Hello,
What's the purpose of these 2 functions (for x>0) ?
y1=(90*x+100*int(x)+int(60*x))/250
y2=(250*x60*int(x)int(100*x))/90
It's easy ... :)
Do you know these 2 functions ?


« Next Oldest  Next Newest »

▼
12152011, 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 It's easy ... :)
▼
12152011, 03:26 AM
Easy? I can't make anything out of it by looking at the Wolfram Alpha plots.
12152011, 04:17 AM
Twodirectional unit conversion
12152011, 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 ... ▼
12162011, 06:04 PM
These are really sweet. Thank you for sharing! 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 IEEE754 doubles). ▼
12162011, 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.
▼
12172011, 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.5959999999and, even one on the venerable 42S (where the equivalents of the above problems do get the correct results!) 1.0 5.95999999999e1 HMS+ > 1.6000The 5.959..e1 kludge is the only way to enter a 12digit number between 1 and 0.1, btw.
These 41/42style programs do get it right, well, as far as I've been able to tell: *LBL"HR" Cheers, Werner
Edited: 22 Dec 2011, 7:26 a.m.
12212011, 06:14 AM
Quote: 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 TI86 as a builtin function The TI86 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 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 ▼
12212011, 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.
12212011, 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"
Edited: 21 Dec 2011, 2:48 p.m. ▼
12212011, 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. x := 3600*HR;Cheers, Werner
12212011, 03:36 PM
Quote: So does the HP15C :)
Quote: So does the HP42S :( The BASIC subroutines below ( from the QBASIC program in this thread convert D.MMSS to D.D (line 310) and D.D to D.MMSS (lines 320328).
310 M = INT(100 * FNFRAC(AN)): S = 100 * FNFRAC(100 * FNFRAC(AN)): AN = INT(AN) + M / 60 + S / 3600: RETURN This morning I had WA 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 PB700 program to QBASIC, I remember the function would not work correctly unless lines 323 and 325 were added. Perhaps both the HP32SII and the HP42S are using a similar simplified formula.
Edited: 21 Dec 2011, 3:48 p.m. ▼
12222011, 12:01 PM
But 0.0759999... *is* the correct value for an input of 0.1333.. The 42S and 32SII have it right.
And, on a decimal machine, using x := HR  FRC(HR)*0.4;does not need any rounding. Cheers, Werner
12222011, 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 10digitrounded 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 hoursIn other words: The exact result of H.MS(0,13333 33333) is exactly 7 minutes and 59,99999988 secondsIn h.ms notation this result would be displayed as 0,075999 99998 8This fullprecision 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 10digit result should be 0,075999 99999But 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 12digit machine. Here, the input value is 0,13333 33333 33 hoursIn h.ms notation this result would be displayed as 0,075999 99999 988This exact result has 13 significant digits. So again, the last digit has to be rounded and the final, correct 12digit result is 0,075999 99999 99And that's exactly what the 32s returns.
So actually both the 41C and 15C are wrong :( Dieter
Edited: 22 Dec 2011, 3:00 p.m.
12212011, 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. 