8/60 -> HMS



#49

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


#50

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.

#51

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.

#52

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.

#53

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.

#54

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.

#55

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


#56

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.


#57

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.


#58

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.


#59

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

#60

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

#61

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

#62

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

#63

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

#64

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


#65

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.


#66

Rounding away from zero?

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


Pauli


#67

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.


#68

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

#69

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


#70

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.


#71

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


#72

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


#73

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

#74

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.


#75

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


#76

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


#77

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

#78

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

#79

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.

#80

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


#81

0.01 (or 0°1'40")

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

d:-)


#82

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 .

#83

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


#84

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


#85

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.


#86

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

#87

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


#88

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

Gerson.

#89

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

#90

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.

#91

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


#92

The ultimate answer is obvious!

It's time for Metric Time!

Mark Hardman


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

#93

->HMS
RND
0
HMS+

Does it too.


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

#94

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.


#95

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


#96

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


Possibly Related Threads...
Thread Author Replies Views Last Post
  HMS commands Geoff Quickfall 6 283 10-14-2013, 06:27 PM
Last Post: Tim Wessman
  OT--TI's SR-60 Matt Agajanian 8 369 04-25-2012, 11:34 AM
Last Post: Joerg Woerner
  Re: more HMS, aTIME, 34s display, 41c bugs? Christopher Johnson 0 90 03-05-2012, 11:20 AM
Last Post: Christopher Johnson
  more HMS, aTIME, 34s display, 41c bugs? Christopher Johnson 2 143 02-25-2012, 10:06 PM
Last Post: Luiz C. Vieira (Brazil)
  wp 34s vs 41c hms+ Christopher Johnson 9 308 02-23-2012, 10:04 AM
Last Post: Christopher Johnson
  H to HMS Bug in HP 15C LE? Eddie W. Shore 2 145 09-26-2011, 11:22 AM
Last Post: Eddie W. Shore
  adding time segmetns (HMS+)?? with 41CX? Sam Samaha 15 497 02-23-2011, 01:22 AM
Last Post: Ángel Martin
  HMS+, HMS-, HMS, HR: LEX files Geoff Quickfall 2 149 12-12-2010, 03:52 PM
Last Post: Geoff Quickfall
  Formulas for ->HMS & ->HR Pekis 0 91 06-08-2008, 05:48 PM
Last Post: Pekis
  HMS+ / HMS- implementation. Alex L 10 387 02-12-2008, 10:12 AM
Last Post: Alex L

Forum Jump: