Do you know these 2 functions ? « Next Oldest | Next Newest »

 ▼ PGILLET Junior Member Posts: 16 Threads: 6 Joined: Dec 2011 12-15-2011, 02:23 AM 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 ... :) ▼ Marcus von Cube, Germany Posting Freak Posts: 3,283 Threads: 104 Joined: Jul 2005 12-15-2011, 03:26 AM Easy? I can't make anything out of it by looking at the Wolfram Alpha plots. Alexander Oestert Senior Member Posts: 429 Threads: 31 Joined: Jul 2011 12-15-2011, 04:17 AM Two-directional unit conversion PGILLET Junior Member Posts: 16 Threads: 6 Joined: Dec 2011 12-15-2011, 09:01 AM It was easy :) y1 = Decimal Degrees -> Degrees/Minutes/Seconds y2 = Degrees/Minutes/Seconds -> Decimal Degrees I don't think it's widely used ... ▼ Oliver Unter Ecker Member Posts: 239 Threads: 9 Joined: Dec 2010 12-16-2011, 06:04 PM 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). ▼ Paul Dale Posting Freak Posts: 3,229 Threads: 42 Joined: Jul 2006 12-16-2011, 06:15 PM 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 ▼ Werner Member Posts: 163 Threads: 7 Joined: Jul 2007 12-17-2011, 05:56 PM 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. PGILLET Junior Member Posts: 16 Threads: 6 Joined: Dec 2011 12-21-2011, 06:14 AM 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 ▼ Oliver Unter Ecker Member Posts: 239 Threads: 9 Joined: Dec 2010 12-21-2011, 12:14 PM 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. J-F Garnier Senior Member Posts: 412 Threads: 40 Joined: Mar 2006 12-21-2011, 02:46 PM 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. ▼ Werner Member Posts: 163 Threads: 7 Joined: Jul 2007 12-21-2011, 03:29 PM 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 Gerson W. Barbosa Posting Freak Posts: 2,761 Threads: 100 Joined: Jul 2005 12-21-2011, 03:36 PM 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. ▼ Werner Member Posts: 163 Threads: 7 Joined: Jul 2007 12-22-2011, 12:01 PM 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 W. Barbosa Posting Freak Posts: 2,761 Threads: 100 Joined: Jul 2005 12-22-2011, 03:11 PM 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. Dieter Senior Member Posts: 653 Threads: 26 Joined: Aug 2010 12-22-2011, 02:58 PM 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. ▼ Gerson W. Barbosa Posting Freak Posts: 2,761 Threads: 100 Joined: Jul 2005 12-22-2011, 03:15 PM 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. Oliver Unter Ecker Member Posts: 239 Threads: 9 Joined: Dec 2010 12-21-2011, 03:46 PM The formula returns 0.08, too. It's all in the proper rounding to internal precision, as mentioned above. See the code above. ▼ PGILLET Junior Member Posts: 16 Threads: 6 Joined: Dec 2011 12-21-2011, 04:13 PM 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 777 11-08-2013, 04:32 PM Last Post: Monte Dalrymple HP Prime: in need of help with defining functions Alberto Candel 14 2,838 10-27-2013, 10:48 AM Last Post: Alberto Candel HP Prime spreadsheet functions SanS 0 1,464 10-04-2013, 04:23 AM Last Post: SanS Stats functions on the HP34S Nicholas van Stigt 5 1,461 09-24-2013, 02:45 AM Last Post: Nick_S Trig Functions Howard Owen 11 2,575 09-16-2013, 02:53 PM Last Post: Fred Lusk 50g piecewise functions Kurt Fankhauser 6 1,701 09-15-2013, 08:01 PM Last Post: Kurt Fankhauser Missing functions on the HP Prime!!!??? :-( Namir 6 1,624 08-22-2013, 08:40 AM Last Post: Gilles Carpentier HP41 Functions Address Table (F.A.T.) Antoine M. Couëtte 6 1,568 07-21-2013, 02:48 AM Last Post: Antoine M. Couëtte Trigonometric Functions (HP-17BII) Gerson W. Barbosa 2 1,193 04-09-2013, 11:57 PM Last Post: Gerson W. Barbosa [41CL] Rescue from 'Lost Y Functions' Dan Grelinger 18 3,225 02-16-2013, 02:08 PM Last Post: Diego Diaz

Forum Jump: