It is currently Wed, 22-11-17, 18:33 GMT

All times are UTC




Post new topic Reply to topic  [ 32 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Sun, 21-07-13, 16:18 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4510
Location: Hamburg, Germany
Do's and Don'ts in Random Star Generation

This post could well be viewed as a mini-tutorial about some basics in randomness.

Since the random generation of stars or other celestial objects plays a very important role in celestia.Sci, I decided to present here some elementary exercises before turning to more advanced stochastic methods in a subsequent post.

Note: Whenever one talks about picking numbers x randomly, one has to specify the corresponding probability density function p(x)!

The simplest one is just a constant and is called a uniform distribution. Every programming language offers a random command that refers to a uniform probability distribution. In C++ for example, Mathf::frand() and Mathf::sfrand() generate float random numbers in [0,1) and (-1,1), respectively.

You all know the discrete version of the uniform distribution from playing dice ;-) . For one die the probability of throwing a number between 1 and 6 is constant and equals 1/6 for each number, such that the sum adds up to 1.

A) Suppose you were given the task of picking stars uniformly distributed on the surface of a sphere with radius 1.

How would you do it?

Sounds almost trivial, right? You parametrize the 3-vector of each point on the unit sphere by 2 angular polar coordinates θ and Φ (with radius set r = 1), in analogy to latitude and longitude, like so
Image

Then you pick each one of your 2 angular coordinates randomly from uniform distributions
θ in [0,2π) and Φ in [0,π].

Unfortunately this is a Don't. To convince you, I repeated the described procedure in Maple. Here is how your result would look like:

Attachment:
unitsphere_wrong.jpg
unitsphere_wrong.jpg [ 64.65 KiB | Viewed 5644 times ]


You clearly see the accumulation of stars near the north and south poles, which is NOT what you set out to accomplish!

So what went wrong??

To get this right, you have to first consider the respective differential element expressed in the chosen coordinates that appears in the normalization integral of your probability distribution. In the above example of the unit sphere surface, we consider the differential area element (solid angle) which should be familiar:

dΏ = sinΦ dΦ dθ = - d(cosΦ) dθ

and thus the relevant probability density p(Ώ) satisfies

p(Ώ) dΏ = constant d(cosΦ) dθ

with these variables!
++++++++++++++++++++++++++++++++++
Apparently for this task, a constant uniform distribution requires cosΦ NOT Φ to be picked randomly along with θ
++++++++++++++++++++++++++++++++++
Again, I did it for you in Maple. Calling now cosΦ = u, we rewrite our vector as follows

Image

and randomly pick u and θ from our uniform distribution. Here is the result:

BINGO!

Attachment:
unitsphere_right.jpg
unitsphere_right.jpg [ 54.37 KiB | Viewed 5643 times ]


This looks pretty cool doesn't it?

Next consider a second task that now involves 3D instead of 2D.

B) You now are to pick stars uniformly distributed within a 3D sphere of radius 1.

This partly resembles the previous problem, whence we already know how to pick the 2 angular coordinates correctly for stars on the surface of any sphere of radius r <=1. The new element is to correctly pick the 3rd coordinate associated with the radius from a uniform distribution!

Firstly, here is the Don't method

This method will now be bypassed hopefully by all of you ;-)
It consists in just picking r in [0,1) randomly from the uniform distribution besides the 2 angular coordinates cosΦ = u and θ.

Unfortunately the result again doesn't look like a uniform distribution of stars within the spherical volume:

Attachment:
sphere_wrong.jpg
sphere_wrong.jpg [ 48.71 KiB | Viewed 5644 times ]


Clearly there are far too many stars at small values of the radial coordinate!

How to get this right?

Again, consider the appropriate differential measure which is now the differential volume element dV in 3D polar coordinates. Since we all know the volume of a sphere by heart,

Image

we rewrite the familiar result (with θ and Φ already integrated over => 4π )

Image

The solution is --analogously to the above recipe-- to pick the volume V randomly from the uniform distribution and solve for r, which apart from a constant factor amounts to

Image

Here is the result:
BINGO!

Attachment:
sphere_right.jpg
sphere_right.jpg [ 83.43 KiB | Viewed 5644 times ]


After these basic exercises, I'll report very soon about the actual, more advanced statistical methods I used to render the globular cluster stars and the galactic halo stars etc in celestia.Sci.

Let me know whether this was anywhere instructive to some of you?

Fridger


Top
 Profile  
 
PostPosted: Sun, 15-06-14, 13:24 GMT 
Offline

