I'm looking for a decent math library. It has to satisfy the following conditions :

1) When scanned, "#.#" has to equal #.# - ie... "5.1" has to equal 5.1 when scanned from a string. Because currently if I use sscanf on "5.1" to get a double and then printf the double back out with high precision, it is 5.0999999999999996 instead of 5.1, and this occurs far too often with other numbers as well, even if it is only off by 4e-16 or so. I want to be able to move from string to double and back without losing any precision.

2) It should support at least as many math functions as the C standard library.

3) C or C++ only.

4) Non GPL if possible, but maybe you can convince me otherwise if
a) My code doesn't have to be GPL too.
b) I'm not forced to release all of my source code, even if I might anyway.

5) Optional - extra features?

I looked at The wikipedia list article of numerical libraries, but about the only thing that looked good at first glance was the GNU MultiPrecision Library. The GNU Scientific Library doesn't seem to offer precision greater than doubles do, only a truckload of math functions.

The problem with GMP is that it uses the LGPL, and I still haven't wrapped my head around what you can and can't do with the (L)GPL. I wish there was a (L)GPL for dummies guide around somewhere.

So, any recommendations / experience to share with me on this matter?

You won't have a problem with LGPL libraries corrupting your source code as long as you dynamically link against them.

I love this library, even when I'm not programming OpenGL. It's just great all around.

You want to truncate digits? Why? If you want to eliminate rounding, multiply by the power of 10 you want to have the precision up to, floor() it, then divide again.
Or you could simply sprintf this number to a buffer, use strchr() to find the decimal point, use the index to the sought number for strcpy, etc. Sure, it'd be slower than pure math operations, but a library would slow things down as well.

I have a 32 bit assembler arbitrary precision library you can have if you want, but I haven't been motivated enough to finish the 64 bit version. To convert to assembly code for Windows, you'd have to add an underscore prefix to the global namespaces. I never did quite finish the transcendental functions either, but it does the fourbanger calculator stuff just fine, as well as print to ascii buffers and scan from ascii buffers.

No, I said I want to minimize rounding - ie maintain precision up to an arbitrary point, maybe around 30 significant digits or so. Multiplying and dividing by 10 won't help fix the failure in precision of statements like 0.1 or 1/10.

Also, super speed is not essential in this application. It won't be computationally expensive over long periods of time.

<runs for antibiotics>

I appreciate the offer, but I'm going to need trig functions.

I've already written a FormatDouble function, and it works fine. It retains the maximum amount of precision available from a double and strips leading and trailing zeros and optimizes the exponent for string length consideration.

What I'm using it for is a console/plotter program that lets you enter equations as strings and then evaluate / simplify / derive / integrate? / plot them.

The LUA interpreter has better precision than a C++ double - it doesn't have any problem with 5.1 or 0.1, or most other common (relatively small) numbers and has precision of somewhere around 14 digits.

BTW, keep comments like 'I don't actually know what I really want' to yourself. I've already stated several times that I want more precision than doubles afford, and I want perfect string to decimal data type and back to string conversions.

@Audric
That sounds reasonable enough.

The MAPM library is looking pretty good so far - it has most of the standard C math functions implemented and supports arbitrary precision math as well as conversion to and from c strings.

Except it isn't a basic type. It may be built-in to the language, but the CPU/FPU doesn't handle it directly. Software has to break it down, do the work, then reconstruct it.

C/C++'s basic types are what the processor deals with. You don't even get float and double if your target machine doesn't have an FPU (unless your compiler offers FPU emulation, but that's not required as part of the language).

At most, it could be part of libc/libstdc++, but there are already libraries which implement it just fine.

I don't think you should ask for something like that without specifying what your precision requirements are.

If you only care about destringifaction+stringification not producing the original value, simply limiting every decimal stringification to 14 digits meets your requirements well over a fairly wide range of numbers, though that's actually a decrease in precision.

On the other hand if you need purely decimal math, that's a very different thing (though it would solve the above problem as long as all stringifications were to decimal). Likewise if you need infinite precision.

Or you can use %a (C99), which uses a hexadecimal notation for floating-point values. The default precision allows you to distinguish between two double values.

a, A   (C99; not in SUSv2) For a conversion, the double argument  is  converted  to
       hexadecimal notation (using the letters abcdef) in the style [-]0xh.hhhhp±d;
       for A conversion the prefix 0X, the letters ABCDEF, and the exponent separa‐
       tor P is used.  There is one hexadecimal digit before the decimal point, and
       the number of digits after it is equal to the precision.  The default preci‐
       sion suffices for an exact representation of the value if an exact represen‐
       tation in base 2 exists and otherwise is sufficiently large  to  distinguish
       values  of  type  double.  The digit before the decimal point is unspecified
       for nonnormalized numbers, and nonzero but otherwise unspecified for normal‐
       ized numbers.

The decimal type in C# is not for mathematicians, but accountants.

