The Museum of HP Calculators

HP Forum Archive 21

[ Return to Index | Top of Index ]

8/60 -> HMS
Message #1 Posted by PGILLET on 1 May 2013, 5:11 p.m.

Hello, Could you try this on your hp in fix 4 display ? 8 enter 60 / ->HMS It seems that some hp show 0.0760 and other .0800 (correct answer, as by Hp15c ?). Do you confirm ? Thanks

      
Re: 8/60 -> HMS
Message #2 Posted by Gilles Carpentier on 1 May 2013, 5:29 p.m.,
in response to message #1 by PGILLET

HP50G, FIX4

8 enter 60 / ->HMS

0.0760 :O it looks like a rounding pb

Idem with my old 48SX

Edited: 1 May 2013, 5:42 p.m.

      
Re: 8/60 -> HMS
Message #3 Posted by Paul Berger (Canada) on 1 May 2013, 7:19 p.m.,
in response to message #1 by PGILLET

32SII = 0.0760
67, 97 and 41CX = 0.0800
28C also gives 0.0760 so it is likely all Saturn based calculators will return this result.

Edited: 1 May 2013, 7:44 p.m.

      
Re: 8/60 -> HMS
Message #4 Posted by Reth on 1 May 2013, 7:59 p.m.,
in response to message #1 by PGILLET

0.0760 is correct answer as it is 0.0800 :)

The "less accurate" HP41 or HP15 give 0.0800, others 0.0760, but subtract 0.076 from the result and see if you get 0.

      
Re: 8/60 -> HMS
Message #5 Posted by bhtooefr on 1 May 2013, 8:09 p.m.,
in response to message #1 by PGILLET

Emulated calcs for everything here using this OS X port of nonpareil, except the 41 (emulated in X-41), 50g, and MK-61 (real hardware)...

I think nonpareil does mess with the display a bit on Classics, condensing the decimal point. Also, on the Classics, I've run with sci 9 as well. Everything else doesn't have a big enough screen to give any more digits (except the 50g, which automatically returned a sci 11 result in standard mode).

Classic:

45: 0.0800 (fix 9 and sci 9 actually return the same fix *4* result)
55: .0760 (fix 9 returns .076000000, sci 9 returns 7.599999998-02)

Woodstock/Spice:

25: 0.0760 (fix 9 returns 0.075999400)
32E, 33C, 34C: 0.0800 (fix 9 returns 0.080000000)

Nut:

41CV (unknown ROM, it's X-41 version 1.0): 0.0800 (fix 9 returns 0.080000000)

Voyager:

11C/15C: 0.0800 (fix 9 returns 0.080000000)

And, for grins, on my real 50g running firmware 2.15:

Standard: 7.59999999999E-2
Fix 4: 0.0760
Fix 11: 0.07600000000

As an aside (not even an HP here), while the MK-61 doesn't do fixed, just a bastardized standard (it actually has trouble with numbers less than 1 and likes to drop into scientific, although it got this one with one leading zero), it returned 0.8 -01.

In any case, doesn't seem like the display format changes anything (and I'm not surprised by that - HPs do the math at full internal precision at all times).

Edited: 1 May 2013, 8:19 p.m.

      
Re: 8/60 -> HMS
Message #6 Posted by Thomas Klemm on 1 May 2013, 8:37 p.m.,
in response to message #1 by PGILLET

Quote:
8 enter 60 /

Please keep in mind that you don't enter the exact value of 8/60 here. Instead with the HP-15C it is a 10-digit mantissa: 

1.333333333 e -1

Now multiply that by 3600 and you'll get: 

479.9999999

This is the exact result 479.99999988 rounded correctly to 10 digits. Therefore the correct answer using ->H.MS with that value should be: 

7.599999999 e -2

With FIX 4 display this will be shown as: 

0.0760

Thus the HP-15C doesn't give the correct answer here.

Cheers
Thomas

Compare that to what's happening when using the double of that value: 
2.666666666 e -1

Multiplied by 3600 we get: 

