▼
Posts: 43
Threads: 2
Joined: Mar 2007
So I found two threads in the archives about HMS+ / HMS, which confirmed what I discovered quite accidentally... that HMS+ / HMS are implemented by converting both arguments with HR, then converting the result back (at least in all the HPs I tested  15c, 41CV, 48G).
BTW, to see this in action, just try something like
10000.20
ENTER
9995.24
HMS
While I was disappointed to discover this, apparently it's generally true in scientifics (Sharp forces explicit conversion, Casio uses the same technique, etc.).
I understand why this happens, I just want better results.
Does anyone know which calculators natively implement HMS+ / HMS using mod 60 operations? I seem to recall a Casio time calculator that might be promising. All I really want is a guarantee that if I'm adding or subtracting times with integral minutes, my result will be in integral minutes as well. Obviously I can program real HMS+ / HMS to override the included ones, but I'd love to find a calc that does it correctly out of the box.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Alex 
Good question. I believe that it's a matter of refining that "extra step" to internally RND and convert to the nearest minute the fractional part of "hh.mmss" that would ordinarily be displayed as mm60 in "FIX 4". Some HP calc's do; others don't.
The HP28C, HP42S, and HP49G display the result of your calculation in correct HMS format: 4.5600. The HP41C/CV/CX and HP48G don't round, displaying 4.5560.
The HP15C and the HP32S/SII don't have HMS+ and HMS; the user must convert each way.
 KS
Edited: 11 Feb 2008, 4:48 p.m.
▼
Posts: 43
Threads: 2
Joined: Mar 2007
Thanks for the reply. Just to clarify, I want a result that is internally correct (important for chaining calculations), as well as correctly displayed. For example, if my 48G is in STD mode, I get 4.55599999999.
What do the 28C, 42S, and 49G produce when displaying the maximum possible precision (STD/ALL)?
EDIT:
I got to where I could do some testing myself.
Looks like the 42S, 28C, and 28S have it exact. So I'm surprised:
The 28 series gets it right, the 48S and 48G do not.
The 42 gets in right, the 41s do not.
Other reports?
Edited: 11 Feb 2008, 9:40 p.m.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Alex 
Our initial findings still stand: The HP28C/S, HP42S, and HP49G get the result  4.56 exactly  correct in all decimal digits. I don't know whether that is due to internal "RND"style closetolerance rounding with subsequent MOD(x,60), or whether the input arguments are parsed for separate processing in the calculations.
FWIW, here is a table of "incorrect" calculations and conversions:
10000.20 10000.20
ENTER >H or >HR
9995.24 9995.24
HMS >H or >HR

>HMS
model result method
HP41 4.555998800 HMS
HP15C 4.555998800 >H >H  >HMS
HP32S* 4.55599998800 >HR >HR  >HMS
HP48G 4.55599999999 HMS
* (includes HP32SII, HP33s, and HP35s)
(Thanks, George and John. I would expect the HP49g+ and HP50g to yield the same result as the HP49G. I would not take it for granted that the HP35s would always yield the same result as the HP33s. Some of the HP33s' datahandling methods from the HP32SII were replaced with RPLstyle methods in the HP35s.)
 KS
Edited: 14 Feb 2008, 1:48 a.m. after one or more responses were posted
▼
Posts: 335
Threads: 12
Joined: Dec 2007
Quote:
HP32S* 4.55599998800 >HR >HR  >HMS
* (includes HP32SII, HP33s, and presumably HP35s [not now at hand])
Result on the HP 35s is 4.555999988
Posts: 256
Threads: 4
Joined: Sep 2007
On the 49G+: 10000.2 Enter 9995.24 HMS yields 4.56.
Regards,
John
Posts: 149
Threads: 7
Joined: Dec 2006
HP27S result is 4.55599999999
Logic used: 10000.2 >HR  9995.24 >HR = >HMS
This is interesting because it differs from the 42S, when one might have expected them to be the same.
Also, thanks for reviving this topic. I was unaware of it.
Edited: 12 Feb 2008, 10:06 a.m.
▼
Posts: 43
Threads: 2
Joined: Mar 2007
I'm glad others find this interesting.
Ken, I think the reason the 27S differs is that you have to do the >HR conversions. I strongly suspect the 42S is actually parsing the input as H.MS. I've confirmed with a glance at the BEAUTIFUL source that Free42 is parsing the input and doing the mod 60 math (check out hms_add_or_sub in core_commands3.cc), and its faithfulness to the 42S only bolsters my suspicion.
I came across this quirk when using my newtome 41CV to tally up times from a log sheet. I was using HMS with clock times to calculate numbers of minutes. When I subtracted 10:20  08:24, I got a surprise.
So far it looks like my onhand best candidates for time math are my 28C, 28S, 42S, and (as long as I don't have to tally over 10K hours) a modern pocket Sharp.
▼
Posts: 149
Threads: 7
Joined: Dec 2006
Yes, you're right of course. I was forgetting there were 2 ways to do it on the 42S, as mentioned elswhere in this thread, with the same result as the 27S when the HR/HMS functions are used together.
Checked it with Free42, and I have to say that is one amazing simulation program.
Posts: 1,792
Threads: 62
Joined: Jan 2005
Alex 
It just goes to show that "simple" calculations are not always so simple in their practical implementation.
 KS
Posts: 43
Threads: 2
Joined: Mar 2007
To back up my initial claim, a few data points from our friends at Sharp and Casio. Interestingly, most of these report the answer in DEG(=HR) format, even if the input is in D°M'S" literal format.
model result method
Casio
fx7500G 4.93333333 > 4°56' 10000°20°  9995°24° *
cfx9850G 4.93333333 > 4°56' 10000°20°  9995°24° **
Sharp
EL520R 4°56' 1000°20°  995°24° †
EL9600C 4.933333333 > 4°56' 10000°20°  9995°24° ‡
*Loses precision at greater difference of magnitude;
10000000°20°  9999995°24° yields 4.933333 > 4°55'59.99"
**Loses precision at greater difference of magnitude;
1000000000°20°  999999995°24° yields 4.933333 > 4°55'59.99"
†Max angle input 9999°59'59'
‡Loses precision at greater difference of magnitude;
10000000°20°  9999995°24° yields 4.933333 > 4°56'0" (!),
1000000000°20°  999999995°24° yields 4.9333 > 4°55'59.88"
