[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120501011921.GK14673@brightrain.aerifal.cx>
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[0]=x, .a[1]=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.