959.9999998

This is the exact result 959.99999976 rounded correctly to 10 digits.

Now in this case we expect 2 digits for the minutes thus we have to round the seconds to 6 places. This gives 960.000000 and thus we end up with: 

0.16

Another interesting value is: 

1.666666666 e -1

Multiplied by 3600 we get: 

599.9999998

If we assume 2 digits for the minutes we have to round that to 600.000000 which leads to 10 minutes. However if we assume only one digit for the minutes we don't have to round and end up with: 

9.599999998 e -2

This is kind of a paradox situation.

Edited: 1 May 2013, 9:45 p.m.

      
Re: 8/60 -> HMS
Message #7 Posted by Paul Dale on 1 May 2013, 8:46 p.m.,
in response to message #1 by PGILLET

I think the correct result here is 0.0760.

8 / 60 = 0.1333333333333...

This rounds down to 0.1333333333 (assuming 10 digits here).

Converting this to HMS gives 0.07599999999 exactly. On display this rounds to 0.0760. This display doesn't know the number is in HMS style, it is just a number.

On the 34S, 8 ENTER 60 / ->H.MS produces 0.07599999999999999 which displays as 0.0760. However, 8 ENTER 60 / H.MS displays 0o 8' 0.00". The difference in the latter is because the calculator knows that the number is H.MS formatted.

- Pauli

            
Re: 8/60 -> HMS
Message #8 Posted by Paul Berger (Canada) on 1 May 2013, 9:22 p.m.,
in response to message #7 by Paul Dale

Am I wrong thinking that is I have a decimal number of hours and if I multiply the fractional part by 60 I should get the number of minutes and if I take the fractional part of that number and multiply it by 60 I would get the number of seconds?
on 48GX 8/60 = 0.133333333333 and if I multiply that by 60 I get 7.99999999998 drop the int part and multiply by 60 and I get 59.9999999988 which will round up to 60 or 1 full minute and give me an answer of 0.0800.

                  
Re: 8/60 -> HMS
Message #9 Posted by Thomas Klemm on 1 May 2013, 9:39 p.m.,
in response to message #8 by Paul Berger (Canada)

Quote:
I get 59.9999999988 which will round up to 60

The question is: round up to how many places? Since only one additional digit to display 7 is needed this will be rounded to 59.999999999.

                        
Re: 8/60 -> HMS
Message #10 Posted by Paul Berger (Canada) on 1 May 2013, 9:59 p.m.,
in response to message #9 by Thomas Klemm

OK but the question was for 4 decimal places which would just show minutes and seconds and in that case it would surely round up to 60 seconds, which for a HMS display I would think should roll up to the next minute which in the case of the original question should give a result of 0.0800. In fact in fix 4 mode it does get rounded to 60, and 8 enter 60 / 60 * =8 to no one surprise. To look at it another way 8/60ths of an hour is 8 minutes so if we are displaying the number in H.MS mode why would the result be anything other than 0.0800? Well technically I guess 0.0760 or 7 minutes and 60 seconds is the same thing but it is a bit odd of a way to present it.

                              
Re: 8/60 -> HMS
Message #11 Posted by Paul Dale on 1 May 2013, 11:14 p.m.,
in response to message #10 by Paul Berger (Canada)

These calculators never round to the display settings during their computations. Thus, the display setting should have no impact on the result.

Would you really want a calculator that returned exactly 3.1416 for PI when displaying in fix 4? I wouldn't.

- Pauli

                  
Re: 8/60 -> HMS
Message #12 Posted by Paul Dale on 1 May 2013, 11:18 p.m.,
in response to message #8 by Paul Berger (Canada)

Quote:
Am I wrong thinking that....

Yes :-)

The H.MS conversions are very tricky to get right. Well, the HR -> H.MS conversion is. The obvious method works for the reverse.

Lots of care needs to be taken to round things off properly and deal with the resulting carries between the fields.

Getting these correct on the 34S took way too much time and effort. That is assuming that I did get them correct.

