Decimal floating point


I just started work on adding support for decimal floating point to Free42. I'm getting close to the point where I can hook an actual decimal library into the code, and I'm now on the lookout for the best code to use.

Hugh Steers kindly gave me a copy of the decimal code he wrote for OpenRPN, and I may decide to use that code eventually - it has an unrestrictive license and it's fast, but because of its encoding scheme it is not very memory-efficient, and at present it still lacks a few functions I need (hyperbolics, gamma, ln(1+x), exp(x)-1).

So, does anyone know of any other options? The IBM decNumber code has licensing restrictions I'm not sure I'm prepared to live with... Something that implements IEEE-754R (including "extended", preferably) and comes under a nice BSD-ish license would be perfect, but I guess that may be a bit much to hope for...

(One cute benefit of the Free42 code restructuring is that I'm going to support the use of extra-wide numbers internally (for complex and matrix computations), so on platforms where "long double" really is longer than plain "double", you'll get some pretty decent accuracy when stress testing INVRT with Hilbert matrices and such... Something to keep fans of binary happy. If they're using Linux, anyway -- VC++ 6.0 does not support "long double" so unless I switch to different development software, the 80-bit capability of your PC's FPU will continue to sit idle. And PalmOS (or rather, MathLib) won't do long double, period. Oh, well, enough rambling.)

- Thomas

Edited: 14 Feb 2006, 6:26 p.m.


hi thomas,

for your long doubles, take a look at this:

its a handy template i wrote that turns your doubles into double-doubles. and you can re-apply it, to turn your double-doubles into double-double-doubles and so on!

you can recompile my BCD library with any N precision. i think, originally i set N to use 24 decimal digits. this was to be pretty confident of 20 digit accurate results. it should be good for sqrt too, but all the trigs are designed to be 20 digit accurate, although in most you could simply increase the number of terms used in the calculations.

a while back i looked at the IBM library, however the license isnt very clear. the thing i did acertain is that it isnt BCD in the usual sense. it works with large binary integers which it converts to decimal on IO. this has the advantage of a smaller representation, but you do need a double sized accumulator eg. for multiply.

incidently, i'm working on a new BCD float library for my "exact" calculator which is variable precision. the fun part is writing the arbrary precision implementations of functions. eg here's the gamma function i've only recently coded:

exact -acc 50
Exact! engine (experimental) V1.03
Usage: exact [-max <max-digits>] [-acc <accurate-digits>]
enter expression to evaluate. variables, x=<expr>
`ans' is last result. `clear' erases all variables
`i' is sqrt(-1). blank line to quit. (min accuracy 50, working accuracy 60)
> gamma(20+17i)
= -1.4506843033047183744112948625133950394899762252240E14-4.9626218780536756371909659359160242411188406767529E13i_

best regards,

Edited: 17 Feb 2006, 9:09 a.m.


Hi Hugh,

I've more or less decided to use your code -- nice license, and if I use 12 bytes, I'll get an effective 17 digits, which is good enough for a 42S simulator (and in binary mode, I can use "long double" without changing the memory footprint, and that ought to make fans of ill-conditioned linear systems happy).

I'm still going to need hyperbolics, gamma, log1p, and expm1, but that, at least, is not a show-stopper as these are not too hard to fake.

BTW, do you know of any nice binary<->string routines? The code I wrote for Free42 works fine with "double", but it uses a look-up table that becomes a bit large when using "long double". For the Unix and Windows versions, I'll get around that by using sprintf and sscanf instead, but on PalmOS, that is not an option...


- Thomas


Hugh says:

> gamma(20+17i)
= -1.4506843033047183744112948625133950394899762252240E14-4.9626218780536756371909659359160242411188406767529E13i_

Both Mathematica and Maple say that gamma(20+17i) is about:

-6.65309788E13 + 1.381348614E14 i

You've got a lot of digits, but they all seem to be wrong. Any idea why?

Possibly Related Threads...
Thread Author Replies Views Last Post
  HP PRIME: derivative at a point Alasdair McAndrew 2 832 11-19-2013, 06:52 AM
Last Post: parisse
  Binary versus Decimal prefixes bill platt 22 3,437 04-27-2013, 11:22 AM
Last Post: Walter B
  Decimal/Binary Conversions for the HP 39gii - 3/16/2013 Eddie W. Shore 0 611 03-16-2013, 04:30 PM
Last Post: Eddie W. Shore
  HP28C/S ROM entry point lists update Christoph Giesselink 0 623 01-31-2013, 02:21 PM
Last Post: Christoph Giesselink
  HP-41 ROM Polling Point at FF5 Dan Grelinger 2 836 01-11-2013, 06:00 PM
Last Post: Monte Dalrymple
  33s Decimal Point Matt Agajanian 4 1,198 11-06-2012, 09:20 PM
Last Post: Matt Agajanian
  Obtaining More Decimal Digits (50g) Eddie W. Shore 3 938 09-13-2012, 05:38 PM
Last Post: Gilles Carpentier
  HP-35A/21 D.MS<-->Decimal degrees routines Matt Agajanian 9 1,856 03-29-2012, 11:03 AM
Last Post: Matt Agajanian
  wp34S IEEE Floating-Point Conversions Jake Schwartz 12 1,674 06-08-2011, 10:46 AM
Last Post: Jake Schwartz
  HP 41CX Decimal Point restore Joseph Banki 5 960 04-25-2011, 12:38 PM
Last Post: C.Ret

Forum Jump: