(12C) Full Moon

[Dieter]

(01-22-2018 11:31 AM)PedroLeiva Wrote:  Nice. How would the program be for the HP 35s calculator?

The 35s does not have date functions (ΔDAYS, DATE+). So the major part of such a program would consist of two routines that convert a Gregorian date to a Julian day number and vice versa. I have posted such a program in the General Software Library. The rest can be directly translated from the 12C program.

So enter the linked program and then add this routine:

Code:

M001 LBL M
M002 XEQ J001  // calculate JDN of input
M003 2415035   // JDN of 15 Jan 1900
M004 -         // days since 15 Jan 1900
M005 29,5306   // shorter for 147653/5000
M006 INT÷      // number of complete moon cycles
M007 LastX
M008 x         // number of days of these cylces
M009 LastX
M010 +         // add one more cycle to get next full moon
M011 2415035,5 // add this number of days to 15 Jan 1900
M012 +         // + 0,5 days for rounding to closest date
M013 IP
M014 GTO J001  // and convert back to Gregorian date

You may also try this version:

Code:

M001 LBL M
M002 XEQ J001  // calculate JDN of input
M003 ENTER     // and save it on the stack
M004 ENTER
M005 2415035   // JDN of 15 Jan 1900
M006 -
M007 29,5306   // shorter for 147653/5000
M008 RMDR
M009 LastX
M010 X<>Y
M011 -
M012 +         // add to JDN of input date
M013 0,5
M014 +         // round new JDN to full days
M015 IP
M016 GTO J001  // and convert back to Gregorian date

These routines should do the same calculation as the 12C program, but please do your own tests. ;-)
For the given example it should return this:

Code:

22,012018 [XEQ] M [ENTER]

=> 3
   31,012018

Does this work?

Edit: at least for UTC the dates may be one day early here and there. Run the program a second time with the calculated date. If the output is the same as the input the full moon seems to be on the next day. Try 1,012018 and get 1,012018 again. Actually the full moon was on 2,012018 (but less than an hour past midnight UTC).

For local time on the North and South American continent the error seems to be more evenly distributed. For UTC maybe line M011 in the first program should better be 2415036 (and line M013 in the second version changed to 1, respectively). But I haven't made any extensive tests.

Dieter