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.

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 HP-28C, HP-42S, and HP-49G display the result of your calculation in correct HMS format: 4.5600. The HP-41C/CV/CX and HP-48G don't round, displaying 4.5560.

The HP-15C and the HP-32S/SII don't have HMS+ and HMS-; the user must convert each way.

-- KS

Edited: 11 Feb 2008, 4:48 p.m.

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.

Alex --

Our initial findings still stand: The HP-28C/S, HP-42S, and HP-49G get the result -- 4.56 exactly -- correct in all decimal digits. I don't know whether that is due to internal "RND"-style close-tolerance 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

HP-41     4.555998800     HMS-

HP-15C    4.555998800     ->H ->H - ->HMS 

HP-32S*   4.55599998800   ->HR ->HR - ->HMS 

HP-48G    4.55599999999   HMS-

* (includes HP-32SII, HP-33s, and HP-35s)

(Thanks, George and John. I would expect the HP-49g+ and HP-50g to yield the same result as the HP-49G. I would not take it for granted that the HP-35s would always yield the same result as the HP-33s. Some of the HP-33s' data-handling methods from the HP-32SII were replaced with RPL-style methods in the HP-35s.)

-- KS

Edited: 14 Feb 2008, 1:48 a.m. after one or more responses were posted

Quote:

---

HP-32S* 4.55599998800 ->HR ->HR - ->HMS
* (includes HP-32SII, HP-33s, and presumably HP-35s [not now at hand])

---

Result on the HP 35s is 4.555999988

HP-27S 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.

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

fx-7500G  4.93333333 -> 4°56'  10000°20° - 9995°24° *

cfx-9850G 4.93333333 -> 4°56'  10000°20° - 9995°24° **

Sharp

EL-520R   4°56'                1000°20° - 995°24° †

EL-9600C  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"

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 new-to-me 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 on-hand 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.

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.

Alex --

It just goes to show that "simple" calculations are not always so simple in their practical implementation.

-- KS

On the 49G+: 10000.2 Enter 9995.24 HMS- yields 4.56.

Regards,

John