Celestia Forums

I have an idea on how we could have Celestia indicate periods of time far into the past and into the future. As it is, I can set time to about +/- 5700000 years CE/BCE but that doesn't cover solar system formation, moon formation (Frank G already modeled), the death of the sun (already modeled as well), etc.

What I propose is, past +/- 10,000 years, time moves (to the user) with some set algorithm. This change would only be useful "educationally." We obviously wouldn't have exact dates (or times for that matter) of astronomical occurances. However, I think it would be interesting & useful to some to be able to put things like Frank's creation of the Moon at what the computer sees as regular years, but a user sees -4.3 BY.

Could this be done within Vincent's Lua addon?

One idea I had is if we let the last two digits of the year +/- 10000 represent a power of 10:
-1/1/10001 could represent the year -10000*10 or -10^5 years
-1/1/10002 could represent the year -10000*100 or -10^6 years
and so on, banner dates in astronomical history could then be (artificially and only to the end user) shown.
at -1/1/13706 or -13700*10^6 the universe starts (user sees -13.7 BY)
at -1/1/45005 or -45000*10^5 for the Sun's beginning (user sees -4.5 BY)
at -1/1/43005 or -45000*10^5 for lunar creation (user sees -4.3 BY)
at 1/1/10006 or 10000*10^6 for the Sun as a red giant (user sees 10 BY)

I hope that made sense...

Really? Nothing? Not one response.... Pah. Guess it wasn't worth the effort of thought.

Patience...

...it's thanksgiving in America isn't it ?

Yes, but we Americans are an impatient sort. Now, now, now!!! LOL...

Actually, speaking of patience. I've been patiently looking forward to your Beta-Lyrae addon.
How's that going? Last I saw, you were aiming for a beta by Feb this year, but I haven't seen it available for download yet.

"Gimme pie. Pumpkin Pie. .... NOW!"

I like the idea of being able to express a broader range of time. However, I would suggest the following (as I have done in the Physics/Astronomy thread):

Year should express a 64-bit number for dates in that range. The would easily cover all of Universal history from a period so long before the big bang it makes the time between the big bang and now look like a wink and so far in the future you would start to see the universe go dark. I would also allow times beyond that using exponentiation.

I think the output of the year needs to be dileneated using the default machine Locale. For English-speakers, this means "," (comma) for thousands separation and "." perior for decimals (In English thou shalt not use a comma for decimal radix) and in German and French a " " (space) or "." (period) for thousands separation and a "," for decimals (In those languages thou shalt not use a period for a decimal radix). Note also technically there is no year 0 in the Common Era (CE) since when the calendarical system was originally designed the Europeans had no concept of the number Zero (0). Also, since the calendar is Gregorian yet was Julian at the proprectic origin of the current era, 31 Dec 1 BCE in the current calendar would actually correspond to 2 January 1 BCE in the old system. Not to mention that the English-speaking world used the old Calendar until the 1700s and before then we started the year on 1 March lilke the old Latin system (March stands for March in the new year for military campaining).

In addition to that, I'd introduce the concept of Universal Time, which set the Time Origin (year 0) to the Big Bang. Unfortunately, this could not correspond exactly with Earth Time but would be useful for simulations on Geologic or universal scales that buggs and I would both like to more accurately emulate.

For dates beyond 2**63, I'd use an exponential system but I'm not sure if going beyond 9,223,372,036,854,775,808 CE will be particularly practical except to see the universe go darker and darker until all matter has been converted into energy.

It wouldn't be hard to do this as far as I can tell although C++ officially lacks the long long (unless they added it in C++ 2003). None the less, it is easy to emulate and most machines these days are 64-bit anyway.

So that's what I plan to do with my project but it may take some time as I can't get the Tarball to compile under cygwin.

TimeHorse wrote: Note also technically there is no year 0 in the Common Era (CE) since when the calendarical system was originally designed the Europeans had no concept of the number Zero (0).

Celestia uses Astronomical dating, not Gregorian.

See http://www.hermetic.ch/cal_stud/cal_art.html for a description of the differences between Christian Gregorian and Julian calendar systems and the Common and Astronomical calendar systems.

Although the calendar date is what the user sees, it is not what Celestia uses internaly. Working out body positions using a calendar representation of time would be impractical, instead Celestia uses the Julian Day as represented by a double.

A double is more than enough to cover the lifespan of the universe, but it has precision issues. Time steps below the current JD precision have no effects, so if you go too far in the future 'Real Time' will not work anymore.

If you use 'long long' in the astro::Date::Date(double jd) constructor in src/celengine/date.cpp, you fix the current year rollover, but you still run into the cloud bug at 32559280-11-26 22:23:15.

For the instances I am talking about (Earth formation, death of the sun, etc within +/- 14 billion years) the existing calendar (double) would work fine. All we would need is a way to "show" the date differently to the user outside of certain limits set in the program (10000 BCE and 10000 CE). Celestia can go ahead an "think" with our date system because the positions of the planets wouldn't matter beyond those dates. This is especially true if you are modeling the formation of the moon. Using my system above, and going back in time, the Earth would cease to exist at system time -1/1/45305 (4.53 GY BCE) and be replaced with Earth Mark I and Theia. Go back to -1/1/46000 (4.6 GY BCE) and you see the solar system forming, etc, etc... The perception to the user would be time moving more quickly, without having to use K and L. The user would see 4.5 Billion Years BCE in the display, while the system would use -1/1/45005. When all is said and done, you wouldn't need to worry about the "real time" boundaries.

