The Museum of HP Calculators

HP Forum Archive 20

 more HMS, aTIME, 34s display, 41c bugs?Message #1 Posted by Christopher Johnson on 25 Feb 2012, 9:34 p.m. ```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 ```

 Re: more HMS, aTIME, 34s display, 41c bugs?Message #2 Posted by Paul Dale on 25 Feb 2012, 10:05 p.m.,in response to message #1 by Christopher Johnson 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

 Re: more HMS, aTIME, 34s display, 41c bugs?Message #3 Posted by Luiz C. Vieira (Brazil) on 25 Feb 2012, 10:06 p.m.,in response to message #1 by Christopher Johnson 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.

Go back to the main exhibit hall