tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Google Summer of Code proposal - libm audit
Dear all,
my name is Stathis Kamperis and I'm proposing the following project as
candidate for this year's Google Summer of Code:
"Audit, unit testing and improvements of the NetBSD math library".
Our math library, which is descendant of Sun's libm (just like most
BSDs'), has quite a few deficiencies:
1. Lacks an extensive unit test suite
2. Certain functions are unimplemented, especially the long double versions
3. Lacks proper error handling / floating point exceptions
4. Lacks formal proof of the implemented algorithms (besides the
comments and the bibliographic references in the code)
5. Lacks documentation on average time, worst-case time and memory
consumption of the implemented algorithms
6. Lacks documentation on rounding modes, error bounds (for some
functions the ULPs are mentioned in math(3) but the list isn't
complete)
NetBSD is being used (at least by a few of us) for scientific
computation, where some sort of quality assurance is nonnegotiable.
Moreover, a lot of modern dynamic languages sit on top of host's libm
implementation. Therefore, whatever glitches the underneath library
has, they propagate to upper layers (I bet this argument will touch
all Python/Ruby developers out there :P).
I don't claim that I am a coding god nor that I will magically turn a
mediocre libm into an outstanding one in the time-frame of a summer.
There's a lot of scientific papers to read myself regarding floating
point arithmetic, and a lot of code to write before starting to 'fix'
things.
Ideally, I'd like to deliver:
1. A certain number of unit tests for every math function. The ATF
would fit nicely here. As part of last year's gSoC, I've written some
math test cases, e.g. [1]. Such tests reveal bugs that would otherwise
go unnoticed, e.g. [2], [3]. We will target correctness, precision,
edge case stressing, error handling and every other requirement of the
IEEE 754 standard we will be confronted with. We can even build a
database of known-good-results from well established CAS's and match
it against the output of our libm.
2. Improvements on existing bits (such as error handling) or
implementation for missing functions.
3. Some sort of documentation of the algorithms nature, efficiency, behavior.
Regarding the politics.
I understand that there is a bias towards 'cool features', which,
besides being practical, they are exploitable in terms of marketing
('NetBSD has ZFS, DTrace, virtualized network stack, etc'). And
marketing we need, absolutely. Also there's a bias towards projects
that have an immediate effect and aren't too much on the experimental
side (see also the recent discussion re. the fuzzer gSoC proposal).
So here's what I think.
If Google decides to sponsor all of our students, fine. No problem.
If Google decides to sponsor less students than we have, then this
project may be managed as a low priority one. Even though I believe it
is as much important as the rest of the things that appear on the
NetBSD's projects page, I wouldn't want my proposal to become the
Apple of Discord and trigger yet another silly never-ending quarrel in
the lists.
So this project either makes it in or not. But in both cases, it will
NOT block _ANY other cool project_ from being sponsored. I hope I
stressed it enough :)
I'd be glad to listen to what you people think.
Best regards,
Stathis Kamperis
P.S. I don't include any stuff regarding myself, since this is an
informal proposal, it's already long and I don't even know if there's
interest on the topic.
____________________
[1]
http://gitweb.dragonflybsd.org/~beket/pcca-tests.git/blob_plain/master:/math.h/t_pow.c
[2] http://mail-index.netbsd.org/source-changes/2009/08/03/msg223605.html
[3] http://sourceware.org/bugzilla/show_bug.cgi?id=10401
Home |
Main Index |
Thread Index |
Old Index