Threaded Mode | Linear Mode

Carsen · 01-10-2018, 05:18 AM

I am inspired by Gamo to post some HP-12C programs! I have honed these 2 programs for a couple of months now. Since I collect driving times everyday, I need to convert the DD.MMSSSS into a number and vice versa.

Here is HMS to decimal format

Code:

01  [ENTER]

02  [g] [INTG]

03  [SWAP]

04  [g] [FRAC]

05  [EEX]

06  2

07  [x]

08  [ENTER]

09  [g] [INTG]

10  [SWAP]

11  [g] [FRAC]

12  [ . ]

13  6

14  [ / ]

15  [+]

16  6

17  0

18  [ / ]

19  [+]

Now here is my other program that converts from decimal to DD.MMSSSS

Code:

01  [ENTER]

02  [g] [INTG]

03  [SWAP]

04  [g] [FRAC]

05  6

06  0

07  [x]

08  [ENTER]

09  [g] [INTG]

10  [EEX]

11  2

12  [ / ]

13  [SWAP]

14  [g] [FRAC]

15  6

16  0

17  [x]

18  [EEX]

19  4

20  [ / ]

21  [+]

22  [+]

I even dare say this program is better than Eddie Shore's program (I ran into his program as I was scouring the forums to check for a similar post as this one) This is because it is shorter, doesn't use any registers, and both of our (Me & Eddie) programs completely wipe any intermediate results stored in the stack before program execution. However, I can't say who's is better in the contest of speed, as I only have a modern HP-12C.

The only reason why I bring up Eddie's program is because he writes a lot of programs and seems experienced. So I'm comparing my first programs with his. And I wrote this program completely on my own, with refinements over time.

I also expect Deiter (I think I spelled his name right) to check and cirque my program. Just like with Gamo's programs.

Carsen · 01-10-2018, 05:22 AM

I just realized that programs should generally be posted in the General Software Library. I'll make sure to do so next time. I also didn't check that section of the forum for a similar post. My apologies. I'm learning.

Gamo · 01-10-2018, 06:49 AM

Thank You Carsen

That will be better to provide example for both programs.

Gamo

Dieter · (This post was last modified: 01-10-2018 10:56 AM by Dieter.)

(01-10-2018 05:18 AM)Carsen Wrote: I am inspired by Gamo to post some HP-12C programs! I have honed these 2 programs for a couple of months now. Since I collect driving times everyday, I need to convert the DD.MMSSSS into a number and vice versa.

I like the formulas shown in this thread on the old forum. The following program adapts Werner's 42s implementation.

Code:

01 ENTER

02 CLX

03 x<>y

04 x<=y?

05 GTO 23

06 ENTER

07 FRAC

08 ,

09 4

10 x

11 -

12 EEX

13 4

14 %

15 FRAC

16 2

17 5

18 0

19 /

20 -

21 CHS

22 GTO 00

23 CHS

24 ENTER

25 INTG

26 ,

27 4

28 *

29 -

30 EEX

31 2

32 *

33 ENTER

34 INTG

35 ,

36 4

37 *

38 -

39 3

40 6

41 /

42 GTO 00

Rule: values in hh.mmss format are entered and returned with negative sign.

Code:

3,1234 [R/S] => -3:07'24.24"

       [R/S] =>  3,1234 hours

 2,75  [R/S] => -2:45

-2,15  [R/S] =>  2,25

Edit: I just noticed...

(01-10-2018 05:18 AM)Carsen Wrote: I also expect Deiter (I think I spelled his name right)

Well.... but at least it sounds right if you say it in English. ;-)

(01-10-2018 05:18 AM)Carsen Wrote: to check and cirque my program. Just like with Gamo's programs.

You can still improve it. For instance, in your first program you can save two steps if you replace lines 01–04 and 08–11 (as well as the first lines of you second program) with

Code:

INTG

LSTX

FRC

In your second program you first multiply by 60 and then divide by 10000. Here a simple multiplication by ,006 will do.

And finally: welcome to the club. ;-)

Dieter

