[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 1 May 2012 02:05:03 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: math todo
hello i thought i dump my math todo here
before the next big release
there are various fixes i didn't dare to
do (eg int32 -> uint32 cleanups) without
extensive test suit for math
tests:
there is still a lot to do for testing
it would be nice to have test vectors for every math
functions and cover the difficult cases for the most
common functions (see c99 F.9, G.6, crlibm, ucb test)
there are many open issues (long double handling,
exception and rounding mode testing, randomized tests,
tests based on math identities)
math.h:
__isrel pulls in long double isnan so isless etc cannot be
entirely inlined for float and double arguments
definition of NAN (0/0) raises invalid exception where it is used
signbit >>63 vs !!
>1ulp error:
tan(pi/2-eps) round tozero
exp(-inf) round upward
asm implementations:
add proper comments (using #)
x86_64 asm versions
long double:
drop ld128 support? and move ldshape union to arch/
at least rename the ieeel2 union and use the same union in all *l.c
internal/longdbl.h needs cleanup
efficient long double classification in math.h? (needs arch specific
things)
volatile fix:
-ffloat-store or -fexcess-precision=standard should fix most
volatile issues so some of the volatile hacks can be cleaned up
fp exceptions:
uniform inexact/invalid exception raising:
common hacks to raise inexact when x!=0: (int)x == 0 and huge+x > 0
round:
shouldn't raise inexact exception (or fix lround if it does)
round to int:
use +0x1.8p52 trick where it is applicable (rem_pio2, rint, lgamma_r)
trigonometric functions:
__rem_pio2_large: maybe returning only 2 bits is enough?
__tan: 3rd arg semantics is probably not optimal
sinf,cosf: return sindf(-y) vs -sindf(y)?
__sin,__cos,..: z,w,.. -> x2,x4,.. so degree is easier to see
use long double pi in long double code? (casin, cacos,..)
log2:
dekker vs long double arithmetics
scalbf:
scalb is buggy, do we need the *f and *l version?
generic code fixes:
int32_t -> uint32_t conversion (can be subtle, so testing is needed)
+= 1, -= 1 -> ++, --
TWO52, twom1000 vs tiny (renames where it makes sense)
remove overflow thresholds (sinh, cosh) when result overflows anyway?
sign bit checking convention (sqrt.c)
missing:
sqrtl
tgamma, tgammaf
(long double bessel)
nextafterf on ld64
tgamma:
lanczos approx as in boost/math/special_functions and python/Modules/mathmodule.c
complex
optimizable creal cimag (libm.h macro for internal code?)
include <math.h> and <complex.h> instead of libm.h (once there are efficient creal etc.)
cpack(x,y) vs x+I*y vs union .a[0]=x, .a[1]=y
fix casin[h], cacos[h], catan[h] (complex arith cornercases)
add missing long double versions
Kahan, W. "Branch Cuts for Complex Elementary Functions, or Much Ado About Nothing's Sign Bit." 1987
Hull, Fairgrieve, Tang "Implementing complex elementary functions using exception handling" 1994
Hull, Fairgrieve, Tang "Implementing the complex arcsine and arccosine functions using exception handling" 1997
see boost/math/complex, python/Modules/cmathmodule.c
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
