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

[Dave Britten]

The HP 65 Finance Pac has a nice program for calculating the number of days between dates, but it doesn't include any programs for adding days to compute a future (or past) date. Can this be done within 100 steps - and without hand-entering constants - on a 65? The days-between-dates program appears to be doing something similar to calculating a Julian day number for the two input dates and taking the difference. My attempts to adapt a Julian day number program from a different model typically end up with most of memory filled, and nowhere near enough left for a Julian-day-to-MM.DDYYYY routine.

I know a good chunk of steps can be saved by having the user input separate month, day, and year (via storing into three registers, using three of the subroutine keys, or simply breaking up the date on the stack), so that the program doesn't have to do all the INT/FRAC grunt work to parse input in MM.DDYYYY format, but that still doesn't seem to get close enough.

I don't need a program with broad enough range to calculate the date 3 million days after Mt. Vesuvius destroyed Pompeii or anything like that; I would think 1900 - 2099 is a perfectly adequate range for most financial calculations. If the HP 80 can do this, I would think the 65 ought to be able to as well.

[teenix]

On the HP Museum USB stick, there is a HP67 Calendar Pac with a program called Days to Dates, Dates to Days. You can set a date and number of days from that date to compute a new date. It might give some ideas for the 65.

cheers

Tony

(01-01-2020 09:49 PM)Dave Britten Wrote:  The HP 65 Finance Pac has a nice program for calculating the number of days between dates, but it doesn't include any programs for adding days to compute a future (or past) date. Can this be done within 100 steps - and without hand-entering constants - on a 65? The days-between-dates program appears to be doing something similar to calculating a Julian day number for the two input dates and taking the difference. My attempts to adapt a Julian day number program from a different model typically end up with most of memory filled, and nowhere near enough left for a Julian-day-to-MM.DDYYYY routine.

I know a good chunk of steps can be saved by having the user input separate month, day, and year (via storing into three registers, using three of the subroutine keys, or simply breaking up the date on the stack), so that the program doesn't have to do all the INT/FRAC grunt work to parse input in MM.DDYYYY format, but that still doesn't seem to get close enough.

I don't need a program with broad enough range to calculate the date 3 million days after Mt. Vesuvius destroyed Pompeii or anything like that; I would think 1900 - 2099 is a perfectly adequate range for most financial calculations. If the HP 80 can do this, I would think the 65 ought to be able to as well.

[Dave Britten]

(01-01-2020 11:23 PM)teenix Wrote:  On the HP Museum USB stick, there is a HP67 Calendar Pac with a program called Days to Dates, Dates to Days. You can set a date and number of days from that date to compute a new date. It might give some ideas for the 65.

cheers

Tony

Thanks, I'll have to take a closer look at that one. It appears to do this kind of date math (plus a few other things), but at 207 merged steps, I'm not sure it could be trimmed down enough to fit the 65.

[teenix]

(01-01-2020 11:33 PM)Dave Britten Wrote:  

(01-01-2020 11:23 PM)teenix Wrote:  On the HP Museum USB stick, there is a HP67 Calendar Pac with a program called Days to Dates, Dates to Days. You can set a date and number of days from that date to compute a new date. It might give some ideas for the 65.

cheers

Tony

Thanks, I'll have to take a closer look at that one. It appears to do this kind of date math (plus a few other things), but at 207 merged steps, I'm not sure it could be trimmed down enough to fit the 65.

Here is the program in text and my emulator card format.

http://www.teenix.org/datePGM.zip

The card files can be loaded into the HP67 and HP97 emulators to try out.

cheers

Tony

[Don Shepherd]

Dave, the answer to your problem can be found here:

https://web.archive.org/web/201705071336...rithm.html

(01-01-2020 09:49 PM)Dave Britten Wrote:  The HP 65 Finance Pac has a nice program for calculating the number of days between dates, but it doesn't include any programs for adding days to compute a future (or past) date. Can this be done within 100 steps - and without hand-entering constants - on a 65? The days-between-dates program appears to be doing something similar to calculating a Julian day number for the two input dates and taking the difference. My attempts to adapt a Julian day number program from a different model typically end up with most of memory filled, and nowhere near enough left for a Julian-day-to-MM.DDYYYY routine.

I know a good chunk of steps can be saved by having the user input separate month, day, and year (via storing into three registers, using three of the subroutine keys, or simply breaking up the date on the stack), so that the program doesn't have to do all the INT/FRAC grunt work to parse input in MM.DDYYYY format, but that still doesn't seem to get close enough.

I don't need a program with broad enough range to calculate the date 3 million days after Mt. Vesuvius destroyed Pompeii or anything like that; I would think 1900 - 2099 is a perfectly adequate range for most financial calculations. If the HP 80 can do this, I would think the 65 ought to be able to as well.

