8/60 -> HMS

[PGILLET]

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

[Gilles Carpentier]

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.

[Paul Berger (Canada)]

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.

[Reth]

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.

[bhtooefr]

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.

[Thomas Klemm]

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.

[Paul Dale]

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 0^o 8' 0.00". The difference in the latter is because the calculator knows that the number is H.MS formatted.

- Pauli

[Paul Berger (Canada)]

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.

[Thomas Klemm]

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.

[Paul Berger (Canada)]

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.

[Paul Dale]

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

[Paul Dale]

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

[Paul Berger (Canada)]

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

[Gerson W. Barbosa]

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

[BShoring]

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

[Thomas Klemm]

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

[Gerson W. Barbosa]

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.

[Paul Dale]

Rounding away from zero?

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

Pauli

[Gerson W. Barbosa]

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.

[Paul Dale]

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

[Thomas Klemm]

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

[Gerson W. Barbosa]

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.

[Thomas Klemm]

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

[Dieter]

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

[Tim Wessman]

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

[Gerson W. Barbosa]

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.

[Paul Dale]

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

[Gerson W. Barbosa]

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

[Paul Dale]

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

[Dieter]

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

[Gerson W. Barbosa]

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.

[Kiyoshi Akima]

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

[Walter B]

0.01 (or 0°1'40")

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

d:-)

[Kiyoshi Akima]

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 .

[Walter B]

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:-)

[Paul Dale]

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

[Gerson W. Barbosa]

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.

[Paul Dale]

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

[Paul Dale]

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

[Gerson W. Barbosa]

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

Gerson.

[Walter B]

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:-)

[Gerson W. Barbosa]

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.

[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" :-)

[Mark Hardman]

The ultimate answer is obvious!

It's time for Metric Time!

Mark Hardman

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

[Reth]

->HMS

RND

0

HMS+

Does it too.

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

[Thomas Klemm]

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.

[PGILLET]

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

[Thomas Klemm]

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