- Pauli

      
Re: 8/60 -> HMS
Message #13 Posted by Paul Berger (Canada) on 1 May 2013, 8:58 p.m.,
in response to message #1 by PGILLET

Interesting it only seems to mess up on that one value 68/60->HMS gives the correct answer of 1.08 and 128/60->HMS gives me 2.08. My Commodore PR-100 is more consistent it gets them all wrong 0.0760 1.0760 2.0760 etc... as does the TI-59

      
Re: 8/60 -> HMS
Message #14 Posted by Gerson W. Barbosa on 1 May 2013, 10:44 p.m.,
in response to message #1 by PGILLET

On my HP-71B I get 0.0800, exactly ;-) 

>FIX 4
>LIST
10 A=8/60 @ T=ABS(FP(A))+.0000000005 @ DISP SGN(A)*(ABS(IP(A))+IP(60*T)/100+IP(MOD(3600*T,60)))
>RUN
 0.0800
            
Re: 8/60 -> HMS
Message #15 Posted by BShoring on 2 May 2013, 1:05 a.m.,
in response to message #14 by Gerson W. Barbosa

I get 0.800 on two emulators for iOS: HP-25C and HP-45. Both have 14-15 digit internal accuracy.

      
Re: 8/60 -> HMS
Message #16 Posted by Thomas Klemm on 2 May 2013, 1:57 a.m.,
in response to message #1 by PGILLET

For very small values the ->H.MS translation should be just a multiplication by the factor 0.36. So for instance 1E-10 will lead to 3.6E-11. However with the HP-15C the value 2.777777777E-10 will be translated to 1.000000000E-10 while the result of the multiplication is 9.999999997E-11. Thus there is some additional rounding that we don't see with the HP-48GX.

Cheers
Thomas

            
Re: 8/60 -> HMS
Message #17 Posted by Gerson W. Barbosa on 2 May 2013, 2:09 a.m.,
in response to message #16 by Thomas Klemm

On the HP-42S, this workaround appears to work: 

00 { 18-Byte Prgm }
01 LBL "HMS"
02 ENTER
03 SIGN 
04 1E-12
05 *
06 +
07 ->HMS
08 END

Gerson.

                  
Re: 8/60 -> HMS
Message #18 Posted by Paul Dale on 2 May 2013, 2:14 a.m.,
in response to message #17 by Gerson W. Barbosa

Rounding away from zero?

I'm certain there would be cases where this is broken too :(

Pauli

                        
Re: 8/60 -> HMS
Message #19 Posted by Gerson W. Barbosa on 2 May 2013, 9:46 a.m.,
in response to message #18 by Paul Dale

Quote:
I'm certain there would be cases where this is broken too :(

1e-11 instead of 1e-12 might be safer. Anyway, this appears to work if our goal is an answer in HH.MMSS format. So far I haven't seen an example this didn't work for, but perhaps I just haven't tried hard enough :-)

Gerson.

                              
Re: 8/60 -> HMS
Message #20 Posted by Paul Dale on 2 May 2013, 5:36 p.m.,
in response to message #19 by Gerson W. Barbosa

0.133333333332 trivially breaks the 1e-12 adjustment.

I'd suspect, but haven't tested, that 0.133333333323 would break the 1e-11 alternative.

There will be less contrived examples too.

- Pauli

                  
Re: 8/60 -> HMS
Message #21 Posted by Thomas Klemm on 2 May 2013, 6:28 a.m.,
in response to message #17 by Gerson W. Barbosa

Quote:
this workaround appears to work

On my HP-42S I get the following results: 

2.77777777777E-10      |   2.77777777777E-10
->HMS                  |   ENTER
                       |   0.36
                       |   *
                       |
9.99999999996E-11      |   9.99999999997E-11

Okay, close enough!

With your program "HMS" I get: 

2.77777777777E-10
HMS

1.0036E-10

Could you elaborate on how this is a "workaround"? Workaround for what?

Can we agree that HP-42S provides the correct result and both HP-41C and HP-15C don't?