Carsen · 01-11-2018, 04:46 AM

(01-10-2018 10:37 AM)Dieter Wrote: The following program adapts Werner's 42s implementation.

Code:

01 ENTER 02 CLX 03 x<>y 04 x<=y? 05 GTO 23 06 ENTER 07 FRAC 08 , 09 4 10 x 11 - 12 EEX 13 4 14 % 15 FRAC 16 2 17 5 18 0 19 / 20 - 21 CHS 22 GTO 00 23 CHS 24 ENTER 25 INTG 26 , 27 4 28 * 29 - 30 EEX 31 2 32 * 33 ENTER 34 INTG 35 , 36 4 37 * 38 - 39 3 40 6 41 / 42 GTO 00

Rule: values in hh.mmss format are entered and returned with negative sign.

I LOVE this program simply because I don't have to switch program lines to convert from HH.MMSS to decimal and vice versa. It's pretty cool. I'll end up using this program. The formulas it uses is also unique and fun.

But I'm still going to keep and work on my own HMS programs. I made the suggested changes and that's so cool because now the program takes up one less register. I also tried to make some more amends but to no avail.

HMS to decimal program V3.

Code:

01  g INTG

02  g LSTX

03  g FRAC

04  EEX

05  2

06  x

07  g INTG

08  g LSTX

09  g FRAC

10  [ . ]

11  6

12  /

13  +

14  6

15  0

16  /

17  +

And the decimal to HMS program V3

Code:

01  g INTG

02  g LSTX

03  g FRAC

04  6

05  0

06  x

07  g FRAC

08  g LSTX

09  g INTG

10  EEX

11  2

12  /

13  SWAP

14  [ . ]

15  0

16  0

17  6

18  x

19  +

20  +

Examples Gamo? No problem. I'll use the driving times I collected today...

Example #1: Carsen's takes a trip to his job. He times himself on how fast he gets to his job and back home. Trip #1 is his venture to his job and trip #2 is his drive back home. Convert the times Carsen collected on both of his trips from HH.MMSS to decimal format. Then figure out his total time he spent getting back and forth from his job that day. Assume that the HMS to decimal prog. is entered into the 12C first. Then the decimal to HMS prog. is entered second. Thus decimal to HMS prog. starts on line #19.
Trip #1: 0 hr 55 min & 53 sec
0.5553 [R/S] ---> 0.931388889 [STO] [+] 1
Trip #2: 0 hr 53 min & 00 sec
0.53 [R/S] ---> 0.883333333 [STO] [+]. Then...
[RCL] 1 ---> 1.814722222. Finally...
[GTO] 19 [R/S] ---> 1.4853 which is 1 hr 48 min & 53 sec.

Sweet! I'm in the club!

Pekis · 01-11-2018, 06:08 AM

... and this thread for mathematical proof of my formulas, but beware of rounding Smile

...

Dieter · (This post was last modified: 01-11-2018 08:06 PM by Dieter.)

(01-11-2018 06:08 AM)Pekis Wrote: ... and this thread for mathematical proof of my formulas,

Ah, so it was you who started that thread.

(01-11-2018 06:08 AM)Pekis Wrote: but beware of rounding ...

Definitely. Calculating with base-60-numbers in the decimal world can be tricky. This reminds me of a 2016 thread where such problems were discussed in detail. Here even in such a powerful language as Fortran. But with binary floating point operations... #-)

Pekis: take a look at post #28 in the linked thread. ;-)

Carsen: here is an improved version that adapts the formulas in that thread. It also preserves the Y-register so that simple hh.mmss arithmetics can be done without storing intermediate results. And it's even one step shorter. ;-)

Code:

01 ENTER

02 CLX

03 x<>y

04 x<=y?

05 GTO 24

06 +

07 ENTER

08 FRAC

09 ,

10 4

11 x

12 -

13 EEX

14 4

15 %

16 FRAC

17 2

18 5

19 0

20 /

21 -

22 CHS

23 GTO 00

24 -

25 EEX

26 4

28 %

29 FRAC

20 1

30 5

31 0

32 /

33 +

