Upsilon

mirror of https://github.com/UpsilonNumworks/Upsilon.git synced 2026-03-19 13:50:28 +01:00

Files

Arthur Camouseigt 1995781a9f [Poincare/IEEE754] Changed methods to use std function

Implemented std::nextafter to replace hand made one.
Methods next and previous are no longer making the difference between -0
and +0

Change-Id: I42e1a073623b70656d9df954694803840cf3088c

2020-11-04 15:30:53 +01:00

openbsd

[Poincare/IEEE754] Changed methods to use std function

2020-11-04 15:30:53 +01:00

softfloat

[liba] Add __aeabi_ul2d implementation

2018-01-23 10:24:52 +01:00

sqlite

Liba cleanup

2015-05-31 13:51:41 +02:00

README.txt

Use OpenBSD 4.9's libm

2017-11-17 11:59:49 +01:00

README.txt

"softfloat": Unaltered files from SoftFloat v3c.
http://www.jhauser.us/arithmetic/SoftFloat.html

"openbsd": Unaltered files from OpenBSD 4.9. Original path is "lib/libm/src"
"openbsd/include": Compatibility headers needed to build files from OpenBSD.
http://www.openbsd.org

Why use OpenBSD's libm? First and foremost, nearly everyone use fdlibm in a way
or another, and OpenBSD is no exception. That being said, OpenBSD comes with a
single-precision variant (which fdlibm itself lacks). And more interestingly,
this variant does all its computation in single-precision (it never upgrades to
double-precision). In our case, this is very interesting because we're doing
single-precision computation when we better performance at the cost of accuracy,
and in our case our hardware has a single-precision FPU so switching to double
can yield much lower performances.

Last but not least, we're using OpenBSD 4.9 and not the latest one because this
version still has all the double precision code (some of it got removed later on
in favor of a "long double" version).