Cheers
Thomas

                        
Re: 8/60 -> HMS
Message #22 Posted by Gerson W. Barbosa on 2 May 2013, 8:26 a.m.,
in response to message #21 by Thomas Klemm

Quote:
Could you elaborate on how this is a "workaround"? Workaround for what?

Can we agree that HP-42S provides the correct result and both HP-41C and HP-15C don't?

Well, I agree 7 minutes and 60 seconds is equivalent to 8 minutes, but this is not acceptable in HH.MMSS or DDD.MMSS formats. Incidentally I had the same problem in this HP-71B program. I solved it by changing slightly the argument before performing the conversion. This is the line 320 of my original CASIO PB-700 program: 

 320 B=B+.00014:T=FR
ACB:M=INT(60*T):S=(3
600*T) MOD 60:RETURN
For that particular purpose, I believe this is a valid workaround.

Cheers,

Gerson.

                              
Re: 8/60 -> HMS
Message #23 Posted by Thomas Klemm on 2 May 2013, 11:46 a.m.,
in response to message #22 by Gerson W. Barbosa

What should happen using FIX 2 with the following value: 

7.5953

Should it magically be displayed as: 

8.00

And if not, why is your expectation different in the case of FIX 4?

Cheers
Thomas

Edit: typo and added missing name

Edited: 2 May 2013, 1:16 p.m. after one or more responses were posted

                                    
Re: 8/60 -> HMS
Message #24 Posted by Dieter on 2 May 2013, 1:02 p.m.,
in response to message #23 by Thomas Klemm

That's exactly the point. For the calculator, "0,07599999999" is a simple real number like any other and thus is correctly displayed as "0,0760" in FIX 4 mode.

Calculators with special formatting options for values that should be interpreted as h.ms may behave differently. For instance the 34s. It displays HMS(8/60) = 0,07599999999999999 correctly as 0,076 or 0,0760. But it also features a special h.ms (resp. d.ms) display mode that returns 0° 8' 0,00" instead.

Dieter

                                          
Re: 8/60 -> HMS
Message #25 Posted by Tim Wessman on 2 May 2013, 1:08 p.m.,
in response to message #24 by Dieter

Yup, that is the same thing used in the 39gII and Prime. The reals can have a flag that causes them to be displayed in the different format. It also allows you to do things like use HMS formatted numbers directly in angles, embed them in other locations and similar things the simple handling found on things like the 48 just don't allow.

TW

                                    
Re: 8/60 -> HMS
Message #26 Posted by Gerson W. Barbosa on 2 May 2013, 2:48 p.m.,
in response to message #23 by Thomas Klemm

I see you point, but looks like you don't see mine. I can accept 0.0760 is the mathematically correct FIX 4 result but I want my program to display 0.0800 because that's what I should expect in HH.MMSS format, for the given example. If the built-in ->HMS function doesn't behave the way I want, then I think a workaround is needed.

Best regards,

Gerson.

                                          
Re: 8/60 -> HMS
Message #27 Posted by Paul Dale on 2 May 2013, 5:41 p.m.,
in response to message #26 by Gerson W. Barbosa

To get the correctly rounded answer, you'll have to invest quite a few more steps.

First, round the 0.0759999.... result to exactly 0.0760 by setting the display mode and rounding.

Second, manually correct the seconds portion. This means detecting the >= 60 case, adding a minute and removing the sixty seconds.

Finally, manually correct the minutes portion in the same manner. Thrown together and completely untested code to do just the minures portion:

    ENTER
    FP
    100
    *
    60
    x>y?
    GTO 00
    XEQ 00
    .04
    +
    RTN

    LBL 00
    Rv
    Rv
    RTN

- Pauli

                                                
Re: 8/60 -> HMS
Message #28 Posted by Gerson W. Barbosa on 2 May 2013, 6:45 p.m.,
in response to message #27 by Paul Dale