Joined: Fri, 13-06-14, 17:45 GMT
Posts: 59
I think random star generation is fine until "real" stars can be distinguished from generated ones. For example all fictional star names should start with "Fcl-"...


Top
 Profile  
 
PostPosted: Sun, 15-06-14, 16:24 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4510
Location: Hamburg, Germany
sjohn wrote:
I think random star generation is fine until "real" stars can be distinguished from generated ones. For example all fictional star names should start with "Fcl-"...


In contrast to Celestia, celestia.Sci follows a quite different approach: statistical concepts play a much more prominent role more or less as in the scientific world. Less initiated people often claim that everything can be proven by means of Statistics ;-). But that's just ignorance. There are many prominent fields in Physics from Quantum Mechanics to Cosmology, where Statistics is an intrinsic necessity!

While Celestia was largely devoted to the Solar system and the galactic neighborhood, celestia.Sci focusses on the Deep Space out to the realm of Cosmology. It is already due to the huge distances and the huge amounts of bodies which are involved here that statistical concepts become unavoidable.

Back to star naming: in celestia.Sci all stars that have official names can be selected by that name. All other (randomly generated stars) do not carry any names and hence cannot be individually addressed. By clicking on a star you can easily tell the difference. Also each time you reboot celestia.Sci the locations etc of the random stars change! But that's no problem.

Let me briefly address a typical application of random stars: so-called star halos of galaxies the properties of which have been extracted recently from a most sophisticated study of our closest spiral galaxy neighbor, the Andromeda galaxy (M 31). It was indeed possible to separate off all foreground stars and extract the distribution of the M 31 halo stars in great detail. Here let me refer you to a summary of mine: viewtopic.php?f=11&t=544

+++++++++++++++++++++++++++
In celestia.Sci, we take these measured distributions as probability densities for random generation. This implies that after suitable averaging we will precisely reproduce ALL measured properties of the Halo stars, although the locations, brightness and colors of the generated stars are fluctuating!
+++++++++++++++++++++++++++

This approach gives us also very nice visualization results, apart from being conform with the standard scientific approach.

Let me illustrate the situation with a single example:

Consider the barred spiral galaxy pair NGC 3788 and NGC 3786 (Hubble type SBa) that is interacting gravitationally. Here is a photo of this pair from the SDSS survey:

[Click on image by all means!]
Attachment:
n3788_n3786_SDSS.jpg
n3788_n3786_SDSS.jpg [ 39.75 KiB | Viewed 4999 times ]


In celestia.Sci, the computer renders the pair with a much better resolution ;-). See here,

[Click on image by all means!]
Attachment:
n3788_n3786.jpg
n3788_n3786.jpg [ 70.28 KiB | Viewed 4999 times ]


On the left you see a seemingly "very bright", named foreground star: HIP 56900. Yet its apparent magnitude is only 10.84. The very faint bright dots around the galaxy pair are incredibly much fainter, though! These are the random Halo stars associated with the two galaxies.

But now, upon diving into the Halo towards the core of e.g. NGC 3786, a huge amount of the Halo stars starts to become visible with a very characteristic luminosity and color distributions....See here:
[Click on image by all means!]
Attachment:
n3788_n3786_zoom.jpg
n3788_n3786_zoom.jpg [ 80.56 KiB | Viewed 4999 times ]


Do you still want to know the name of each of these random stars? ;-)

Fridger

_________________
Image


Top
 Profile  
 
PostPosted: Sun, 15-06-14, 20:19 GMT 
Offline

Joined: Fri, 13-06-14, 17:45 GMT
Posts: 59
Whoa! I see the concept now. So it is basically a spatial astronomy program plus a realistic statistical virtual Universe program...Nice!

I used SpaceEngine for a time, but I'm sure celestia.Sci is (will be) much more scientific and realistic. My problem was with SE that it felt like a videogame (which it is) and that - for me - was a serious problem...

A realistic cosmology engine is a very good option in my opinion, but of course the "real" empirical knowledge is the best.

I hope celestia.Sci will be able to use the new GAIA data in a few years time...that is one billion real stars...I hope the database will be able to deal with that many stars...


Top
 Profile  
 
PostPosted: Tue, 24-06-14, 3:47 GMT 
Offline
User avatar

Joined: Fri, 03-04-09, 8:21 GMT
Posts: 211
t00fri wrote:
Also each time you reboot celestia.Sci the locations etc of the random stars change! But that's no problem.

Hi Fridger,

Under some circumstances it might be useful to exactly reproduce the same results between reboots, so can I suggest that having the option to be able to control / specify the seed for all this randomness might be a nice feature to have. (Perhaps as an option in the .cfg file??)

