Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 30 Apr 2012 21:19:21 -0400
From: Rich Felker <>
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


> 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

BTW under asm, we may also want to switch to the faster acos

> 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

> 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


> 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



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.