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
8/60 > HMS


« Next Oldest  Next Newest »

▼
05012013, 05:11 PM
▼
05012013, 05:29 PM
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.
05012013, 07:19 PM
32SII = 0.0760
Edited: 1 May 2013, 7:44 p.m.
05012013, 07:59 PM
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.
05012013, 08:09 PM
Emulated calcs for everything here using this OS X port of nonpareil, except the 41 (emulated in X41), 50g, and MK61 (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) Woodstock/Spice:
25: 0.0760 (fix 9 returns 0.075999400) Nut: 41CV (unknown ROM, it's X41 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.59999999999E2 As an aside (not even an HP here), while the MK61 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.
05012013, 08:37 PM
Quote:
Please keep in mind that you don't enter the exact value of 8/60 here. Instead with the HP15C it is a 10digit 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 7.599999999 e 2
With FIX 4 display this will be shown as: 0.0760 Thus the HP15C doesn't give the correct answer here.
Cheers
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.
05012013, 08:46 PM
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.
▼
05012013, 09:22 PM
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? ▼
05012013, 09:39 PM
Quote: 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. ▼
05012013, 09:59 PM
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.
05012013, 11:18 PM
Quote: 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.
05012013, 08:58 PM
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 PR100 is more consistent it gets them all wrong 0.0760 1.0760 2.0760 etc... as does the TI59
05012013, 10:44 PM
On my HP71B I get 0.0800, exactly ;) >FIX 4 ▼
05022013, 01:05 AM
I get 0.800 on two emulators for iOS: HP25C and HP45. Both have 1415 digit internal accuracy.
05022013, 01:57 AM
For very small values the >H.MS translation should be just a multiplication by the factor 0.36. So for instance 1E10 will lead to 3.6E11. However with the HP15C the value 2.777777777E10 will be translated to 1.000000000E10 while the result of the multiplication is 9.999999997E11. Thus there is some additional rounding that we don't see with the HP48GX.
Cheers ▼
05022013, 02:09 AM
On the HP42S, this workaround appears to work: 00 { 18Byte Prgm } Gerson. ▼
05022013, 02:14 AM
Rounding away from zero? I'm certain there would be cases where this is broken too :(
▼
05022013, 09:46 AM
Quote: 1e11 instead of 1e12 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.
05022013, 06:28 AM
Quote:
On my HP42S I get the following results: 2.77777777777E10  2.77777777777E10 Okay, close enough!
With your program "HMS" I get: 2.77777777777E10 Could you elaborate on how this is a "workaround"? Workaround for what? Can we agree that HP42S provides the correct result and both HP41C and HP15C don't?
Cheers ▼
05022013, 08:26 AM
Quote:
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 HP71B program. I solved it by changing slightly the argument before performing the conversion. This is the line 320 of my original CASIO PB700 program: 320 B=B+.00014:T=FRFor that particular purpose, I believe this is a valid workaround. Cheers, Gerson. ▼
05022013, 11:46 AM
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
_{Edit: typo and added missing name} Edited: 2 May 2013, 1:16 p.m. after one or more responses were posted ▼
05022013, 01:02 PM
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 ▼
05022013, 01:08 PM
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
05022013, 02:48 PM
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 builtin >HMS function doesn't behave the way I want, then I think a workaround is needed. Best regards, Gerson. ▼
05022013, 05:41 PM
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
▼
05022013, 06:45 PM
There's another approach I used in the QBASIC version of the subroutine, in the program in the link above. The HP71B 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.
HP71B:
▼
05022013, 07:30 PM
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.
05032013, 03:24 PM
Pauli, sometimes life is easier than you might expect. ;) Quote:Here's my alternative code: 0Somewhat 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 secondsOr, in our case: 0,0760Dieter ▼
05032013, 04:29 PM
Quote: Very nice!
Quote:
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 { 12Byte Prgm } Regards, Gerson.
05032013, 04:13 PM
Just out of curiosity, in FIX 2 what would you expect to see for 36 1/x >H.MS ? ▼
05032013, 04:40 PM
0.01 (or 0°1'40") Remember >H.MS doesn't round to minutes  actually, it makes sense with FIX 4 only. d:) ▼
05032013, 08:37 PM
Quote: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 . ▼
05042013, 01:26 AM
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:) ▼
05042013, 01:29 AM
Quote: 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.
▼
05042013, 02:15 AM
I've just noticed that 0.076 ENTER 0 H.MS+as in Dieter's suggestion above, returns 0.076 on my WP34S. Shouldn't 0.08 be preferable? Gerson. ▼
05042013, 03:15 AM
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.
05042013, 03:19 AM
What display mode are you using?
0.076 ENTER 0 H.MS+ Produces 0.0800 in FIX 04 mode here. Likewise in ALL mode.
05042013, 05:16 AM
Quote:Every display format from FIX 5 on should work correctly since the usual rounding applies ... d:)
05032013, 05:00 PM
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.
05032013, 08:44 PM
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 builtin modes for displaying something like "one mile thirteen yards two feet five and threequarters inches" or "three pounds seven shillings eleven pence" :) ▼
05032013, 10:34 PM
The ultimate answer is obvious! It's time for Metric Time!
Mark Hardman Edited: 3 May 2013, 10:38 p.m.
05042013, 06:24 PM
>HMS Does it too.
Edited: 4 May 2013, 6:27 p.m.
05042013, 06:45 AM
Since I was curious how the HP41C handles this transformation I had a glance at the source code. 544 716 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
Let's have a look at how this works for the example 0.21: P
I'll skip the rounding here and just continue to the 2nd call of HMSMP. 545 720 1724 DEC PT
Thus the operations won't affect digits left to P: P 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
The next steps deal with the rounding: P
The next call to HMSMP doesn't change anything on that result. That's the point where the value 7999999998 is rounded to 9 places.
Kind regards
VASM ROM ASSEMBLY510 ENTRY XTOHRS Edited: 4 May 2013, 7:06 a.m. ▼
05042013, 07:54 AM
Brilliant ! That shows that proper rounding was considered as necessary by hp for the famous hp41 (and hp15c I presume). Thanks :) ▼
05042013, 11:38 AM
Sure they did, but in this special case you mentioned in the original post (i.e. 1.333333333E1) they got it wrong: Now I'd have to check in the source code of the HP48 why it behaves differently. Do we have access to that?
Cheers 