more HMS, aTIME, 34s display, 41c bugs?

[Christopher Johnson]

Here is some more HMS,Alpha oddities. What do you think?

Hopefully I am presenting this in a clear way.

34s 3.0 2551

FIX 6

9.285964

ENTER^

aTIME

Bad time or dAtE

FIX 4

9.2860

9.285900

aTIME

9:28:59 AM

FIX 2

9.29

aTIME

9:28:59 AM

FIX 0

9.

aTIME

9:28:59 AM



41C - 2051A

FIX 6

9.285964

ENTER^

ATIME

9:28:59.64 AM

FIX 4

9.2860

ATIME

9:28:59 AM

FIX 2

9.29

ATIME

9:28 AM

FIX 0

ATIME

9 AM

I think the 34s is rounding to 4 places and throwing the error. Where as the 41c

is taking just the absolute value. I prefer the 41c approach. Also the 34s does

not follow the fix setting when appending to alpha like the 41c. Again I prefer

the 41c approach. Just some observations I had.

Now this is more errors in HMS math functions. I know nsim uses 41c roms.

I'm not sure if coconut uses roms but I'm fairly sure it does. free42 is a

simulation.

Which calculator do you think is giving the right answer, out of the 3 here?

I will go with the way free42 handles these numbers.

wp34s 3.0 2551

22.0500			22.4100

ENTER^			ENTER^

22.0000			22.0000

HMS-			HMS-

0.046000000		0.406000000

hp41c 2051A

0.045999999		0.405999999

nsim-0.61 - unknown rom version

0.045999999		0.405999999

free42 - 1.4.70 - linux

0.0500			0.4100

coconut on the palm 1.0

0.045999999		0.405999999

free42 - 1.4.70 - palm

0.0500			0.4100



These numbers cause the strange behavior. The numbers in between work just fine

and get the same answer as free42.

22.02, 22.05, 22.08, 22.11, 22.14, 22.17, 22,20, 22.23 etc.

Could this be considered a 41c bug? What do you get on other hp's?

I searched for 41 bugs and found this:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv005.cgi?read=7416

Here is some more strange behavior

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv014.cgi?read=61466

Now that is a conversion bug. I'm just doing straight HMS-. The other reason I

post this link is message #6 I see the same pattern as above. A thought just

came to me. Maybe the software is converting to HR performing the math and then

converting back to HMS?

I tried 3 online HMS calculators and they all gave me the same answer as free42.

I am interested in what others may think of this.

CJ

[Paul Dale]

Quote:

---

I think the 34s is rounding to 4 places and throwing the error.

---

Yes, the 34S is rounding to four places before doing anything with the time. Yes, this is different to the 41c + time module. Likewise, alphaTIME on the 34S doesn't care about display mode. Now, the 34S could be made more like the 41c if this is desirable. Is it?

I'm unsure about using the display mode -- what happens in FIX 3 e.g. The way things are now, you append the time and can easily strip off whatever trailing characters you want -- we've a pretty good selection of alpha commands to assist here. Whereas, the 41c has a rather limited selection of alpha commands by default.

Quote:

---

wp34s 3.0 2551

22.0500			22.4100

ENTER^			ENTER^

22.0000			22.0000

HMS-			HMS-

0.046000000		0.406000000

---

Fixed, built and in subversion now. Revision 2576. A problem rounding the result to register precision from internal precision -- effectively a double rounding where the first went down to 59.99999 which avoids the over sixty correction and the second pushed this up to 60.

Quote:

---

Could this be considered a 41c bug?

---

I would consider it one.

Quote:

---

Maybe the software is converting to HR performing the math and then converting back to HMS?

---

This is what the 34S does -- the code is smaller this way.

- Pauli

[Luiz C. Vieira (Brazil)]

Hi.

Quote:

---

Maybe the software is converting to HR performing the math and then converting back to HMS?

---

It's more likely to be. The step-by-step true HMS+ (or HMS-) might be time- and memory-consuming, while addition and multiplication are already implemented. The HMS->HR might round the original numbers and HR->HMS would probably round the results as well. I do not have the emulators to test, though.

Cheers.

Edited: 25 Feb 2012, 10:08 p.m.