HP Forum Archive 11

[ Return to Index | Top of Index ]

30.6001, 25 year old hack? Message #1 Posted by hugh on 7 Apr 2003, 7:30 p.m. formulae for date calculations always involve the mystery number 30.6001 [quick recap. problems involving date arithmetic are solved by converting a d/m/y date into a julian day number (# of days since 4716BC) or some offset absolute day# eg from 1/1/1900, adding & subtracting from that number and then converting back to d/m/y. thus two subroutines are needed date->julian and julian->date]. 30.6001 is the days per month approximation (365-31-28)/10 (ie av month days without jan & feb). so what? this number is used in most modern books eg. montenbrucks's astronomy book, also in peter duffett-smith's book. both come from Meeus' earlier works, first published 1979. now, i happen to know that all the computations using 30.6001 work just fine using 30.6. so, whats the deal with the small adjustment. i thought i had got to the bottom of this when i read meeus' to reveal 30.6001 was a *workaround* for the numerical errors in his hp-85 microcomputer from 1978 (he says this in his book). 1978 is before ieee floating point standardization. so basically, you needed small number hacks to manually ensure correct roundoff. so this hack has been carried forward 25 years with no one noticing. but wait! here's the hp29c/19c applications book from july 1977. p44 and the *same* hack is used before meeus' publication. could it be that hp originated this hack all along. and where did it really start?

Re: 30.6001, 25 year old hack? Message #2 Posted by Trent Moseley on 7 Apr 2003, 11:49 p.m., in response to message #1 by hugh Hugh, I don't know the answer to your question, however I'm looking in my files. Now what Montebruck said (translated from German in his book (Practical Ephemeris Calculations pub. by Springer-Verlag in 1987 pg 34)"In all computers with clean arithmetic 30.6001 can be replaced by 30.6. This is usually, however, the case only for pocket computers." Now the date we are counting from for the Julian Day Number is Noon 1 January 4713 B.C. not 4716 B.C.

Re: 30.6001, 25 year old hack? Message #3 Posted by Bill Wiese on 8 Apr 2003, 2:10 a.m., in response to message #2 by Trent Moseley Folks.. > Now what Montebruck said (translated from German in > his book (Practical Ephemeris Calculations pub. by > Springer-Verlag in 1987 pg 34)"In all computers > with clean arithmetic 30.6001 can be replaced by > 30.6. This is usually, however, the case only for > pocket computers." I assume the term 'clean arithmetic' is implying BCD floating-point math, not binary floating-point (which most computers use). So if you're running on a decent calc or a computer using BCD F.P. math (HP71B, HP75, etc.) you're OK. Funny that mention was made of this being done for the HP85 - because HP85 BASIC, I'm pretty sure, uses BCD FP math! Having a vague recollection of doing date math with Julian dates, the 0.0001 is probably added so that we avoid problems with taking INT() and FRAC() functions on results in the digit form of N.999999... instead of (N+1).000000. This just biases the error upward a bit. This may not just be due to BCD vs binary floating-point math. Most BCD math engines have at least 8 or 10 digits of precision, while quite a few programming languages had a 'float' data type that was 32bits wide including the exponent - meaning 24 bit mantissa gives about 7.2 digits of precision (bits used in a base = log(base)/log2). So we have some difference there. Bill Wiese San Jose, CA

Re: 30.6001, 25 year old hack? Message #4 Posted by hugh on 8 Apr 2003, 1:00 p.m., in response to message #3 by Bill Wiese according to my calculations 30.6 will work fine on any BCD math and also on ieee754 floats. the BCD math means that it should always work on a calculator. the problem 30.6001 is trying to avoid in binary is that floor(10*30.6) = 305 when 30.6 is actually 30.599999... internally as it cant be exact in binary. however, floating point math would be useless if 10*30.6 != 306 and so ieee rounds the last bit correctly. montenbruck is correct. i assume "clean" arithmetic means either BCD representation or correct treatment of rounding the last binary digit. reading meeus more closely; yes hp85 was BCD, but he is complaining about other basics (presumably binary) like the hp-intergral hp-ux technical basic 5.0 (what was that?). so appologies to the hp85.

30. 6 vs. 30.6001... Message #5 Posted by Andrés C. Rodríguez (Argentina) on 8 Apr 2003, 7:32 a.m., in response to message #1 by hugh If I recall correctly, the calendar program in the HP25 Applications Book used 30.6 (perhaps just to save precious program steps); the HP41C Standard Applications Pac used 30.6001 (there was much more program space available).

Re: 30. 6 vs. 30.6001... Message #6 Posted by hugh on 8 Apr 2003, 12:50 p.m., in response to message #5 by Andrés C. Rodríguez (Argentina) thats interesting because 30.6 would work. the 29c book uses 30.6001 *but* it is stored in a register, so the program cost is avoided.

Re: 30. 6 vs. 30.6001... Message #7 Posted by Trent Moseley on 8 Apr 2003, 5:46 p.m., in response to message #5 by Andrés C. Rodríguez (Argentina) Andres, You are right about the HP-25C Applications Book. They did use 30.6 but they could have used 30.6001 because the listed program used only 46 steps! tm

Re: 30. 6 vs. 30.6001... Message #8 Posted by hugh on 8 Apr 2003, 6:21 p.m., in response to message #7 by Trent Moseley perhaps they knew, 30.6001 was bogus. what date is the 25c applications book? the 29c is 1977.

Re: 30. 6 vs. 30.6001... Message #9 Posted by Trent Moseley on 8 Apr 2003, 6:50 p.m., in response to message #8 by hugh Hugh, 1975 tm

Re: 30. 6 vs. 30.6001... Message #10 Posted by Trent Moseley on 9 Apr 2003, 5:37 p.m., in response to message #8 by hugh Hugh, Does knowing the 25C's Appications Programs book was printed in 1975 using 30.6 throw any further light on your investigation? tm

Re: 30. 6 vs. 30.6001... Message #11 Posted by Andrés C. Rodríguez (Argentina) on 8 Apr 2003, 6:22 p.m., in response to message #7 by Trent Moseley OK, I was just trying to remember details which are 25 years old!

[ Return to Index | Top of Index ]

Go back to the main exhibit hall