Christophe wrote:If you use 'long long' in the astro::Date::Date(double jd) constructor in src/celengine/date.cpp, you fix the current year rollover, but you still run into the cloud bug at 32559280-11-26 22:23:15.

Sorry, what's the "cloud bug"?

As far as JDN (Julian Day Numbers) are concerned, those only count days, not years, so you are right, the year is arbitrary as far as JDN is concerned. But of course, with JDN you need to express the time of day as a fraction. Thus, you either need:

1) A double / long double (53 or 64 bits of precision) (currently using double)
2) A pair of Long Longs and long -- long long for the JDN and long for the second of the day (0 to 86399). JDN has 64-bit range.
3) A long long fixed-point number such that say JDN = n*2**18 for an 18-bit binary fraction and 46 bits for JDN.
4) Create a class to abstract how the JDN is internally defined and define math operands around it so that it emulates a floating-point type.

Personally, I think the ideal solution has to be a floating point number, just one with more precision, since I have a feeling all the calculation would get wacky if you changed it without providing a fully-qualified JDN class with all math operations. 53 bits could express dated accurately up until about 188 147 536 years, approximately, by my estimates given 17 bits required to resolve the JDN Fraction uniquely for a given second.

I think it would be confusing to express dates in the compact exponentiated form buggs_moran originally suggested and still prefer 'fixing' the clock to give it a greater range.

TimeHorse wrote:Sorry, what's the "cloud bug"?

This:

TimeHorse wrote:53 bits could express dated accurately up until about 188 147 536 years, approximately, by my estimates given 17 bits required to resolve the JDN Fraction uniquely for a given second.

The time variable being used throughout the code, unless you want to do a full rewrite, I think we are stuck with a 53 bit precision. You also have to take into account that the clock is incremented at each frame redraw, so to support real time the clock needs to be precise to 1/100 s, not to 1 s.

TimeHorse wrote:I think it would be confusing to express dates in the compact exponentiated form buggs_moran originally suggested and still prefer 'fixing' the clock to give it a greater range.

I agree.

We could use two variables, an offset (64-bit integer) and a time (53-bit floating point).

The offset stores the time in years, and the 64-bit integer stores the date within the year.

Whenever the time changes, if the year changes it is added to the offset and subtracted from the date.

Whenever the time is displayed, the offset is displayed separately to the date, but in such a way that it looks the same.

Computation of angles are a trickier matter with this method, as two parts of the angle must be calculated and this could slow down angular computations by a factor of two. What would be needed would be an efficient way of preserving the accuracy of angles over such time periods.

This method can support years from -2^63 to 2^63 (about -1.8 * 10^19 to 1.8 * 10^19) with no loss of precision.

One other change would be required - limiting the maximum speed of the simulation to 10^12 or 10^13 times the maximum speed.

Even if the above method won't work directly, the idea of storing a separate offset variable solely for display purposes as suggested by buggs_moran would be one possible solution.

1) compact exponentiated form: I like that description. I actually was going to call it "half assed scientific notation"
2) my initial purpose for this was purely for visual/educational use. Frankly, there is very little need to display solar orbits precisely beyond recorded history as we have no exact records whatsoever. I was originally thinking some kind of logarythmic scale, but powers of 10 don't seem to work well with 365.242199... The only snag in my method, apart from the initial confusion of setting dates in ssc files, is setting up movement outside out solar system in the future (i.e. stellar migration, ancient supernovae, and the like). As it is, fsgregs addons take place outside of recorded history, but at dates which students do not understand. The sun dying in a mere 7000 years is much more daunting than 4.5 billion years... Obviously, I teach the correct date, but that is not the point of my addon idea...

TimeHorse wrote:I think it would be confusing to express dates in the compact exponentiated form buggs_moran originally suggested and still prefer 'fixing' the clock to give it a greater range.

Of course, I would love the ability to put in actual years rather than my "compact exponentiated form". Just like showing how long travel actually takes with a certain speed setting (ie travelling to the moon at 1000 m/s) , it would be neat to show how long the sun will be around, or how long it took the continents to form...

selden wrote:Celestia uses Astronomical dating, not Gregorian.

See http://www.hermetic.ch/cal_stud/cal_art.html for a description of the differences between Christian Gregorian and Julian calendar systems and the Common and Astronomical calendar systems.

Thanks Seldon. I am fimiliar with what is commonly called the Julian Day Number (JDN). This is not to be confused with the Julian Calendar to which I referred. The Julian Day Number used in Astronomy really doesn't concern itself with years and counts time only in Julian Days. Thus, the year is not really important. Once can however convert between JDN and any of the other calendrical systems quite easily. I'm not sure which epoch you use in Celestria as I have only been studying the code for a few days but I can say it is very nicely written C++. I have seen the JDN epoch set to 1 Jan 1900 (Gregorian), 1 Jan 2000 (Gregorian), 1 Jan -4713 B.C.E. (Julian) and 17 Nov 1858 (Gregorian). Which is used doesn't really matter as it's just an offset.

For more information on various calendars, I suggest visiting the Calendrical Calculations site at http://emr.cs.uiuc.edu/home/reingold/calendar-book/index.shtml.

Looking some more at the code, my opinion is that the best thing to do is solve the problem in 2 steps:

1) Typedef double JulianDayNumber; and replace double with JulianDayNumber throughout the code where a double is used to represent a Julean Day Number.

2) Design a class that emulates a double with greater precision and is fast.

The trouble is step 1 would require a rather intense scrutiny of the code because of course double can be used for a number of things, but I think even if we don't do 2 it is a good idea because it makes it obvious from context when a double actually represents a JDN.