34 ENTER

35 FRAC

36 1

37 ,

38 5

39 /

40 +

41 GTO 00

Re. your example:

Code:

-0,5553 [R/S] =>  0,913888889

-0,5300 [R/S] =>  0,883333333

         [+]  =>  1,814722222

        [R/S] => -1,4853

Dieter

Pekis · 01-11-2018, 09:22 PM

...
Could you show the result of converting 8/60 to HMS with your program
? It's the "acid" test ... Smile

Thanks

Dieter · (This post was last modified: 01-12-2018 09:49 AM by Dieter.)

(01-11-2018 09:22 PM)Pekis Wrote: ...
Could you show the result of converting 8/60 to HMS with your program
? It's the "acid" test ...
Thanks

The program returns -0,07599999999. Which is displayed as -0,0760. ;-)
But actually this is the correct (!) result. Here's why:

You do not enter 8/60, but 0,1333333333 – a number slightly less than 8/60. And the exact HMS value for this is 7'59,99999988" which is correctly rounded to 7'59,9999999".

Try it: 0,1333333333 h times 3600 s/h equals 479,99999988 s. Or 7 minutes and 59,99999988 seconds. Which is what the above implementation returns.
For the same reason HMS(7/60) should (and here does) return 7'00,0000001" on a 10-digit calculator. Simply because 0,1166666667 is a tiny bit more than 7/60.

So yes, this indeed is an acid test: if the result is exactly 8'00" or 7'00" the function would be wrong and do some kind of "cosmetic rounding". Which is not what a decent calculator should do. ;-)

Dieter

Pekis · 01-12-2018, 12:36 PM

Thanks for the answer.

DEG->DMS(8/60) would be evaluated as 0.08 (expected result) on an infinite precision machine with my formula

DEG->DMS(x)=(90*x+INT(60*x)+100*INT(x))/250
( DMS->DEG(x)=(250*x-INT(100*x)-60*INT(x))/90 )

Look at the result on a limited precision machine as the argument tends to 8/60:
0.13 ---> 0.0748
0.133 ---> 0.07588
0.1333 ---> 0.075988
0.13333 ---> 0.0759988
0.133333 ---> 0.07599988
0.1333333 ---> 0.075999988
...
"8/60" ---> 0.076

Is there something wrong seeing 0.075999999999.... naturally rounded to 0.076 by the machine ?

What do you think of it ?

Dieter · 01-12-2018, 12:50 PM

(01-12-2018 12:36 PM)Pekis Wrote: Thanks for the answer.

Which one?

(01-12-2018 12:36 PM)Pekis Wrote: Is there something wrong seeing 0.075999999999.... naturally rounded to 0.076 by the machine ?

If the result actually was exactly 7'60" I'd say that this should not occur. But here we are talking about 0,07599999999 which is only displayed as 0,0760. And that's fine by me: it can even serve as a hint that the result is a tiny bit less than 8 minutes. ;-)

Dieter

Carsen · 01-13-2018, 01:26 AM

(01-11-2018 07:03 PM)Dieter Wrote: Carsen: here is an improved version that adapts the formulas in that thread. It also preserves the Y-register so that simple hh.mmss arithmetics can be done without storing intermediate results. And it's even one step shorter. ;-)

Code:

01 ENTER 02 CLX 03 x<>y 04 x<=y? 05 GTO 24 06 + 07 ENTER 08 FRAC 09 , 10 4 11 x 12 - 13 EEX 14 4 15 % 16 FRAC 17 2 18 5 19 0 20 / 21 - 22 CHS 23 GTO 00 24 - 25 EEX 26 4 28 % 29 FRAC 20 1 30 5 31 0 32 / 33 + 34 ENTER 35 FRAC 36 1 37 , 38 5 39 / 40 + 41 GTO 00

Dieter! This. New. Version. Is. Amazing. Thanks a lot.

And I'm sure you know why its so cool. Preserving the Y register is SO useful for what I do 5 days a week, collecting that sort of data. And rather than using my 50g, the Voyager series is just perfect with its size and power consumption.