Date: Mon, 30 Apr 2012 21:19:21 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: math todo On Tue, May 01, 2012 at 02:05:03AM +0200, Szabolcs Nagy wrote: > hello i thought i dump my math todo here > before the next big release Thanks! > 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) I'd be happy to see more testing. :-) > math.h: > __isrel pulls in long double isnan so isless etc cannot be > entirely inlined for float and double arguments Indeed, this should be fixed asap. I'll see if I can write some clever macros to avoid bloating up the header too much. > definition of NAN (0/0) raises invalid exception where it is used This is only used as a fallback on compilers that don't have __builtin_nan, no? > signbit >>63 vs !! Hm? This has been fixed I think. > >1ulp error: > tan(pi/2-eps) round tozero > exp(-inf) round upward What's the issue here? exp(-inf) is an exact zero; there's no rounding involved. Are you saying in round-upward mode the result is nonzero with the current implementation? > asm implementations: > add proper comments (using #) > x86_64 asm versions With yesterday's commit, I think all the x86_64 asm that's possible with SSE2 is done. If we want asm for non-longdouble versions of transcendental functions, I think it will just involve moving the value from an SSE register to an FPU register and back... I have no idea how this would compare in performance to the C versions using SSE. BTW under asm, we may also want to switch to the faster acos implementation. > long double: > drop ld128 support? and move ldshape union to arch/ What ld128 support? I don't think we really want to "drop" it since it will probably be needed later, > at least rename the ieeel2 union and use the same union in all *l.c > internal/longdbl.h needs cleanup This cleanup stuff is low priority as long as it works, IMO. > efficient long double classification in math.h? (needs arch specific > things) I think this would potentially be worthwhile. Having bits/math.h would also allow us to remove float_t/double_t from alltypes.h (they're only used/needed by one header, math.h). > volatile fix: > -ffloat-store or -fexcess-precision=standard should fix most > volatile issues so some of the volatile hacks can be cleaned up I think it would be nice to try to ensure that the code still works with just -ffloat-store for older gcc versions that don't have -fexcess-precision=standard. > fp exceptions: > uniform inexact/invalid exception raising: > common hacks to raise inexact when x!=0: (int)x == 0 and huge+x > 0 I don't really care how uniform it is as long as it works, but it's fine to have this sort of cleanup as a low-priority goal. > 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? How so? > 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 Until we have a better one, couldn't we just use sqrt() as a first approximation then use Newton's method or a binary-search for the correct long double result? Or just return sqrt() since the only arch that doesn't have sqrtl asm yet is the one where ld==double. > tgamma, tgammaf Well we have these but they're inaccurate for some inputs. > (long double bessel) > nextafterf on ld64 Eh? > tgamma: > lanczos approx as in boost/math/special_functions and python/Modules/mathmodule.c > complex > optimizable creal cimag (libm.h macro for internal code?) This was done a long time ago. > 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=x, .a=y > fix casin[h], cacos[h], catan[h] (complex arith cornercases) > add missing long double versions Ok. Rich
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.