There's another approach I used in the QBASIC version of the subroutine, in the program in the link above. The HP-71B version is so much shorter I am loathe to discard it, but this will have to be done if I run into an invalid result. I am thinking of generating say, 60 thousand arguments, and look for results returning M=60. If none is found, ok, otherwise dustbin...

Gerson.

------------------------- 

HP-71B:

319 REM ->HMS
320 T=FP(B)+.000000005 @ M=INT(60*T) @ S=INT(MOD(3600*T,60)) @ RETURN

QBASIC:

319 ' ->HMS
320 T = FNFRAC(AN): M = INT(60 * T): S = FNFRAC(((3600 * T) / 60)) * 60
323 IF INT(S + .5) = 60 THEN S = 0: M = M + 1
325 IF M = 60 THEN M = 0: AN = AN + 1
328 RETURN

                                                      
Re: 8/60 -> HMS
Message #29 Posted by Paul Dale on 2 May 2013, 7:30 p.m.,
in response to message #28 by Gerson W. Barbosa

The QBASIC code is essentially what the 34S does. I'm not sure how stable this will be in binary arithmetic, but in decimal is should be fine.

I used a greater or equal test instead of an equality just in case really bad stuff happens.

- Pauli

                                                
Re: 8/60 -> HMS
Message #30 Posted by Dieter on 3 May 2013, 3:24 p.m.,
in response to message #27 by Paul Dale

Pauli, sometimes life is easier than you might expect. ;-)

Quote:
Second, manually correct the seconds portion. This means detecting the >= 60 case, adding a minute and removing the sixty seconds. Finally, manually correct the minutes portion in the same manner. Thrown together and completely untested code to do just the minures portion:
Here's my alternative code: 
  0
  H.MS+
Somewhat shorter, and it (usually) does the trick. At least the calculators I know of are smart enough to handle minutes and seconds >= 60.

Example: 

    2,8465      i.e. 2 hours, 84 minutes and 65 seconds
    0 [H.MS+]
 => 3,2505      i.e. 3 hours, 25 minutes and 5 seconds
Or, in our case: 
    0,0760
    0 [H.MS+]
 => 0,0800
Dieter
                                                      
Re: 8/60 -> HMS
Message #31 Posted by Gerson W. Barbosa on 3 May 2013, 4:29 p.m.,
in response to message #30 by Dieter

Quote:
Here's my alternative code: 
  0
  H.MS+

Very nice!

Quote:
Somewhat shorter, and it (usually) does the trick.

For the OP's example, 8/60, the display mode should be selected to FIX 4 or greater, then the argument should be rounded to the number of digits in the display first: 

00 { 12-Byte Prgm }
01 LBL "HMS"
02 ->HMS
03 RND
04 0
05 HMS+
06 END

FIX 4
8 ENTER
60 / 
XEQ HMS  -->  0.0800

Regards,

Gerson.

                                          
Re: 8/60 -> HMS
Message #32 Posted by Kiyoshi Akima on 3 May 2013, 4:13 p.m.,
in response to message #26 by Gerson W. Barbosa

Just out of curiosity, in FIX 2 what would you expect to see for 36 1/x ->H.MS ?

                                                
Re: 8/60 -> HMS
Message #33 Posted by Walter B on 3 May 2013, 4:40 p.m.,
in response to message #32 by Kiyoshi Akima

0.01 (or 0°1'40")

Remember ->H.MS doesn't round to minutes - actually, it makes sense with FIX 4 only.

d:-)

                                                      
Re: 8/60 -> HMS
Message #34 Posted by Kiyoshi Akima on 3 May 2013, 8:37 p.m.,
in response to message #33 by Walter B

Quote:
actually, it makes sense with FIX 4 only.
Are you saying it doesn't make sense with FIX greater than 4? I always assumed it was capable of displaying decimal seconds. For example, 7 minutes 59.75 seconds would show as 0.075975 in FIX 6. Which in FIX 4 displays as 0.0760 and not as 0.0800 .
                                                            
Re: 8/60 -> HMS
Message #35 Posted by Walter B on 4 May 2013, 1:26 a.m.,
in response to message #34 by Kiyoshi Akima

