Category: Uncategorized

It started as a small task to save space for a calculator project with 1 function. Now, as of mid October 2026, fp64lib transformed into a full blown library with more than 100 functions! And it’s still growing, as the IEEE 754 standard contains a wealth of functions that should/could be implemented.

I hope you like it. If so, consider giving me a star on my github page or leave a comment in the discussion forum. I’m always happy to see, what you use the library for. This gives me additional energy to keep up maintaining and extending it.

fp64_lib was extended to include the functions in section 5.3.1 of the IEEE Standard 754-2019:
fp64_nextUp(x) returns the least possible number that is just > x. Usually, the difference of nextUp(x)-x is 1ulp (unit in last place).
fp64_nextDown(x) returns the biggest possible number that is just < x.

See the documentation for some interesting examples.

V1.1.32 include some small changed to bring the makefile up-to-date for the linux community.

With V1.1.31, fp64_pow(x,y) returns results if both x and y are negative, if y is an integer, e.g. fp64_pow(-2,-2) = 0.25, or fp64_pow(-2,-3) = -0.125. If y is not an integer, the result is NaN, e.g. fp64_pow(-2,-2.5) = NaN.

NB.: When y is not an integer, the correct mathematical result can no longer be represented as a real number but would be a complex number, e.g. (-2)^(-2.5) = 0 – 0.176776695297i.

For some boundary conditions and malformed inputs, fp64_strtod was updated to behave properly. For values in the range of [-0.5,-1.0], fp64_round was updated to produce the correct rounding.

In V1.1.29, the (flash) memory footprint for a number of routines was reduced. Furthermore, fp64_compare(a,b) returned a wrong result when a == -b. This was fixed.

V1.1.28 includes some space optimizations in the string conversion routines and fixed the handling of -0 in fp64_toString

The handling of +0 and -0 was changed, according to the IEEE 754 standard: (+0)-(+0) now returns (+), and ftoa(-0) will return “-0.E0”.

For some limited number of special cases, fp64_compare returned the wrong result. This is fixed now.

I cleaned up the library reference, inserted a table of contents and organized the reference in a slightly different way: All the conversion functions are now grouped together towards the end of the reference. Additionally, links between the documentation of the functional groups and the library reference were installed. All this shold it make easier to quickly find the functions needed.

Due to some questions regarding sin(pi), an article is available explaing the problems of floating point math: fp64_sin(float64_NUMBER_PI) is not 0.