My precision requirements are that string numbers have an exact representation when converted to data. With my current implementation using doubles, my command line calculator / function parser is too stupid to return 51 for 5.1/0.1. That's just not acceptable to me, nor should it be acceptable to anyone using a calculator program.

This is the basis of the problem - most base 2 floating point representations are just incapable of representing decimals correctly. If they used base 2 to represent the numerals and used a separate number to represent the decimal point, then there shouldn't ever be a problem with it, but you can't represent every number with powers of 1/2.

That's the same thing as the GNU Multi Precision library. I'm looking into it.

[EDIT]

Forgot the range check on second number, but you know what I mean...

[EDIT2]

The arbitrary precision lib I mentioned earlier does have transcendental functions, but some of them could be optimized with precalculated numbers in a file for identities, which I haven't bothered with.

I tried it just to see how fast it was on this 3.1Ghz Athlon II, but somehow argc & argv were getting corrupted. After hours of fiddling with gdb, valgrind and Electric Fence, I tried the Watcom compiler, which worked fine (although Watcom crashes on an fflush() ).

Printing gives out results like:

count = 7021

Input number    0.7021
Sin    0.6458224341509764981664646025062778090792175100125560862802365350598448
Cos    0.7634876446592358739582226598267228849622487768704818372243868793930424
Tan    0.8458845911504221153467969183513439373684976836083291157721866966077248

count = 7022

Input number    0.7022
Sin    0.6458987796862030057491918266634106923511167321066618731945697836968761
Cos    0.7634230585984901932657298394753035699212712280249010525166211455076285
Tan    0.846056157737701829266851733611519926546263348925174306300998247937501

count = 7023

Input number    0.7023
Sin    0.6459751187624417218523788222528204136464410918821905557397273206694932
Cos    0.7633584649035139329501939060000511971689937336425396753570132724535036
Tan    0.8462277533584315588906546332567283389122943855797825858950950746135725

and here's how long it takes to print out 10000 loops with 80 bytes in the integral part and 80 bytes in the fractional part. The first one is redirecting to results.txt, where the output above was copied from.

pepsi@fractal_comet:/home/prog/bignums 02:49 AM $ time t > results.txt

real    0m59.132s
user    0m59.021s
sys     0m0.087s
pepsi@fractal_comet:/home/prog/bignums 02:50 AM $ time t noprint

real    0m0.038s
user    0m0.038s
sys     0m0.000s
pepsi@fractal_comet:/home/prog/bignums 02:50 AM $ 

The second timing result is how long it takes to calculate the trig funcs (1/30 of a second for all 30000 results) but not printing to decimal (quite a chore in itself)

[EDIT5]

I forgot to show the input number for the trig stuff... edited all the above

[EDIT6]

Recompiling with 800 bytes of integral and decimal bytes with 700 decimal positions printed gives this for 100 loops

pepsi@fractal_comet:/home/prog/bignums 03:02 AM $ time t > results.txt

real    4m9.194s
user    4m8.927s
sys     0m0.093s
pepsi@fractal_comet:/home/prog/bignums 03:07 AM $ time t noprint

real    0m0.004s
user    0m0.003s
sys     0m0.000s

noprint is faster than before because only 100 loops

count = 42

Input number    0.42
Sin    0.4077604530595701859727871580863423156477998312272199837618432020183270288765336837439844031983341253779690576147116094979039277815379680051349489526859390640113444468728511707118838605394853620887365370981415293797665495368793143468270256405581832984876247762177846669463896709533912328054270139386495849713716053377167824292341132590924517670116080193774565000394404325176018879137001116501917905458262931179583116640073280342696907129516730267817169709076756630570369478068356496088806733562791025935518005717823975399647433911242565646284290408108965129580005045630325009645600351052252234931946795935673759622200090939484176528145403518844626429027118291618481207436517990068199382319726055853613
Cos    0.9130889403123082724360887896656672808656036779177695185367711006995955759007027812268532869219485750392032411157021985701743449718712839893630769060956987500869050561130530606277722475164033362715938822340958362676305487363307447311046606036732548594394880660779345469357363927362599236287787967113779712125417724313266162079002839798171344659068700365238628373106988573793108841436286988550471435158583090282785551299521559463196485941733155093326870424140702825354668014736012094116310173282063294354797176618106265223818473429154560119875265514193935088602078450686698516654784487568476528092182943197051363283336770971514484898843637969744795863457522041097293912185666895010296292417843629169566
Tan    0.4465725462845951080354340492493297863664702530228539431793643752790652121798457119308281093711337117351824302405127265043941078743201413802742986904431097907418452657673429572010439544368058258668460621337750507856743137674138128805462521543172690127434221187279537588377878373065777689804867923360071570888272946017486343012618629153112816524990960304473577139058272000642627832629543035542998512407586811092722803660439984439880202739952675782181893386116210218071303871409986764914583800844104115292506997715868582578179441467373632677384179542325076687281260631102061490708090583107700757824466976889133117431057537299832543055583282997302563566765119476476011271217072270990986942660758601073145