Point taken :-) I should have written FIX 6 instead. Nevertheless, abusing standard decimal numbers for H.MS displays is suboptimal. Thus we invented the 'H.MS display mode' for the WP 34S (see p. 52) which - hopefully - does it right.

d:-)

                                                                  
Re: 8/60 -> HMS
Message #36 Posted by Paul Dale on 4 May 2013, 1:29 a.m.,
in response to message #35 by Walter B

Quote:
Point taken :-) I should have written FIX 6 instead. Nevertheless, abusing standard decimal numbers for H.MS displays is suboptimal. Thus we invented the 'H.MS display mode' for the WP 34S (see p. 52) which - hopefully - does it right.

The 34S's HMS mode (really DMS mode) does get this right. The ->H.MS function also gets the correct result even though the two are different.

What about FIX 5 or FIX 7 for tenths or thousandths of a second.

- Pauli

                                                                        
Re: 8/60 -> HMS
Message #37 Posted by Gerson W. Barbosa on 4 May 2013, 2:15 a.m.,
in response to message #36 by Paul Dale

I've just noticed that 

0.076 ENTER 0 H.MS+
as in Dieter's suggestion above, returns 0.076 on my WP-34S. Shouldn't 0.08 be preferable?

Gerson.

                                                                              
Re: 8/60 -> HMS
Message #38 Posted by Paul Dale on 4 May 2013, 3:15 a.m.,
in response to message #37 by Gerson W. Barbosa

Seems to work okay here.

        FIX 04  8  ENTER  60  /  ->H.MS  RND  0  H.MS+

Results in 0.0800 on the display for me.

Firmware revision 3344 in single precision mode.

- Pauli

                                                                              
Re: 8/60 -> HMS
Message #39 Posted by Paul Dale on 4 May 2013, 3:19 a.m.,
in response to message #37 by Gerson W. Barbosa

What display mode are you using?

        0.076 ENTER 0 H.MS+

Produces 0.0800 in FIX 04 mode here. Likewise in ALL mode.

What firmware revision are you using? There have been a number of nasty bugs in the H.MS code over time. Like I wrote earlier, these functions are hard to get right.

- Pauli

                                                                                    
Re: 8/60 -> HMS
Message #40 Posted by Gerson W. Barbosa on 4 May 2013, 12:46 p.m.,
in response to message #39 by Paul Dale

Same here (3382). Previously I'd forgotten to do the rounding after 8 60 /. Sorry!

Gerson.

                                                                        
Re: 8/60 -> HMS
Message #41 Posted by Walter B on 4 May 2013, 5:16 a.m.,
in response to message #36 by Paul Dale

Quote:
What about FIX 5 or FIX 7 for tenths or thousandths of a second.
Every display format from FIX 5 on should work correctly since the usual rounding applies ...

d:-)

                                                
Re: 8/60 -> HMS
Message #42 Posted by Gerson W. Barbosa on 3 May 2013, 5:00 p.m.,
in response to message #32 by Kiyoshi Akima

1/36 of an hour is 1/36*3600 seconds, that is, 100 seconds exactly, or 1 minute and 40 seconds. The H.MMSS format requires FIX 4 or greater by definition. It has never occurred to me using fix 2 in this situation. Anyway, assuming I didn't care about the seconds, I would expect minutes to be rounded up to the next minute when the number of seconds is 30 or greater. Since the rounding occurs when seconds are greater or equal 50, FIX 2 is useless to me, in this case.

                                                
Re: 8/60 -> HMS
Message #43 Posted by Kiyoshi Akima on 3 May 2013, 8:44 p.m.,
in response to message #32 by Kiyoshi Akima

I think that makes my point, what little there was of it. The first response said one minute, the second said two minutes.

Ah, the joys of sexagesimal notation. I suppose it's a good thing HP calculators don't have built-in modes for displaying something like "one mile thirteen yards two feet five and three-quarters inches" or "three pounds seven shillings eleven pence" :-)

                                                      
Re: 8/60 -> HMS
Message #44 Posted by Mark Hardman on 3 May 2013, 10:34 p.m.,
in response to message #43 by Kiyoshi Akima

