akcs.joehorn@hpcvbbs.UUCP (Joseph K. Horn) (06/12/91)
Any mathematicians out there? I need your help.
All the code I've seen written to handle Feet.Inches pulls the number
apart into its int and frac parts, handles them, and then recombines.
But some years ago, this algorithm for Hours.MinSec was published:
+-----------------------------------------+
| HMS->(x) = x + FP(x)/1.5 + FP(x*100)/90 |
+-----------------------------------------+
The fact that it works mystifies me. My question is: If this kind of
algorithm works for H.MS, can similar ones be created for any arbitrary
fractional systems, like Yards.FeetInches? If so, how?
It would sure shrink and speed up a lot of programs.
Thanx.
BTW, just in case it helps or amuses, here's the inverse function:
+-----------------------------------------+
| ->HMS(x) = x - .4*FP(x) - .004*FP(x*60) |
+-----------------------------------------+
-- Joe Horn --bson@rice-chex.ai.mit.edu (Jan Brittenson) (06/14/91)
In a posting of [12 Jun 91 05:40:05 GMT] akcs.joehorn@hpcvbbs.UUCP (Joseph K. Horn) writes: > +-----------------------------------------+ > | HMS->(x) = x + FP(x)/1.5 + FP(x*100)/90 | > +-----------------------------------------+ > My question is: If this kind of algorithm works for H.MS, can similar > ones be created for any arbitrary fractional systems, like > Yards.FeetInches? If so, how? How about: YFI->(x) = x + FP(x) * 7/3 + FP(x*10) * 22/9 Where YFI is: y.fii I.e. 1 yard, 2 feet, 5 inches = 1.205 --- So, how does it work? Pretty simple actually. The first term maps the integer part 1:1 (no conversion necessary). But it also maps the .f and ..ii parts 1:1, so they need some adjustment. Feet map 1:0.3, so as far as feet are concerned we fulfill the following equation to get the feet back in line: 1 = 0.3 + 0.3 * k ==> k = (1-0.3)/0.3 = 7/3 So we now have: YFI->(x) = x + FP(x) * 7/3 Note that we use FP() since we have already taken care of the integer part (which mapped 1:1). This also maps the ..ii part, so again we need to adjust it - we would like it to map 1:0.036 (i.e. 3 * 12in = 1ft): 1 = 0.036 + 0.036 * k + 0.36 * m ==> m = (1-0.036-0.036*7/3)/0.36 = 22/9 So now we have our final term. YFI->(x) = x + FP(x) * 7/3 + FP(x*10) * 22/9 We multiply by ten and discard the IP to get rid of what is already mapped. Apologies if this sounds confusing. -- Jan Brittenson bson@ai.mit.edu
woodhams@phoenix.Princeton.EDU (Michael Woodhams) (06/14/91)
In article <2855ad7d:3432comp.sys.handhelds@hpcvbbs.UUCP> akcs.joehorn@hpcvbbs.UUCP (Joseph K. Horn) writes: >Any mathematicians out there? I need your help. > >All the code I've seen written to handle Feet.Inches pulls the number >apart into its int and frac parts, handles them, and then recombines. > >But some years ago, this algorithm for Hours.MinSec was published: > > +-----------------------------------------+ > | HMS->(x) = x + FP(x)/1.5 + FP(x*100)/90 | > +-----------------------------------------+ > >The fact that it works mystifies me. My question is: If this kind of >algorithm works for H.MS, can similar ones be created for any arbitrary >fractional systems, like Yards.FeetInches? If so, how? HMS->(H.MMSS) = H.MMSS + 0.MMSS/1.5 + 0.SS/90 = H + MM/100 + SS/10000 + MM/150 + SS/15000 + SS/9000 = H + MM(1/100+1/150) + SS(1/10000+1/15000+1/9000) = H + MM/60 + SS/3600 as required. The solution to the yards, feet, inches problem is obvious: use metrics. Let YFI->(Y.FII) convert yards.feet_inches to decimal yards, and assume it is of the form YFI->(x) = x + FP(x)/a + FP(x*10)/b and solve for a and b: YFI->(Y.FII) = Y.FII + 0.FII/a + 0.II/b = Y + F/10 + II/1000 + F/(10*a) + II/(1000*a) + II/(100*b) = Y + F*(a+1)/(10*a) + II*(a*b+b+10*a)/(1000*a*b) = Y + F/3 + II/36 so (a+1)/(10*a) = 1/3 => a=3/7 1/36 = (a*b+b+10*a)/(1000*a*b) = (3*b/7+b+30/7)/(3000*b/7) = (3*b+7*b+30)/(3000*b) = (b+3)/(300*b) => b=9/22 so YFI->(x) = x + FP(x)*7/3 + FP(x*10)*22/9 The reverse transformation is left as an exercise for the student.
HCLIMER%UTCVM.BITNET@CUNYVM.CUNY.EDU (Harold Climer) (06/14/91)
On Fri, 14 Jun 1991 09:26 CST you said: >Relay-Version: VMS News - V6.0-3 14/03/90 VAX/VMS V5.4; site gacvx2.gac.edu >Path: > gacvx2.gac.edu!noc.MR.NET!msi.umn.edu!umeecs!caen!zaphod.mps.ohio-state.edu! > >cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!princeton!phoenix.Princ > eton.EDU!woodhams >Newsgroups: comp.sys.handhelds >Subject: Re: HP 48 Yards.FeetInches >Message-ID: <10737@idunno.Princeton.EDU> >From: woodhams@phoenix.Princeton.EDU (Michael Woodhams) >Date: 13 Jun 91 23:56:15 GMT >Sender: news@idunno.Princeton.EDU >References: <2855ad7d:3432comp.sys.handhelds@hpcvbbs.UUCP> >Organization: Princeton University Observatory >Nntp-Posting-Host: phoenix.princeton.edu >Lines: 43 > >In article <2855ad7d:3432comp.sys.handhelds@hpcvbbs.UUCP> > akcs.joehorn@hpcvbbs.UUCP (Joseph K. Horn) writes: >>Any mathematicians out there? I need your help. >> >>All the code I've seen written to handle Feet.Inches pulls the number >>apart into its int and frac parts, handles them, and then recombines. >> >>But some years ago, this algorithm for Hours.MinSec was published: >> >> +-----------------------------------------+ >> | HMS->(x) = x + FP(x)/1.5 + FP(x*100)/90 | >> +-----------------------------------------+ >> >>The fact that it works mystifies me. My question is: If this kind of >>algorithm works for H.MS, can similar ones be created for any arbitrary >>fractional systems, like Yards.FeetInches? If so, how? > >HMS->(H.MMSS) = H.MMSS + 0.MMSS/1.5 + 0.SS/90 > = H + MM/100 + SS/10000 + MM/150 + SS/15000 + SS/9000 > = H + MM(1/100+1/150) + SS(1/10000+1/15000+1/9000) > = H + MM/60 + SS/3600 as required. > >The solution to the yards, feet, inches problem is obvious: use metrics. > >Let YFI->(Y.FII) convert yards.feet_inches to decimal yards, and >assume it is of the form > >YFI->(x) = x + FP(x)/a + FP(x*10)/b > >and solve for a and b: > >YFI->(Y.FII) = Y.FII + 0.FII/a + 0.II/b > = Y + F/10 + II/1000 + F/(10*a) + II/(1000*a) + II/(100*b) > = Y + F*(a+1)/(10*a) + II*(a*b+b+10*a)/(1000*a*b) > = Y + F/3 + II/36 >so (a+1)/(10*a) = 1/3 => a=3/7 >1/36 = (a*b+b+10*a)/(1000*a*b) > = (3*b/7+b+30/7)/(3000*b/7) > = (3*b+7*b+30)/(3000*b) > = (b+3)/(300*b) => b=9/22 >so >YFI->(x) = x + FP(x)*7/3 + FP(x*10)*22/9 > >The reverse transformation is left as an exercise for the student. Left as an exercise for the student. How I hate those words. I thought I would never see them here. I had enough of them when we used Keith R. Symon's "Mechanics" for Classical Mechanics at UTC (Physics by the way ). I also hate it should be obvious. It sure as hell wasn't always obvious to us.(Seemed like he always skipped 10 or 12 steps between the "obvious" parts.) Harold Climer Physics Department U. Tennessee at Chattanooga
akcs.joehorn@hpcvbbs.UUCP (Joseph K. Horn) (06/15/91)
Harold Climer says he hates the words "left as an exercise for the student." Although it made me laugh, because we all share the frustration, I hope everyone is aware that that phrase is merely a polite euphemism for "although I know how to do it, I really don't have the time to explain it, but I think you're smart enough to figure out out on your own, and hey, it's kinda fun to re-invent the wheel anyhow." To all the folks who responded to the yards.feetinches problem: THANX!! -- Joe Horn --
rrd@hpfcso.FC.HP.COM (Ray Depew) (06/25/91)
Okay, Harold started it: >>The reverse transformation is left as an exercise for the student. > Left as an exercise for the student. How I hate those words. >I thought I would never see them here. I had enough of them when we used >Keith R. Symon's "Mechanics" for Classical Mechanics at UTC (Physics by the way >). I also hate it should be obvious. It sure as hell wasn't always obvious to >us.(Seemed like he always skipped 10 or 12 steps between the "obvious" parts.) I tried "it is obvious that..." on a midterm in one of my Chem E classes once. The prof was amused, but he didn't buy it. On the same midterm, one of my friends was desparate enough (and time was almost up) that he even tried "...and then a miracle happens." The prof didn't buy that, either. Not even at BYU. Ray HP ICBD -- IC's By Decree Fort Collins, Colorado rrd@hpfitst1.hp.com