Date addition: can it be done in a single HP 65 program card?

[Dave Britten]

(01-02-2020 03:36 PM)Don Shepherd Wrote:  

(01-02-2020 01:38 PM)Dave Britten Wrote:  The presence of the mod operator worries me a bit

I implemented the g() function on the 65 years ago, and I handled the mod 12 for m like this:

rcl 3 (m)
9
+
12
/
frac
12
x
sto 3

that seemed to work fine. I always double-checked my test results with the 12c DAYS function and the 17b DAYS function.

Yes, I see those two large integer constants in the d() calculation, perhaps just store those in registers prior to executing the program, although you hate to have that dependency. I would imagine two cards would be required, maybe even three. My DBD program on the 65 is 96 lines.

Interesting challenge.

Don

Yeah, I'm about 99.9% sure I could make it work with two cards. I've already fit a date-to-day-number program on one card (a quick adaptation of the routines in this program), there just isn't enough room to also fit a day-number-to-date program to convert back to a date. But you can use the first card to easily calculate days between dates, by converting the two dates to numbers and subtracting.

I'll probably have to settle for that approach: the first card can accept dates and convert them to numbers, maybe with another subroutine that takes two dates and does the subtraction for you, then a second card that converts numbers to dates so you can interpret the results of adding/subtracting days.

Can the 65 safely record on both "sides" of a card, or do the tracks end up overlapping? I could fit it on a single card that way.

EDIT:

The Finance Pac "Actual Days Between Dates" (FIN 1-28A) already has a somewhat undocumented routine on D that parses a date in MM.DDYYYY format and converts it to some kind of date number, but it doesn't appear to be Julian date numbers. For example, Jan. 2, 2020 is converted to 737,806, and Jan. 1, 1900 is 693,975. Does that date numbering scheme look familiar to anybody?