The ultimate answer is obvious!

It's time for Metric Time!

Mark Hardman

Edited: 3 May 2013, 10:38 p.m.

                  
Re: 8/60 -> HMS
Message #45 Posted by Reth on 4 May 2013, 6:24 p.m.,
in response to message #17 by Gerson W. Barbosa

->HMS
RND
0
HMS+

Does it too.

Edited: 4 May 2013, 6:27 p.m.

      
Re: 8/60 -> HMS
Message #46 Posted by Thomas Klemm on 4 May 2013, 6:45 a.m.,
in response to message #1 by PGILLET

Since I was curious how the HP-41C handles this transformation I had a glance at the source code. It all boils down to the following steps: The subroutine HMSMP is called twice. In between the pointer PT is moved 2 places to the right (DEC PT): 

   544  716           1 GOSUB  HMSMP
   544  717           0
   545  720        1724 DEC PT
   546  721 HMS160 1724 DEC PT
   547                  LEGAL
   548  722           1 GOSUB  HMSMP

This subroutine HMSMP multiplies the register C with 0.6 (unless S5 is set): 

   565  747 HMSMP   412 A=C    WPT                     ; A = C
   566  750        1712 C SR   WPT                     ; shift right C => C = 0.1 * A
   567  751         752 C=C+C  WPT                     ; C = 0.2 * A
   568  752         752 C=C+C  WPT                     ; C = 0.4 * A
   569  753        1112 C=A-C  WPT                     ; C = A - 0.4 * A = 0.6 * A
   570  754         214 ?S5=1                          
   571  755          63 GONC   HMSM20 ( 763)           
   572  756          16 A=0    W                       ; clear the whole word
   573  757         406 A=C    X                       ; copy the last digit
   574  760        1016 C=A+C  W                       ; adding the last digit rounds the result
   575  761         106 C=0    X                       ; clear the last digit
   576  762        1740 RTN

Let's have a look at how this works for the example 0.21: 

                   P            
               C: 02100000000000
A=C    WPT     A: 02100000000000

C SR   WPT     C: 00210000000000

C=C+C  WPT     C: 00420000000000

C=C+C  WPT     C: 00840000000000

C=A-C  WPT     C: 01260000000000

I'll skip the rounding here and just continue to the 2nd call of HMSMP. Please note that the pointer P is now shifted 2 places to the right: 

   545  720        1724 DEC PT
   546  721 HMS160 1724 DEC PT

Thus the operations won't affect digits left to P: 

                     P            
               C: 01260000000000
A=C    WPT     A: 00060000000000

C SR   WPT     C: 01206000000000

C=C+C  WPT     C: 01212000000000

C=C+C  WPT     C: 01224000000000

C=A-C  WPT     C: 01236000000000

Thus we end up with the result 0.1236 interpreted as 0:12'36".

Now let's have a look at what's happening with 8/60: 

                   P            
               C: 01333333333000
A=C    WPT     A: 01333333333000

C SR   WPT     C: 00133333333300

C=C+C  WPT     C: 00266666666600

C=C+C  WPT     C: 00533333333200

C=A-C  WPT     C: 00799999999800

The next steps deal with the rounding: 

                   P            
               C: 00799999999800
A=0    W       A: 00000000000000

A=C    X       A: 00000000000800

C=A+C  W       C: 00800000000600

C=0    X       C: 00800000000000

The next call to HMSMP doesn't change anything on that result. Thus we end up with 0.08 which is interpreted as 0:08'00".

That's the point where the value 7999999998 is rounded to 9 places.

Kind regards
Thomas

VASM ROM ASSEMBLY

   510                  ENTRY  XTOHRS
   511                  ENTRY  HMSMP
   512                  ENTRY  HMSDV
