Do you know these 2 functions ?



#19

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 ... :)


#20

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

#21

Two-directional unit conversion

#22

It was easy :)

y1 = Decimal Degrees -> Degrees/Minutes/Seconds

y2 = Degrees/Minutes/Seconds -> Decimal Degrees

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


#23

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).


#24

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


#25

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.

#26

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


#27

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.

#28

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.


#29

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

#30

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.


#31

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


#32

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.

#33

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.


#34

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.

#35

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

See the code above.


#36

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


Possibly Related Threads...
Thread Author Replies Views Last Post
  [41CL] New Extra Functions version Monte Dalrymple 0 148 11-08-2013, 04:32 PM
Last Post: Monte Dalrymple
  HP Prime: in need of help with defining functions Alberto Candel 14 654 10-27-2013, 10:48 AM
Last Post: Alberto Candel
  HP Prime spreadsheet functions SanS 0 331 10-04-2013, 04:23 AM
Last Post: SanS
  Stats functions on the HP34S Nicholas van Stigt 5 278 09-24-2013, 02:45 AM
Last Post: Nick_S
  Trig Functions Howard Owen 11 506 09-16-2013, 02:53 PM
Last Post: Fred Lusk
  50g piecewise functions Kurt Fankhauser 6 290 09-15-2013, 08:01 PM
Last Post: Kurt Fankhauser
  Missing functions on the HP Prime!!!??? :-( Namir 6 326 08-22-2013, 08:40 AM
Last Post: Gilles Carpentier
  HP41 Functions Address Table (F.A.T.) Antoine M. Couëtte 6 297 07-21-2013, 02:48 AM
Last Post: Antoine M. Couëtte
  Trigonometric Functions (HP-17BII) Gerson W. Barbosa 2 229 04-09-2013, 11:57 PM
Last Post: Gerson W. Barbosa
  [41CL] Rescue from 'Lost Y Functions' Dan Grelinger 18 593 02-16-2013, 02:08 PM
Last Post: Diego Diaz

Forum Jump: