# HP Forums

Full Version: Do you know these 2 functions ?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

Hello,

What's the purpose of these 2 functions (for x>0) ?

y1=(90*x+100*int(x)+int(60*x))/250
y2=(250*x-60*int(x)-int(100*x))/90

It's easy ... :)

Easy? I can't make anything out of it by looking at the Wolfram Alpha plots.

Two-directional unit conversion

It was easy :)

y1 = Decimal Degrees -> Degrees/Minutes/Seconds

y2 = Degrees/Minutes/Seconds -> Decimal Degrees

I don't think it's widely used ...

These are really sweet. Thank you for sharing!

Did you develop them yourself?

I think I'm going to use them in a calculator I know...

One should note that int() needs to do more than truncate to an int. It needs to round to internal precision as well, or you get something like 2.5111111111 for y2(2.3) (using IEEE-754 doubles).

Correctly dealing with rounding is by far the most difficult part of properly implementing these functions.

More so with binary floating point numbers than decimal ones.

- Pauli

Many of the H.MMSS numbers cannot be represented correctly in binary floating point... I've looked at Free42 Binary, it does a good job.

Some errors of the HMS arithmetic functions on the 41C:

``` 1.20 0.20 HMS-          0.5959999999
1.0 0.5959999999 HMS-   1.080000e-10
```
and, even one on the venerable 42S (where the equivalents of the above problems do get the correct results!)
``` 1.0 5.95999999999e-1 HMS+ -> 1.6000
```
The 5.959..e-1 kludge is the only way to enter a 12-digit number between 1 and 0.1, btw.

These 41/42-style programs do get it right, well, as far as I've been able to tell:

```*LBL"HR"
XEQ 02
3600
/
RTN
*LBL"HMS-"
CHS
*LBL"HMS+"
XEQ 02
X<>Y
XEQ 02
+
*LBL"S-H"
3600
/
*LBL"HMS"
ENTER
FRC
.4
*
-
E4
%
FRC
.004
*
-
RTN
*LBL"H-S"
*LBL 02
XEQ 00
*LBL 00
ENTER
INT
.4
*
-
E2
*
END
```

Cheers, Werner

Edited: 22 Dec 2011, 7:26 a.m.

Quote:
These are really sweet. Thank you for sharing!

Did you develop them yourself?

I think I'm going to use them in a calculator I know...

One should note that int() needs to do more than truncate to an int. It needs to round to internal precision as well, or you get something like 2.5111111111 for y2(2.3) (using IEEE-754 doubles).

Hello,

Yes, I discovered these 2 formulas years ago.

Are they known elsewhere ?

You're right about rounding to internal precision:

That's what I do now in my implementation of the dd->dms formula on the TI-86 as a built-in function

The TI-86 computes 14 digits and displays 12 => Rounding is done to 12 digits before and after the formula:

(It's good old Z80 programming)

ld hl,_OP1 ; hl = OP1 address (Floating point register number 1)

ld a,(hl) ; Get OP1 flag byte

ld (mem1),a ; save OP1 flag byte

and \$7F ; Clear sign bit => positive

ld (hl),a ; OP1=abs(x)

call _RNDGUARD ; OP1=OP1 rounded to 12 digits (abs(x) rounded, I call it x')

call _op1toop4 ; OP4=OP1 (x')

ld hl,n90

call _mov10toop2 ; OP2=90

call _FPMULT ; OP1=OP1*OP2 (90*x')

call _op1toop5 ; OP5=OP1 (90*x')

call _op4toop1 ; OP1=OP4 (x')

call _INTGR ; OP1=int(OP1) (int(x'))

ld hl,n100

call _mov10toop2 ; OP2=100

call _FPMULT ; OP1=OP1*OP2 (100*int(x'))

call _op5toop2 ; OP2=OP5 (90*x')

call _FPADD ; OP1=OP1+OP2 (90*x'+100*int(x'))

call _op1toop5 ; oP5=OP1 (90*x'+100*int(x'))

call _op4toop1 ; OP1=OP4 (x')

ld hl,n60

call _mov10toop2 ; OP2=60

call _FPMULT ; OP1=OP1*OP2 (60*x')

call _INTGR ; OP1=int(OP1) (int(60*x'))

call _op5toop2 ; OP2=OP5 (90*x'+100*int(x'))

call _FPADD ; OP1=OP1+OP2 (90*x'+100*int(x')+int(60*x'))

ld hl,n250

call _mov10toop2 ; OP2=250

call _FPDIV ; OP1=OP1/OP2 ((90*x'+100*int(x')+int
(60*x'))/250)

call _RNDGUARD ; OP1=OP1 rounded to 12 digits

ld a,(mem1)

and \$80 ; Keep sign bit only

ld hl,_OP1

or (hl)

ld (hl),a ; Restore sign bit

ret

I have not seen them before and find them quite remarkable. Wonder how you found them.

Here's my implementation of your formula (in MorphEngine):

```	"toHMS": function(x) { return this.toPrecision((90*x+100*this["int"](this.toPrecision(x))+this["int"](this.toPrecision(60*x)))/250); },
```

"this" points to the function collection for the "Number" (=Reals) data type.

Cheers.

Hello,

I didn't know these formulae either. Interesting.

However, here is case with abnormal result:

```7.5 1/x XEQ "HMS1"
Result is 0.0760
The HP-41C HMS function correctly returns 0.0800 .
The HP32SII ->HMS function returns 0.0759999999999 .
Here is my test program:
01*LBL "HMS1"
02 ENTER^
03 ENTER^
04 ENTER^
05 90
06 *
07 X<>Y
08 INT
09 100
10 *
11 +
12 X<>Y
13 60
14 *
15 INT
16 +
17 250
18 /
19 END
```

Edited: 21 Dec 2011, 2:48 p.m.

While the 0.0760 is wrong, I'm afraid it's the 41C that returns the abnormal result in this case... no doubt there's some 'cosmetic rounding' taking place that doesn't always work.

The correct result is delivered by the 32SII (and also by the 42S).
My formulas used in the programs above return the correct result as well.
(for HMS that would be:

``` x := 3600*HR;
x := x/100 + int(x/60)*0.4;
x := x/100 + int(x/60)*0.4;
```
Cheers, Werner

Quote:
The HP-41C HMS function correctly returns 0.0800 .

So does the HP-15C :-)

Quote:
The HP32SII ->HMS function returns 0.0759999999999 .

So does the HP-42S :-(

The BASIC sub-routines below ( from the QBASIC program in this thread convert D.MMSS to D.D (line 310) and D.D to D.MMSS (lines 320-328).

```310 M = INT(100 * FNFRAC(AN)): S = 100 * FNFRAC(100 * FNFRAC(AN)): AN = INT(AN) + M / 60 + S / 3600: RETURN
320 T = FNFRAC(AN): M = INT(60 * T): S = FNFRAC(((3600 * T) / 60)) * 60
323 IF INT(S + .5) = 60 THEN S = 0: M = M + 1
325 IF M = 60 THEN M = 0: AN = AN + 1
328 RETURN
```

This morning I had W|A simplify the first line. The result appears to be correct (at least for positive arguments -- I haven't tested it with negative arguments), despite being longer than PGILLET's original function:

`y2 = (180*IP[x] + 3*IP[100*FP[x]] + 5*FP[100*FP[x]])/180`

I didn't try to simplify the other function. When converting my original CASIO PB-700 program to QBASIC, I remember the function would not work correctly unless lines 323 and 325 were added. Perhaps both the HP-32SII and the HP-42S are using a similar simplified formula.

Edited: 21 Dec 2011, 3:48 p.m.

The formula returns 0.08, too. It's all in the proper rounding to internal precision, as mentioned above.

See the code above.

It seems better to round each time before calling int()

But 0.0759999... *is* the correct value for an input of 0.1333.. The 42S and 32SII have it right.

It's a bit like complaining (1/3)*3 does not equal 1.

And, on a decimal machine, using

``` x := HR - FRC(HR)*0.4;
HMS := x - FRC(x*100)*0.004;
```
does not need any rounding.

Cheers, Werner

Gerson, I think you used the wrong smilies. ;-) In fact, the 41C and 15C are wrong. They return an incorrect result due to rounding. I see Werner already said it, but anyway, let's take a closer look at this:

There is one basic thing we have to consider: the argument for the H.MS function is not 1/7,5 hours. In fact, it's the 10-digit-rounded value of this, i.e. all we can do is apply the H.MS function to x = 0,1333333333 hours. The correct H.MS representation of this is as follows:

```   0,13333 33333  hours
x 3600 seconds/hour
= 479,99 99998 8 seconds
```
In other words: The exact result of H.MS(0,13333 33333) is exactly
```   7 minutes and 59,99999988 seconds
```
In h.ms notation this result would be displayed as
```   0,075999 99998 8
```
This full-precision result requires 11 significant digits. But there are just 10 of them on the 41C and 15C. So the last digit gets rounded and the correct 10-digit result should be
```   0,075999 99999
```
But that's not what these machines return. They return exactly 8 minutes. Which is plain wrong. Or "inexact", if you prefer. ;-)

Now let's take a look at the same problem on a 12-digit machine. Here, the input value is

```   0,13333 33333 33 hours
x 3600 seconds/hour
= 479,99 99999 988 seconds
= 7 minutes, 59,999 99999 88 seconds
```
In h.ms notation this result would be displayed as
```   0,075999 99999 988
```
This exact result has 13 significant digits. So again, the last digit has to be rounded and the final, correct 12-digit result is
```   0,075999 99999 99
```
And that's exactly what the 32s returns.

So actually both the 41C and 15C are wrong :-(

While on the other hand the 32s is right :-)

Dieter

Edited: 22 Dec 2011, 3:00 p.m.

Quote:
It's a bit like complaining (1/3)*3 does not equal 1.

As in Dr. Randall's talk above... I found that ridiculous when I watched it, yet I did the same...

Cheers,

Gerson.

Quote:
Gerson, I think you used the wrong smilies. ;-)

Smiles duly reversed :-)

Thanks both of you!

Gerson.

Edited: 22 Dec 2011, 3:16 p.m.