Regards
CC

_________________
CITIZENS OF CM - JOIN THE REVOLUTION
...black out your avatar
THE AVATARS ARE REVOLTING !!!


Top
 Profile  
 
PostPosted: Tue, 24-06-14, 13:54 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4510
Location: Hamburg, Germany
chuft-captain wrote:
t00fri wrote:
Also each time you reboot celestia.Sci the locations etc of the random stars change! But that's no problem.

Hi Fridger,

Under some circumstances it might be useful to exactly reproduce the same results between reboots, so can I suggest that having the option to be able to control / specify the seed for all this randomness might be a nice feature to have. (Perhaps as an option in the .cfg file??)

Regards
CC


Good point, CC.

In C++, the (pseudo-) random number generator rand() needs to be properly initialized. Depending on the argument seed of the srand(seed) method, different desired behaviours may easily be obtained.

For every different seed value used in a call to srand(seed), the pseudo-random number generator can be expected to generate a different succession of results in the subsequent calls to rand().

Two different initializations with the same seed will generate the same succession of results in subsequent calls to rand().

If seed = 1, the generator is reinitialized to its initial value and produces the same values as before any call to rand or srand.

Specifically, by adding a line like

srand(time(NULL));

one gets a distinct seed each time, and the sequence of numbers produced will vary accordingly.
Note that one only needs to call srand(seed) once, not before each time rand() is called.

Cheers,
Fridger

_________________
Image


Top
 Profile  
 
PostPosted: Tue, 24-06-14, 20:43 GMT 
Offline
User avatar

Joined: Fri, 03-04-09, 8:21 GMT
Posts: 211
Sure Fridger,

Those are programming decisions most anyone who's done any coding at all will be familiar with, ... but does this mean "yes" : that you will allow for this behaviour to be user-configurable?

If so, what do you anticipate it will look like in the CFG file?

CC

_________________
CITIZENS OF CM - JOIN THE REVOLUTION
...black out your avatar
THE AVATARS ARE REVOLTING !!!


Top
 Profile  
 
PostPosted: Wed, 25-06-14, 0:14 GMT 
Offline
User avatar

Joined: Tue, 04-09-07, 21:55 GMT
Posts: 773
Location: N 42.38846 W 83.45456
a default setting using rand would be good
but
with a option of setting the seed , that way one can copy it or set it so that a view IS reproducible

i would think that reproducing the SAME settings over and over would be a valuable option

_________________
"I don't pitch Linux to my friends, I let Microsoft do that for me."
Using OpenSUSE 42.1 & Scientific Linux 6.7


Top
 Profile  
 
PostPosted: Wed, 25-06-14, 6:22 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4510
Location: Hamburg, Germany
chuft-captain wrote:
Sure Fridger,

Those are programming decisions most anyone who's done any coding at all will be familiar with, ... but does this mean "yes" : that you will allow for this behaviour to be user-configurable?

If so, what do you anticipate it will look like in the CFG file?

CC


CC,

certainly, my reply meant YES.

I actually have provisionally implemented the two different seed options already in celestia.Sci. There are five cases where random generation is used throughout:

  • halo stars around galaxies,
  • 3D rendering of spiral galaxies
  • rendering of "globular clusters" in the periphery of elliptical galaxies
  • rendering of irregular galaxies via "Diffusion Limited Aggregation (DLA)" algorithm
  • star distributions and colors of globular clusters
  • locations of pink HII regions in galaxies

It remains to be seen whether I'll only allow for a global twofold seed option for all listed renderings or whether the user is allowed to select the seeds for the 5 cases individually.

