NavList:
A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding
Re: DeltaT fits
From: Peter Hakel
Date: 2010 Apr 5, 17:56 -0700
From: Peter Hakel
Date: 2010 Apr 5, 17:56 -0700
Frank, I will address some of your points in not quite the original order in which you made them.
You wrote:
"People have prejudices when it comes to the way things are calculated. I guarantee you that some potential customers for your applications read about it and think "that's just a spreadsheet. it can't be any good." That's because they've never been exposed to the awesome power of the dark side of the force! Er... I mean... that's because they're unfamiliar with the amazing computational and presentational versatility of Excel."
I must plead guilty to having that prejudice. The French analytic theories were just more appealing to me than having tables of tabulated ephemerides. I did not do a detailed memory analysis that you suggested. I liked the idea of covering many centuries, both past and present, in a "self-contained" model. I thought it was a better deal to have all that at a certain (maybe large but fixed) cost, whereas using a table would lead to an increase of the project's size depending on the time period I would choose to cover. The DeltaT fits were a bit of a hybrid, because there is no single fitting function to cover all those centuries. If there were one available, I'm sure I'd be using it. :-))
You are absolutely right about the "potential customers" concern. I know, because originally I had my doubts about Excel too. That is why I coded the ephemerides equations into a Fortran test program first. Only after that reproduced official NA data I "transplanted" the formulae into Excel. This is also the reason why the Moon spreadsheet is available for a free download, accompanied by a YouTube demo video. Always happy to make converts for "Team Excel." :-)
You wrote:
"We're getting into coding details here, so I don't want to bore the group with this, but consider: you could make one "line" of data for each calendar day. For one arcsecond accuracy, you can probably cram all the data for the ecliptic latitudes and longitudes of the navigational planets, Sun, and Moon into 500 bytes."
You're right, perhaps we should continue off the list with this. Just a "brief" reply on this point from me here.
Let's say that Excel internally stores each floating point number as a 4-byte "float" (although I believe it is an 8-byte "double"). So, ecliptical latitude and longitude, 8 bytes for one pair for one day. Times 365 for one year worth of daily data, that's roughly 3 kB. Multiply by the number of years you want to cover. Times 24 to have hourly data for the Moon. Maybe Excel can do some clever data compression (binary vs. ASCII? use integer data with fewer bytes for 1" accuracy?).
On my iPhone I did however notice that many of the beautiful Excel functions are simply not supported, at least not yet. For example, I had to abandon the use of the SIGN() and SUMPRODUCT() functions. OpenOffice Calc is not quite 100% supportive either. I had to work around that in order to preserve portability. This discouraged me from even trying more complex tasks such as to interpolate as you suggest, although I have done exactly as you said many times in my Fortran work. And that is why I was not brave enough to do iterations in Excel using self-referential cells; instead, all iterations (light-time in planetary ephemerides, intercepts in the NA's many-body-fix algorithm) are explicitly repeated four times, which is what my Fortran tests told me was sufficient.
I will take your advice for future consideration. I am pretty sure that in your work you also focused on getting a program to calculate the correct answer first, and THEN optimization for speed and memory was the next refinement. With my spreadsheets I have done the first but not yet the second. So little time, maybe I'll get to it eventually.
Peter Hakel
http://www.navigation-spreadsheets.com/
You wrote:
"People have prejudices when it comes to the way things are calculated. I guarantee you that some potential customers for your applications read about it and think "that's just a spreadsheet. it can't be any good." That's because they've never been exposed to the awesome power of the dark side of the force! Er... I mean... that's because they're unfamiliar with the amazing computational and presentational versatility of Excel."
I must plead guilty to having that prejudice. The French analytic theories were just more appealing to me than having tables of tabulated ephemerides. I did not do a detailed memory analysis that you suggested. I liked the idea of covering many centuries, both past and present, in a "self-contained" model. I thought it was a better deal to have all that at a certain (maybe large but fixed) cost, whereas using a table would lead to an increase of the project's size depending on the time period I would choose to cover. The DeltaT fits were a bit of a hybrid, because there is no single fitting function to cover all those centuries. If there were one available, I'm sure I'd be using it. :-))
You are absolutely right about the "potential customers" concern. I know, because originally I had my doubts about Excel too. That is why I coded the ephemerides equations into a Fortran test program first. Only after that reproduced official NA data I "transplanted" the formulae into Excel. This is also the reason why the Moon spreadsheet is available for a free download, accompanied by a YouTube demo video. Always happy to make converts for "Team Excel." :-)
You wrote:
"We're getting into coding details here, so I don't want to bore the group with this, but consider: you could make one "line" of data for each calendar day. For one arcsecond accuracy, you can probably cram all the data for the ecliptic latitudes and longitudes of the navigational planets, Sun, and Moon into 500 bytes."
You're right, perhaps we should continue off the list with this. Just a "brief" reply on this point from me here.
Let's say that Excel internally stores each floating point number as a 4-byte "float" (although I believe it is an 8-byte "double"). So, ecliptical latitude and longitude, 8 bytes for one pair for one day. Times 365 for one year worth of daily data, that's roughly 3 kB. Multiply by the number of years you want to cover. Times 24 to have hourly data for the Moon. Maybe Excel can do some clever data compression (binary vs. ASCII? use integer data with fewer bytes for 1" accuracy?).
On my iPhone I did however notice that many of the beautiful Excel functions are simply not supported, at least not yet. For example, I had to abandon the use of the SIGN() and SUMPRODUCT() functions. OpenOffice Calc is not quite 100% supportive either. I had to work around that in order to preserve portability. This discouraged me from even trying more complex tasks such as to interpolate as you suggest, although I have done exactly as you said many times in my Fortran work. And that is why I was not brave enough to do iterations in Excel using self-referential cells; instead, all iterations (light-time in planetary ephemerides, intercepts in the NA's many-body-fix algorithm) are explicitly repeated four times, which is what my Fortran tests told me was sufficient.
I will take your advice for future consideration. I am pretty sure that in your work you also focused on getting a program to calculate the correct answer first, and THEN optimization for speed and memory was the next refinement. With my spreadsheets I have done the first but not yet the second. So little time, maybe I'll get to it eventually.
Peter Hakel
http://www.navigation-spreadsheets.com/