************************************************
*    IF TO H.MMSS, THEN S5=1                   *
*    IF TO H.DDDD, THEN S5=0                   *
************************************************
   517  662 XTOHRS 1372 ? C#0  M
   518  663        1640 RTN NC
   519  664         416 A=C    W
   520  665         216 B=A    W
   521  666        1046 C=C+1  X
   522  667        1046 C=C+1  X
   523  670         406 A=C    X
   524  671        1534 PT=    12
   525  672         506 A=A+C  X
   526  673         107 GOC    HMS140 ( 703)
   527  674 HMS110 1724 DEC PT
   528  675        1624 ? PT=  0
   529  676          33 GONC   HMS130 ( 701)
   530  677 HMS120  316 C=B    W
   531  700        1740 RTN
   532  701 HMS130 1146 C=C-1  X
   533  702        1723 GONC   HMS110 ( 674)
   534  703 HMS140  116 C=0    W
   535  704         332 C=B    M
   536  705         214 ?S5=1
   537  706         223 GONC   HRS100 ( 730)
   538  707        1734 INC PT
   539  710        1324 ? PT=  13
   540  711          43 GONC   HMS150 ( 715)
   541  712           1 GOSUB  HMSMP
   541  713           0
   542  714          53 GOTO   HMS160 ( 721)
   543  715 HMS150 1734 INC PT
   544  716           1 GOSUB  HMSMP
   544  717           0
   545  720        1724 DEC PT
   546  721 HMS160 1724 DEC PT
   547                  LEGAL
   548  722           1 GOSUB  HMSMP
   548  723           0
   549  724         416 A=C    W
   550  725         316 C=B    W
   551  726 HMS170    1 GOLONG MPY150
   551  727           2
   552  730 HRS100   16 A=0    W
   553  731           1 GOSUB  HMSDV
   553  732           0
   554  733        1734 INC PT
   555  734        1324 ? PT=  13
   556  735          27 GOC    HRS120 ( 737)
   557  736        1734 INC PT
   558  737 HRS120    1 GOSUB  HMSDV
   558  740           0
   559  741        1756 A SL   W
   560  742         516 A=A+C  W
   561  743         356 BC EX  W
   562  744        1623 GOTO   HMS170 ( 726)
   563  745 HMSDV  1712 C SR   WPT
   564  746        1012 C=A+C  WPT
   565  747 HMSMP   412 A=C    WPT
   566  750        1712 C SR   WPT
   567  751         752 C=C+C  WPT
   568  752         752 C=C+C  WPT
   569  753        1112 C=A-C  WPT
   570  754         214 ?S5=1
   571  755          63 GONC   HMSM20 ( 763)
   572  756          16 A=0    W
   573  757         406 A=C    X
   574  760        1016 C=A+C  W
   575  761         106 C=0    X
   576  762        1740 RTN
   577  763 HMSM20  512 A=A+C  WPT
   578  764        1712 C SR   WPT
   579  765        1352 ? C#0  WPT
   580  766        1757 GOC    HMSM20 ( 763)
   581  767        1740 RTN

Edited: 4 May 2013, 7:06 a.m.

            
Re: 8/60 -> HMS
Message #47 Posted by PGILLET on 4 May 2013, 7:54 a.m.,
in response to message #46 by Thomas Klemm

Brilliant ! That shows that proper rounding was considered as necessary by hp for the famous hp-41 (and hp-15c I presume). Thanks :-)

                  
Re: 8/60 -> HMS
Message #48 Posted by Thomas Klemm on 4 May 2013, 11:38 a.m.,
in response to message #47 by PGILLET

Sure they did, but in this special case you mentioned in the original post (i.e. 1.333333333E-1) they got it wrong: 7999999998 has 10 significant digits so there's no reason to round that to 9 digits. Just from looking at the code I understand that they didn't want to handle that special case. Or maybe they didn't realize it is a glitch or they even considered it a benefit since the result is what people probably expect.

Now I'd have to check in the source code of the HP-48 why it behaves differently. Do we have access to that?

Cheers
Thomas

[ Return to Index | Top of Index ]

Go back to the main exhibit hall