Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 1 May 2012 02:05:03 +0200
From: Szabolcs Nagy <>
Subject: math todo

hello i thought i dump my math todo here
before the next big release

there are various fixes i didn't dare to
do (eg int32 -> uint32 cleanups) without
extensive test suit for math

	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)
	__isrel pulls in long double isnan so isless etc cannot be
	entirely inlined for float and double arguments
	definition of NAN (0/0) raises invalid exception where it is used
	signbit >>63 vs !!
>1ulp error:
	tan(pi/2-eps) round tozero
	exp(-inf) round upward
asm implementations:
	add proper comments (using #)
	x86_64 asm versions
long double:
	drop ld128 support? and move ldshape union to arch/
	at least rename the ieeel2 union and use the same union in all *l.c
	internal/longdbl.h needs cleanup
	efficient long double classification in math.h? (needs arch specific
volatile fix:
	-ffloat-store or -fexcess-precision=standard should fix most
	volatile issues so some of the volatile hacks can be cleaned up
fp exceptions:
	uniform inexact/invalid exception raising:
	common hacks to raise inexact when x!=0: (int)x == 0 and huge+x > 0
	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,..)
	dekker vs long double arithmetics
	scalb is buggy, do we need the *f and *l version?
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)
	tgamma, tgammaf
	(long double bessel)
	nextafterf on ld64
	lanczos approx as in boost/math/special_functions and python/Modules/mathmodule.c
	optimizable creal cimag (libm.h macro for internal code?)
	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
	Kahan, W. "Branch Cuts for Complex Elementary Functions, or Much Ado About Nothing's Sign Bit." 1987
	Hull, Fairgrieve, Tang "Implementing complex elementary functions using exception handling" 1994
	Hull, Fairgrieve, Tang "Implementing the complex arcsine and arccosine functions using exception handling" 1997
	see boost/math/complex, python/Modules/cmathmodule.c

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.