[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 23 Jan 2012 12:07:15 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: libm
On Mon, Jan 23, 2012 at 05:41:52PM +0100, Szabolcs Nagy wrote:
> i've looked into libm implementations
> to figure out what's best for musl
Thanks!!
> * reproducible semantics:
Unless others are deeply committed to having results match other
platforms/libcs bit-for-bit, this is not a major concern for me.
I'm happy with bit-exact just for non-transcendental (i.e. sqrt) and
1ulp (or even several ulp) max error for transcendental functions.
> * tradeoffs:
>
> modern libms (libmcr, libultim, crlibm) try to guarantee
> correctness but arg reduction and faithful (or even
> correct) rounding is hard to do and hard to verify
Correct arg reduction is important to me. Incorrect arg reduction is
equivalent to billions of billions of ulp error in the final results.
> * libms in practice:
>
> many functions are the same in glibc and the various
> bsd libcs (they are mostly based on fdlibm, but glibc
> 64bit double precision functions are from the gpl
> licensed libultim)
You really mean double, not extended? That's odd since fdlibm covers
double.. I wonder when/why they switched.
> the extended precision algorithms are reused across
> different libcs as well, but there are 80bit vs 128bit
> differences. the correctness of extended precision
> algorithms are much less studied (eg there are no
> correctly rounded versions or worstcases for 2pi arg
> reductions)
Any ideas how the different ones evolved (separately written or common
ancestor code, etc.) and where we should look to pull code from?
> most of the complex functions are simple once elementary
> functions are there (bsd libcs has bsd licensed
> implementations of these)
Well they don't have any more difficult numeric analysis issues, but
there are quite a few corner cases with complex functions which many
platforms have gotten wrong (issues with branch cuts and signed zeros,
etc.).
> conclusion:
>
> the simplest approach for musl at this point is to
> reuse the already available math functions
> (+run the available tests on them)
I generally agree, provided no major bugs are found - and even if they
are, they should be fixable.
> this can be done by diffing the various bsd and glibc
> functions and choosing the best one (usually they are
> the same except code organization and bit manipulation
> details)
That was my impression too.
> code and ideas from crlibm might be possible to use
> but that would take much more effort and knowledge
> (assuming we want small code size)
Yes, crlibm looks very interesting but also very large...
> designing new algorithms for elementary functions seems
> to require a huge effort and the best tradoffs are not
> even clear
Agreed. I think it's roughly as big a task as the rest of musl
combined, so it's best not to go there.
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.
