HP Forum Archive 13

[ Return to Index | Top of Index ]

hp35 is magic Message #1 Posted by hugh steers on 1 Sept 2003, 5:34 p.m. the recent mention of csim (thanks jonathan) has got me reading the hp35 assembler again... ive been trying to experiment with cordic calculation methods (as used in the 35). although theres several papers out there, there's not a lot of code (i couldnt find any). so i decided to try to write some. im shifting and adding in binary, so i need 53 bits (for a double) and 53 constants (one for each mantissa bit). now, i assume the 35 worked in decimal right through, so it would need 10 ten digit constants but use each more than once (binary uses each constant for add or subtract just once). worse, it would need to implement the hyperbolic iteration (for logs and square root), which means it needs the atanh constants as well as the atan ones. thats 20 constants. i dont see those constants in the assember. where are they?? i read the original paper by j.s.walther of hp, "unified algorithms for elementary functions". here he describes some trickery for only storing half the constants. but i still dont see even 10 in the assember (and i know it works!). there are about 5 or so patches of "load constant X". theres more. in my version ive separated the logic for linear, circular and hyperbolic iteration. i know you can combine them using more inner-loop tests, but, it gets quite cumbersome, and you have to do the hyperbolic 3k+1 malarkey otherwise your answers are wrong. which brings me to the final question. why didnt early models have hyperbolic functions on keyboard, since internally hyp was used for log, exp and square root. i can understand the space restriction at first, but what about hp80 and hp55. perhaps they didnt think anyone wanted them. or was it because it didnt really do the 3k+1 correction internally but somehow log and sqrt could be extracted accurately. or perhaps its voodoo magic ;_) my code: http://www.voidware.com/cordic.htm

Re: hp35 is magic Message #2 Posted by Nelson M. Sicuro (Brazil) on 1 Sept 2003, 6:41 p.m., in response to message #1 by hugh steers Can you describe this method (or point to some link) in "algorithmic" form (not C or other language)? I'm planning to build a calculator with microcontrollers, initially as a emulator for HP ROMS and in the future a calculator of my own as a "compilation" of various algorithms and functions of my interest (as merging the functions of the HP-15C and HP-16C). I'll try to get the 15C ROM, but it isn't a easy task. In another way, I can use the HP-42S's ROM and modify the assembler to fit in my emulator (Saturn CPU) and 7-segment display (to fit in a HP-32E case with its display/keyboard). Best regards, Nelson P.S. your scicalc for Palm OS is a beauty! I can't imagine such a precision on a real pocket calculator... Or can I? Building one from scratch is a lot of work, but as a hobby (read "open source" and "free") project, who knows...

Re: hp35 is magic Message #3 Posted by hugh on 1 Sept 2003, 7:01 p.m., in response to message #2 by Nelson M. Sicuro (Brazil) google search for "crdcsrvy". i found that the most useful. j.s.walthers paper is here, http://www.voidware.com/uafef.pdf btw, im currently working on scicalc v3. originally, i thought v3 would extent v2. but v3 is completely new. it will be able to handle symbolic expressions for solve, integrate, factorize and so on.... i reached this conclusion by reading the 15c advanced functions handbook. there are problems that no numerical method can touch (eg integrate sin(1/x) from 1 to inf). it has a value. what is it? the trick (as in the book) is to first transform it into another expression that can be handled numerically.

Re: hp35 is magic Message #4 Posted by Nelson M. Sicuro (Brazil) on 1 Sept 2003, 7:22 p.m., in response to message #3 by hugh Thanks, I'll read that paper. I'm not a mathematician but I'm really interested in numerical algorithms (as I use many of them in my work as a Delphi programmer, now working on forest growing/planning software). How is the compiler that you use for Palm platform? I'm really interested in porting the EMU42 to the PalmOS, but I'm not a C programmer, barely read it... If it was in assembler, no problem at all! (I think I'll put this task on my "hobby projects" list ;-) Best regards! Nelson

Re: hp35 is magic Message #5 Posted by Bill Wiese on 1 Sept 2003, 9:54 p.m., in response to message #1 by hugh steers Hi... why didnt early models have hyperbolic functions on keyboard, since internally hyp was used for log, exp and square root. i can understand the space restriction at first ... but somehow log and sqrt could be extracted accurately Well I'm guessing that they simply ran out of ROM space so hyperbolics were first to go. The HP35 did all its stuff in, what, 768 instructions? And that ROM was chock-full. As programmability was added (HP25, etc.) the extra ROM space would've gone to support these features. Also features were determined also by marketing folks so hyperbolics may have been down the list. I don't think square root was done via CORDIC methods - more likely an algorithm very similar to division or a Newton's method which works very well for sqrt(x). Bill

Re: hp35 is magic Message #6 Posted by hugh on 2 Sept 2003, 8:22 a.m., in response to message #5 by Bill Wiese im thinking they didnt have the rom space *not* to do hyperbolic functions! and then using exp(x) = sinh(x) + cosh(x) and log(x) = 2atanh((x-1)/(x+1)). something im speculating on is that hyperbolic functions have always been, at least internally, present on calculators but they've chosen not to put them on keyboard. does anyone know how early japanese makers like sharp & casio did their scientific functions. did they copy hp or a different technique altogether.

Re: hp35 is magic Message #7 Posted by Bill Wiese on 2 Sept 2003, 11:35 a.m., in response to message #6 by hugh Hi Hugh... There are *direct* CORDIC shift & add methods (don't have the reference but I've seen 'em) for the hyperbolics, log funcs, etc. That is, the hyp funcs are not "derived". This generally seems to allow better accuracy in the last place (digit or bit depending on radix). This 'ulp' issue is a big thing for floating-point engine designers. There is even concern about rounding/last-place error dealing with scaling & range reduction preprocessing (i.e, bringing input into a range where actual calculations work properly, converge, etc.) You might want to take a look at the books by: J. M. Muller, "Elementary Functions" (Birkhauser/Boston); Israel Koren, (paperbound, don't have title at hand); Cody & Waite,"Software Manual for the Elementary Functions"; You'll see a lot about last-digit concerns, rounding matters, etc. Many many Japanese sci calcs of Woodstock vintage do NOT have the same accuracy on logs & trigs. Sometimes seem accurate to only 5+ dec places! Bill Wiese San Jose, CA

Re: hp35 is magic Message #8 Posted by hugh on 2 Sept 2003, 11:45 a.m., in response to message #7 by Bill Wiese thanks bill. i'll check out those references, -- hugh.

Re: hp35 is magic Message #9 Posted by David Smith on 2 Sept 2003, 2:54 p.m., in response to message #1 by hugh steers In the old reference "Collected Algorithms of the ACM" there was a cute continued fraction routine. You ran a rather simple iteration a few times and got a couple of numbers. By combining these numbers in various simple ways you could got trigs, exponetials, etc. I always thought it was kinda neat.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall