WP 31S/34S: H.MS+/H.MS- anomaly?

[2far]

Hi all, I was just going to buy the hardware when I was checking out some calculation examples on the WP-31s and WP-34s 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

[Bernd Grubert]

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

[Marcus von Cube]

We will investigate the issue as soon as SourceForge allows us to access the code repository again. At the moment we're stuck.

[2far]

(07-17-2015 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.

(07-17-2015 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'

[Paul Dale]

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

[2far]

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

[Paul Dale]

Getting the fix to people could take a while yet:

http://sourceforge.net/blog/sourceforge-...storation/

We use subversion not git, so it looks like we'll be the last group recovered.


- Pauli

[Dieter]

(07-18-2015 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

[Paul Dale]

(07-20-2015 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

[Dieter]

(07-20-2015 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

[Paul Dale]

(07-24-2015 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

[Werner]

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

[Paul Dale]

That's a clever piece of code.

- Pauli

[Werner]

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.)*.4-FP((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

[Claudio L.]

(07-24-2015 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.)*.4-FP((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).

[Paul Dale]

(07-24-2015 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

[fhub]

(07-19-2015 04:33 AM)Paul Dale Wrote:  Getting the fix to people could take a while yet:
http://sourceforge.net/blog/sourceforge-...storation/

SVN is back again.
The fix will be 3799, so the next build will have a good number (3800) for a final(?) release ...

Franz

[Paul Dale]

Fixes committed.

- Pauli

[Marcus von Cube]

(07-26-2015 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.

[pascal_meheut]

I've built the emulators but I cannot upload to sourceforge...