From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/607 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: libm Date: Sun, 4 Mar 2012 15:50:41 +0100 Message-ID: <20120304145041.GB5728@port70.net> References: <20120123164152.GZ31975@port70.net> <20120123170715.GA197@brightrain.aerifal.cx> <20120227210253.GA25004@port70.net> <20120227222437.GH184@brightrain.aerifal.cx> <20120303225758.GA5728@port70.net> <20120304065340.GT184@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1330872656 9504 80.91.229.3 (4 Mar 2012 14:50:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 4 Mar 2012 14:50:56 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-608-gllmg-musl=m.gmane.org@lists.openwall.com Sun Mar 04 15:50:56 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1S4Cly-0006mN-4o for gllmg-musl@plane.gmane.org; Sun, 04 Mar 2012 15:50:54 +0100 Original-Received: (qmail 32303 invoked by uid 550); 4 Mar 2012 14:50:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32295 invoked from network); 4 Mar 2012 14:50:53 -0000 Content-Disposition: inline In-Reply-To: <20120304065340.GT184@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:607 Archived-At: * Rich Felker [2012-03-04 01:53:40 -0500]: > On Sat, Mar 03, 2012 at 11:57:58PM +0100, Szabolcs Nagy wrote: > > see > > http://nsz.repo.hu/libm > > Some initial questions... > > - Why are there two versions (one "slow") of rem_pio2? > originally code they are __ieee754_rem_pio2 and __kernel_rem_pio2 maybe slow is not the best name the slow version is only called (by the non-slow one) for large numbers (>2^20) when multi precision arithmetic is needed using many bits of 2/pi (there is a large ipio2 array in that file) maybe it should be called __rem_pio2_large ? > - Is __invtrigl.c used? It clashes with the app-reserved namespace. > fixed it is used by long double inv trig functions > gcc-specific hacks involving __typeof__. If gcc4 allows _Generic even > with -std=c99 etc. then I think _Generic is the best. > no, gcc does not support it (i have a gcc 4.7 built from svn in october and it has -std=c1x, but _Generic is not supported) i wrote it using generic since i couldnt come up with any way to solve it in c99 > > how to do the long double ifdefs? > > #if LDBL_MANT_DIG == ... > ok will do that > > check x87 fpu precision setting from ld80 code? > > (or we assume it's extended precision) > > All existing code (well, mainly macro definitions) in musl assumes its > set to extended, and we provide no code to change it. > ok > > preferred way of handling consts? > > (freebsd code uses 1.0f, (float)1, 0x1p0, static const float one=1;..) > > (i'm not sure why 'one' or 'zero' is used instead of 1 or 0 > > maybe it's another compiler float-store bug workaround) > > i assume (float)1.0 is the same as 1f > > I like 1.0f, etc. BTW are you sure 1f is valid C? Certainly 1L is not > a valid alternative for 1.0L when you want long double.. > ok (1f might be wrong, i just wrote that in the mail) > > i wonder if it's ok to use a polyeval(coeffs, x) function instead > > of writing out the polynomial (some openbsd long double code uses > > such thing but not everywhere) > > I suspect the functions that aren't using it right now depend on a > particular evaluation order to avoid loss of precision. I could be > wrong though; that's just my best guess. > it's just a minor detail, but this was one of the parts where things could be a bit nicer and more consistent (probably) (coeffs in array, and using some static inline eval etc, it might not be a good idea for some technical reason, but i dont yet see why) > > todo: > > - move the code to musl tree so the changes are recorded there > > Very interested in doing this sooner rather than later. > ok complex is missing but it is not hard to add (if you want to wait for it) the parts i wrote may need some review or testing (it can be done after merging of course) (it would be nice if musl had a dedicated testing package where one could add test functions and easy to run) > > - fix int32_t issues (there are many) > > - define isnan, signbit, etc macros to be efficient and > > change bithacks into isnan etc in the code when appropriate > > Try something like: > > union __float_rep { float __x; uint32_t __r; }; > #define __FLOAT_REP(x) ((union __float_rep){x}.__r) > > #define isnan(x) \ > sizeof(x)==sizeof(float) ? (__FLOAT_REP(x)&0x7fffffff)>0x7f800000 : \ > sizeof(x)==sizeof(double) ? (__DOUBLE_REP(x)&.... > > Does that work? Of course it would work to just let it get converted > up implicitly to long double and just have one case, but that would be > more expensive I think. > ok so using compound literal i was thinking about this something like this will work the difficult part is figuring out if it can be used internally (many math functions start by turning the float/double into unsigned int, then doing various checks to handle special cases like nan, inf, signbit, etc using bithacks i thought most of them could be isnan() etc eg compare the current fmax to the freebsd one i'm not sure if this can be done in general because some bit hacks will be needed anyway and it might be better doing the conversion once many functions do checks like if(x < 12.34) ... else if(x < 78.9) ... but using unsigned int arithmetics like if ((x&bitmask) < 0xabcdef) ... which is not clear, but i guess this cannot be changed because float compare does a different thing but it would be nice to reduce the bithacks without changing the semantics or performance)