[Dave Britten]

(01-02-2020 09:09 AM)Don Shepherd Wrote:  Dave, the answer to your problem can be found here:

https://web.archive.org/web/201705071336...rithm.html

Thanks Don, I'll see if I can scrape any wisdom from that listing. The presence of the mod operator worries me a bit, since that isn't directly available on the 65. Maybe the day-number-from-date formula could be simplified a bit, but I don't think I can factor out y since that's all integer division. I don't see the same explicit tests for the month being greater than 2, but I think the same (or a similar) effect is contained in the two integer division and mod calculations just before the return.

[Don Shepherd]

(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

[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?

[Don Shepherd]

(01-02-2020 03:43 PM)Dave Britten Wrote:  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.

Never tried that! Do it and see if it works. That would be good to know.

[Dave Britten]

(01-02-2020 04:27 PM)Don Shepherd Wrote:  

(01-02-2020 03:43 PM)Dave Britten Wrote:  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.

Never tried that! Do it and see if it works. That would be good to know.

I know the 67/97 was designed to do that, and I've seen plenty of pictures of cards with both write-protect notches cut out, but I don't know if the 65 reader/writer has the heads aligned to only write on half the card. I'll have to play around with one of my blanks and see if it works (or read through scans of 65 Notes and see what others had to say about it).

I played around with the Finance Pac date program some more, and the day numbering scheme seems to be set up so that Jan. 1, 0000 = 1. If I can work out a reverse calculation to convert back to a date, then I can just make a companion card that you load and run after pressing D and adding/subtracting days.

[SlideRule]

(01-02-2020 03:43 PM)Dave Britten
[color=#FF0000' Wrote:  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. [/color]

YES! I have 100's of HP-65 cards with programs on BOTH sides; never any issues.

BEST!
SlideRule

[Dave Britten]

(01-02-2020 05:27 PM)SlideRule Wrote:  

(01-02-2020 03:43 PM)Dave Britten
[color=#FF0000' Wrote:  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. [/color]

YES! I have 100's of HP-65 cards with programs on BOTH sides; never any issues.

BEST!
SlideRule

Great! Maybe I'll try duplicating the days-between-dates card from the finance pack and adding a second side with a program that converts day numbers back to dates.

[Dave Britten]

Alright, I managed to cram pretty much all the functionality of the 67 Standard Pac calendar program into two sides of a single 65 card:

Side 1:
A: Days between dates (calls B on x and y and subtracts the values)
B: Date to day number (Julian date without the 1,720,982 offset added; preserves stack Y register)
C: Date to day of week (calls B then falls through to D)
D: Day number to day of week

Side 2:
A: Day number to date
B: Number of days to weeks+days

The usage is understandably different from the 67 version, e.g. if you want to compute a future/past date, you load side 1, enter the starting date and press B to convert to a day number, add/subtract a number of days, then load side 2, and press A to convert back to a readable date. If you need to compute several offsets from the same date, you can store the day number in R7-R9, which aren't used by side 2, then recall the day number, add/subtract, and convert to a date as many times as needed.

Like the 67 version, it's limited to 1901-2099 due to not calculating leap years correctly for years that are divisible by 100 but not divisible by 400.

I need to test it a bit more, and make the code more readable than my messy notes, then I'll probably add it to the software library forum.

[teenix]

I've created 2 HP-65 program cards for the emulator if anyone wants to try them out.

http://www.teenix.org/dates65.zip

cheers

Tony

(01-03-2020 02:33 AM)Dave Britten Wrote:  Alright, I managed to cram pretty much all the functionality of the 67 Standard Pac calendar program into two sides of a single 65 card:

Side 1:
A: Days between dates (calls B on x and y and subtracts the values)
B: Date to day number (Julian date without the 1,720,982 offset added; preserves stack Y register)
C: Date to day of week (calls B then falls through to D)
D: Day number to day of week

Side 2:
A: Day number to date
B: Number of days to weeks+days

The usage is understandably different from the 67 version, e.g. if you want to compute a future/past date, you load side 1, enter the starting date and press B to convert to a day number, add/subtract a number of days, then load side 2, and press A to convert back to a readable date. If you need to compute several offsets from the same date, you can store the day number in R7-R9, which aren't used by side 2, then recall the day number, add/subtract, and convert to a date as many times as needed.

Like the 67 version, it's limited to 1901-2099 due to not calculating leap years correctly for years that are divisible by 100 but not divisible by 400.

I need to test it a bit more, and make the code more readable than my messy notes, then I'll probably add it to the software library forum.