Post Reply 
H->HMS conversion HP-15C vs. HP42S vs HP67
09-15-2018, 02:47 PM (This post was last modified: 09-15-2018 02:57 PM by Albert Chan.)
Post: #61
RE: H->HMS conversion HP-15C vs. HP42S vs HP67
An idea to fix the 60-seconds bug ... think of it as a feature Smile

If DD.MMSS form returned, say 9.5960, it is not really 10 degrees.
It is close, but not quite reach it.

So, the calculator is giving the user more information about the angles ...
And this honest answer extended to other FIX places:

FIX 3: 9.596 (close to 6 "ten secs")
FIX 2: 9.60 (close to 60 minutes)
FIX 1: 9.6 (close to 6 "ten minutes")
FIX 0: 10 (uh, no room to give precision, so ... 10)

Warning: above is meant as a joke ... the FIX places game work for the bug Tongue
Find all posts by this user
Quote this message in a reply
09-18-2018, 04:56 PM
Post: #62
RE: H->HMS conversion HP-15C vs. HP42S vs HP67
(09-13-2018 01:46 PM)Albert Chan Wrote:  Before the fix, we may see 60 seconds, sometimes 60 minutes, but it is accurate.
A little cleaning-up, and we are good ...

After the fix, potentially you get into fixing phantom bug, similar to +25 seconds patch:
Just an example, on HP-12C, try X = 1000.999999:

Pekis DEG->DMS formula: (90*X + INT(60*X) + 100*INT(X)) / 250 ...

After some thinking, even the original formula is not safe ...

Example, angle = 9.20 degrees:
X = 9.19999 99999 99999 3 (degree), DEG->DMS(X) = 9.11999 99999 99999 2

Unless DD.MMSS allowed round-off, to 9.12, above just hit a 40 seconds bug.
This is a proposed fix:

Code:
def dms_to_deg(x):
    y = (100 + 1e-14) * x              # fix 40 seconds bug
    y = 2.5*y - int(y) - 60*int(y/100)
    return y * (1/90 - 3e-18)          # compensate above fix

def deg_to_dms(x):
    y = (3600 + 9e-13) * x             # y > 3600 D + 60 M + S
    z = 100 * int(y/3600) + int(y/60)  # z = 160 D + M (exact)
    y += 40 * z                        # y ~ 10000 D + 100 M + S
    return y * (1/10000 + 2e-20)       # avoid round-down 0.5 ULP

New deg_to_dms(X) = 9.12000 00000 00001
Find all posts by this user
Quote this message in a reply
09-20-2018, 08:52 PM (This post was last modified: 09-20-2018 08:53 PM by DaveBr.)
Post: #63
RE: H->HMS conversion HP-15C vs. HP42S vs HP67
(09-10-2018 07:06 PM)Joe Horn Wrote:  
(09-10-2018 06:18 PM)Albert Chan Wrote:  As long as calculator treat the "number" as decimal, it cannot be fix by patching formula.

Ho ho! The gauntlet has been thrown! Big Grin <scampers off to Happy Programming Place to ponder this challenge>

Great post! I read 2 + pages of this (now 4 page) thread, armed with several HP calculators and several IOS emulators, grinding through each posting until this one. I dropped my hardware and smiled.
Good on you guys!
Dave
Find all posts by this user
Quote this message in a reply
09-21-2018, 03:06 AM (This post was last modified: 09-21-2018 01:58 PM by Craig Bladow.)
Post: #64
RE: H->HMS conversion HP-15C vs. HP42S vs HP67
I ran into this issue when developing NQ41, which uses double precision binary math, and after looking into possible solutions decided not to address it and let it display 1.2960 as we all know what that means and the conversion back to decimal degrees can be done more accurately than if the rounding was used to obtain a display of 1.30.

Try CC41!
Find all posts by this user
Quote this message in a reply
09-21-2018, 06:08 AM
Post: #65
RE: H->HMS conversion HP-15C vs. HP42S vs HP67
It's been years, but back in the day when a 41 was my main field computer in surveying I created a subroutine for displaying bearings and angles in dms format. It built it in the alpha register and used a view command to see it while leaving the original number unchanged in the x register. This also allowed display of cardinal directions instead of N90-00-00W.

Since the numbers given by the calculator are correct but it doesn't properly handle Sexagesimal rounding this is the cleanest option in my opinion. You could write a program called DMS which would convert the number from decimal and then view a properly rounded display leaving the number correct in the x register. It would have to adjust for the display setting and for me I would only use fix 2, 4, 5 or 6 as valid displays. If I only cared to the nearest degree no need to convert to begin with, anyone should be able to round that in their head. I also can't picture a need for less than a hundreth of a second but maybe someone else can.
Find all posts by this user
Quote this message in a reply
09-21-2018, 12:16 PM
Post: #66
RE: H->HMS conversion HP-15C vs. HP42S vs HP67
(09-21-2018 03:06 AM)Craig Bladow Wrote:  I ran into this issue when developing NQ41, which uses double precision binary math, and after looking into possible solutions decide not to address it and let it display 1.2960 as we all know what that means and the conversion back to decimal degrees can be done more accurately than if the rounding was used to obtain a display of 1.30.

An unintended consequence of deg_to_dms patch to fix 40-seconds bug, 60-seconds bug is shifted away.
Now, user need to input 16+ decimals to hit the display bug.

Example: angle = 2.05 degrees, X = 2.049999 ...

Pekis DEG->DMS(X) = 2.0259999 ... (Hit 60 seconds display bug)
My deg_to_dms(X) = 2.030000 ... (display bug shifted down, to 2.04999 99999 99999 degree)

So, the patch is Buy 1, Get 1 Free Smile
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)