The seed option will boil down to a choice of a boolean variable (true, false), say fluct:
Code:
if(fluct)
    srand(time(NULL);
else
    srand(1);


The choice of the fluctuation setting (fluct) will be implemented in the menu bar via
the File->Preferences...graphical dialog. The program dumps and reloads all respective settings at shutdown into a configuration file in a Qt-specific manner. In case there are convincing arguments, the preferred fluct setting might instead be entered in the good-old celestia.Sci.cfg file. However, the general idea is to interactively manage all such settings in the graphical Preferences... dialog.

Probably, the fluct setting will also enter in the "Deep Space" workflow toolbutton. Note that celestia.Sci comes for now with three preset workflows :

  • Solar System Work
  • Deep Space Work
  • Cosmological Work

The last used workflow is also stored and reloaded.

Here is a screenshot of the toolbar region with the Workflow toolbutton (W) clicked on the right.
[Click on image by all means!]
Attachment:
toolbar.jpg
toolbar.jpg [ 34.87 KiB | Viewed 4896 times ]


JVV wrote:
a default setting using rand would be good...


My preference for a default setting is fluct = true, since this fluctuating rendering option naturally illustrates that the positions (and colors) of the listed objects are not individually known, but only in the sense of stochastic variables sampled from KNOWN respective probability distributions.

Fridger

_________________
Image


Top
 Profile  
 
PostPosted: Wed, 25-06-14, 14:26 GMT 
Offline
User avatar

Joined: Mon, 03-09-07, 23:01 GMT
Posts: 388
Location: Tuscany, Tyrrhenian Sea
t00fri wrote:
The program dumps and reloads all respective settings at shutdown into a configuration file in a Qt-specific manner


This mean that will be memorized also the random seed value(s) of srand(seed) in order to replicate the star generation like has been randomly generated. Let correct me if I'm wrong: one need to know "after" the first load what is the seed to be used "before" the second load in order to replicate that star generation, right? How do you do that in C++? ^^ I'm unable to do that in LUA: how I ask for a "visual output" or "print" of the random value of e.a. math.randomseed(12654), I got nothing, just the inizialization for the successive, working, math.random() function; whereas I need of knowing how 12654 has been random generated without to be set by user. x/

_________________
Never at rest.


Top
 Profile  
 
PostPosted: Wed, 25-06-14, 15:51 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4510
Location: Hamburg, Germany
fenerit wrote:
t00fri wrote:
The program dumps and reloads all respective settings at shutdown into a configuration file in a Qt-specific manner


This mean that will be memorized also the random seed value(s) of srand(seed) in order to replicate the star generation like has been randomly generated.

No, what is memorized is NOT the seed but the boolean constant fluct. If fluct = true then we use a different sequence of random numbers in each run, since then seed = time(NULL), which differs after each boot-up. If fluct = false, we use seed = 1, which has a special meaning, as I summarized above:
++++++++++++++++++++
If seed = 1, the generator is reinitialized to its initial value and produces the same values as before any call to rand or srand.
++++++++++++++++++++
Quote:
Let correct me if I'm wrong: one need to know "after" the first load what is the seed to be used "before" the second load in order to replicate that star generation, right? How do you do that in C++? ^^ I'm unable to do that in LUA: how I ask for a "visual output" or "print" of the random value of e.a. math.randomseed(12654), I got nothing, just the inizialization for the successive, working, math.random() function; whereas I need of knowing how 12654 has been random generated without to be set by user. x/


Sorry, my LUA expertise is in Coma and needs to be "woken up" again. But I did plenty of tests in celestia.Sci: if I simply call srand(1) at an initializing stage of celestia.Sci, I keep getting the same displays of
  • halo stars around galaxies,
  • 3D rendering of spiral galaxies
  • rendering of "globular clusters" in the periphery of elliptical galaxies
  • rendering of irregular galaxies via "Diffusion Limited Aggregation (DLA)" algorithm
  • star distributions and colors of globular clusters
  • locations of pink HII regions in galaxies

in successive boot-ups.

Cheers,
Fridger

_________________
Image


Top
 Profile  
 
PostPosted: Wed, 25-06-14, 16:26 GMT 
Offline
User avatar

Joined: Mon, 03-09-07, 23:01 GMT
Posts: 388
Location: Tuscany, Tyrrhenian Sea
Then, it is exclude the case John (in my opinion) was asking for:

John Van Vliet wrote:
a default setting using rand would be good but with a option of setting the seed, that way one can copy it or set it so that a view IS reproducible i would think that reproducing the SAME settings over and over would be a valuable option


because the boolean option in both cases avoids the condition that one, fashioned by the random disposition of a particular prompt, be able to reproduce it later;

I apologize if I bring confusions in these matters

_________________
Never at rest.


Top
 Profile  
 
PostPosted: Wed, 25-06-14, 18:47 GMT 
Offline

Joined: Fri, 13-06-14, 17:45 GMT
Posts: 59
I would like to add one thing to this: I think it is very important psychologically to draw a distinct line between plausible fiction and scientific reality...Realism may well be a kind of illusion too but it is the best way of truthful perception in my opinion.

It can be very nice to predict certain properties of mostly unknown galaxies etc., but I think you should not blur reality with virtual fictional reality.

A virtual reality which is fictional can be - for me - a bit of a letdown...if it does not feel real, it is somehow fake...even if it is probable...

Of course I'm not saying these feelings are rational...maybe our mammalian brains are programmed to understand only the macrostructure of matter and energy...

So the real question is this: do I want to see stars which cannot be discovered in reality, because they are "not there"?

It may sound ridiculous to you, but for me it can be a real problem...where does realistic virtual reality end and where does fictional virtual reality start?

So it is still about Do's and Don'ts...


Top
 Profile  
 
PostPosted: Wed, 25-06-14, 20:28 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4510
Location: Hamburg, Germany
sjohn wrote:
I would like to add one thing to this: I think it is very important psychologically to draw a distinct line between plausible fiction and scientific reality...Realism may well be a kind of illusion too but it is the best way of truthful perception in my opinion.

It can be very nice to predict certain properties of mostly unknown galaxies etc., but I think you should not blur reality with virtual fictional reality.

A virtual reality which is fictional can be - for me - a bit of a letdown...if it does not feel real, it is somehow fake...even if it is probable...

Of course I'm not saying these feelings are rational...maybe our mammalian brains are programmed to understand only the macrostructure of matter and energy...

So the real question is this: do I want to see stars which cannot be discovered in reality, because they are "not there"?

It may sound ridiculous to you, but for me it can be a real problem...where does realistic virtual reality end and where does fictional virtual reality start?

So it is still about Do's and Don'ts...


Please keep in mind that we are talking here about celestia.Sci, with the boldface acronym .Sci standing for Scientific. Being a scientist by profession, with decades of frontline research experience in Astro-Particle physics and Cosmology, I think I know pretty well about your evoked border lines ;-) .

