Hi all, I was just going to buy the hardware when I was checking out some calculation examples on the WP31s and WP34s emulator with unexpected results (subtract 1 degree from 18 minutes):
0.18 [ENTER]
1 [H.MS]
0.416 (not 0.42??)
1 [H.MS]
1.42 (ok again, except when you start with 0.416  then you'd expect 1.416)
With other values (0.17, etc) it delivers the expected results. It doesn't matter if you use 1 [H.MS+] or 1 [H.MS]
 you can also 0.416 [ENTER] 1 [H.MS+] with result 0.18
Is it some kind of strange rounding bug? I tried searching the forums first, but found nothing.
Cheers from Zurich,
Greg
PS: not sure if this should have gone somewhere else  new to this
Hello Greg,
The result is not really wrong.
0.4160 actually means 41' + 60" which is 42'.
I could imagine that this has to do with rounding of intermediate results, which gives may be 59.9...9" for the seconds. After combination with the 41" the seconds are simply rounded to 60".
Regards
Bernd
We will investigate the issue as soon as SourceForge allows us to access the code repository again. At the moment we're stuck.
(07172015 12:56 PM)Bernd Grubert Wrote: [ > ]The result is not really wrong.
0.4160 actually means 41' + 60" which is 42'.
Phew, that's a relief! I got misled by the trailing zero not being displayed, so i didn't recognize the 60" = 1' ... I'll try to remember that whenever it pops up.
(07172015 01:31 PM)Marcus von Cube Wrote: [ > ]We will investigate the issue as soon as SourceForge allows us to access the code repository again. At the moment we're stuck.
This is good to hear, greatly appreciated! I'd be interested as well, why it occurs (and with which numbers). It will take a lot more time and experience to find out myself, though. But still impatiently waiting for SourceForge to return from the 'static offline mode'
Fixed. The problem was rounding when the number was negative didn't quite work always.
I need sourceforge to be available to be able to commit the changes.
 Pauli
Pauli, Marcus, Bernd, I am really surprised and happy about how fast the diagnose and fix went!
The calculator is ordered, and now I also need a flash cable  tried to contact Harald Pott, but I guess that USB board was sold out long ago and the email address on the circuit board is no longer in order ...
If anyone has got a hint for a flash cable (too little time right now to gather all the components and start soldering myself), or even somebody near Zurich with access to one, that would be very nice!
But I guess that's for a different thread :)
Cheers and have a nice weekend!
Greg
(07182015 04:05 AM)Paul Dale Wrote: [ > ]Fixed. The problem was rounding when the number was negative didn't quite work always.
I see that rounding is a problem with certain H.MS operations, but in this case 18 minutes are
exactly 0.3 hours, and this minus 1 hour is
exactly –0.7 hours = –42 minutes. So I wonder where a roundoff error may occur.
Dieter
(07202015 06:09 AM)Dieter Wrote: [ > ]I see that rounding is a problem with certain H.MS operations, but in this case 18 minutes are exactly 0.3 hours, and this minus 1 hour is exactly –0.7 hours = –42 minutes. So I wonder where a roundoff error may occur.
The conversion of 18 minutes came out as 0.3000....0001 in the internal reals. I didn't check where the error came from but I suspect the multiplication by 1/60 is the culprit. This was chosen because it is faster than division by 60 but it will round differently. Of course, I could be completely wrong here.
 Pauli
(07202015 07:16 AM)Paul Dale Wrote: [ > ]The conversion of 18 minutes came out as 0.3000....0001 in the internal reals. I didn't check where the error came from but I suspect the multiplication by 1/60 is the culprit.
Since 1/60 is always rounded, the multiplication result cannot be exact under all circumstances. Compared to a division by 60, is a slightly (IMHO negligibly) faster execution really worth the trouble?
On the other hand it is always possible that an H.MS operation yields a result with a "60 seconds" part, so this has to be handled anyway.
Dieter
(07242015 09:47 AM)Dieter Wrote: [ > ]On the other hand it is always possible that an H.MS operation yields a result with a "60 seconds" part, so this has to be handled anyway.
I think you answered your own question
This case wasn't about the rounding, it was about the negative sign.
 Pauli
You don't have to divide by 60 for >HMS (courtesy of John H. Meyers):
">HMS" (41C code):
Code:
ENTER
FRC
.4
*

1 E4
%
.004
*

RTN
It will never result in 60 for MM or SS, either
Cheers, Werner
That's a clever piece of code.
 Pauli
The 41C code is mine, but the formula is John's.
From an old post of his on comp.sys.hp48:
>HMS
Program: \<< DUP FP .4 *  DUP 100. * FP .004 *  \>>
Formula: H.MS=H.FP(H.)*.4FP((H.FP(H.)*.4)*100)*.004
HMS>
Program: \<< DUP 100. * FP 150. / + DUP FP 1.5 / + \>>
Formula: H.=H.MS+FP(H.MS*100)/150+FP(H.MS+FP(H.MS*100)/150)/1.5
Cheers, Werner
(07242015 11:59 AM)Werner Wrote: [ > ]The 41C code is mine, but the formula is John's.
From an old post on comp.sys.hp48:
>HMS
Program: \<< DUP FP .4 *  DUP 100. * FP .004 *  \>>
Formula: H.MS=H.FP(H.)*.4FP((H.FP(H.)*.4)*100)*.004
HMS>
Program: \<< DUP 100. * FP 150. / + DUP FP 1.5 / + \>>
Formula: H.=H.MS+FP(H.MS*100)/150+FP(H.MS+FP(H.MS*100)/150)/1.5
Cheers, Werner
This is great! No rounding, no problems with negatives, handles any input (like 1h 65').
newRPL has found its HMS commands implementation. Thanks! (to both John for the original post, and you for refreshing our memories).
(07242015 12:50 PM)Claudio L. Wrote: [ > ]This is great! No rounding, no problems with negatives, handles any input (like 1h 65').
newRPL has found its HMS commands implementation.
Why won't the /150 and /1.5 steps cause rounding problems?
3 is not a factor of the base (10).
 Pauli
(07262015 08:27 AM)Paul Dale Wrote: [ > ]Fixes committed.
 Pauli
It will take some time until I can build everything. When I had the time SF was down... Now I'm a bit busy. Maybe another sleepless night will do.
I've built the emulators but I cannot upload to sourceforge...