To properly understand statistical arguments, it does indeed require some solid background in the field.

Perhaps you did not carefully read the background info I provided in a number of threads of this forum about the used stochastic approaches...

What astronomers, astro-physicists and cosmologists measure in the Universe are often not properties of individual far-away stars, globulars, galaxies, ...etc, but rather a multitude of distribution functions characterizing accurately in a probabilistic sense the locations, densities, color, brightness,... of such objects! Since there are always VERY big numbers N of such objects involved, the relative statistical uncertainties of their actual locations etc. decrease like 1/sqrt(N) -> 0 as surely some of you will remember from their professional formation times.

It is precisely this kind of knowledge that is used in celestia.Sci to visualize the far-distant objects in Space in a statistical manner. No fiction involved here, yet the visualization results need to be interpreted correctly!

Your above question
Quote:
So the real question is this: do I want to see stars which cannot be discovered in reality, because they are "not there"?

simply shows that you did unfortunately misinterpret the celestia.Sci approach entirely.

In natural science EVERY measurement of quantities of interest involves some uncertainties. The far away objects in Space involve even much bigger ones. Take e.g. the given positions of far-away stars from our best scientific star catalogs Hipparcos and/or Tycho. As soon as the parallaxes for these stars as seen from Earth get smaller and smaller, the uncertainties w.r.to distance increase dramatically: HENCE...-- with position data from these catalogs taken at face value -- the respective stars are probably not THERE! Still with a correct interpretation of these data i.e. by properly including the error bars, the contained information is most valuable.

By using probabilistic approaches along with the measured data on relevant probability densities, one can make VERY solid statements about such objects, DESPITE their elusiveness and far distances. The clue is the reduction of uncertainties due to the large numbers involved.

Fridger

_________________
Image


Top
 Profile  
 
PostPosted: Fri, 27-06-14, 13:26 GMT 
Offline
User avatar

Joined: Fri, 03-04-09, 8:21 GMT
Posts: 211
t00fri wrote:
My preference for a default setting is fluct = true, since this fluctuating rendering option naturally illustrates that the positions (and colors) of the listed objects are not individually known, but only in the sense of stochastic variables sampled from KNOWN respective probability distributions.

I agree that's a good idea as the default setting.
If I understand you correctly seed=1 will produce a static version on each boot (sorry, but my "C" is also in a coma, but if I recall correctly seed is typically a float f: 0 <= f < 1), therefore seed = 1 is only one of many possible "static" versions.
ie. Repeating any previously used seed value (not just seed=1) will reproduce the same results as any previous use of that value as a seed.

So, I think what JVV and fenerit are suggesting is that users will start with fluct = true, but during a given random session they may like those results in particular, and therefore decide to set fluct = false before terminating the session, with the expectation that the particular randomly generated display of that session will be replicated on subsequent boots (until such time as fluct is set back to true).

However this would require that the actual randomly generated seed value (from a seed = time(NULL) call) is saved when fluct is set to false, and re-called on subsequent startup.

Regards
CC

_________________
CITIZENS OF CM - JOIN THE REVOLUTION
...black out your avatar
THE AVATARS ARE REVOLTING !!!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 32 posts ]  Go to page 1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group