long double (was "strtold?")

[Howland Craig D (Craig)]

@Tim Prince wrote on Tue 3/17/2009 7:31 PM:
>Howland Craig D (Craig) wrote:
>      I have done some looking, and was not finding much; I've found
one
> or two candidates, but not a whole set like I had expected.  (For
> example, FreeBSD has just the easy ones like those I've mentioned.)
> I'll
> do more searching later.  Hopefully people can keep it in mind and
maybe
> we'll stumble across a set that we can import.  I had hoped to find a
> set under OpenSolaris, but they don't appear to have the math library
> visible.
>      I share your concern about checking.  Related to that, I did find
> an arbitrary-precision package that has the transcendentals that could
> be used for checking.
>                 Craig
>   
@How ambitious are you?  Does it need to be as difficult to read as 
@fdlibm?  Both 80-bit and 128-bit IEEE formats?  For x86 80-bit, gcc/387

@in-lines are good enough, although expl() and powl() could use
something 
@a notch better than glibc.  If you're trying to be more general, it's 
@difficult to be efficient as well.  For comparison checks, are you 
@satisfied with gmp/mpfr, or is their use in gcc a disrecommendation?  
@There are test suites, elefunt/celefunt being among the better/longer 
@established.
 
I am very ambitious, but available time does not match what would be
nice to accomplish.  (As evidenced by how long it has taken to reply
to your email.  Sorry for that, but they are good questions and are
worth adequate consideration.)
 
The plan would be to be much more readable than fdlibm--which is not
very hard to accomplish.  (Even their hard-coding of all the bit values
wouldn't be hard to read if there were actually a reasonable amount of
commenting.  Of course, it can stand more improvements than just
comments.)

80 vs. 128 bit is a good question.  I had been thinking that both ought
to be supported since it is unknown what Newlib users have.  (80-bit for
certain, since it is widespread due to Intel.  128 is an interesting
question.  Are there any real systems that actually use it?  I've
personally only seen a library that did it, but it was separate from a
compiler.  General surfing shows enough about it that we likely should
do it from the start.)
 
My initial thinking was that the "easy" ones like round and int get
done for multiple sizes because it is easy to do so.  For the hard ones
like sines and logs, I was hoping that 128 bit versions would work fine
if used with 80 bits, but had not progressed to the point of some
experimentation to see if that is true or not.  (That is, if a sine
algorithm works for 128 bits, truncating the constants used to 80 and
operating with them over the same working ranges ought to work.)  If
this thinking is flawed, let me know.  As you point out, I'd expect
a 128-capable to probably be slower since the argument reduction would
be targeting a narrower range and/or require higher-order polynomials.

Thanks for pointing out elefunt/celefunt, as it gives something
else to look at.  I would think that gmp/mpfr would be OK.  If it
weren't for the GPL, we'd just copy the gcc stuff at face value, so
using the same checks that they do would be no different.  (I actually
lost the URL to the one that I had found because of a power outage,
and haven't gone to find it again, yet.)  What do you think?
 
Regarding efficiency, the first thought is that slow is better than not
having it (which ultimately is infinitely slow).  Speed is something
best put in first if possible, but improvements could be made later.
 
To outline a potential set of goals:
 
1.  Create a complete*, accurate^ long double library that can handle
IEEE754-2008 binary128 and Intel 80-bit formats.  Both numerical
returns and errno error handling per the C99 standard (including Annex
F)
are supported.  POSIX extensions supported with conditional compile
selection.
2.  Code is portable.  (That is, is able to compile and execute properly
on multiple platforms and compilers, as Newlib currently does.)
3.  Allows for the case of long double being the same size as common
double, that is binary64.  (Done by not defining LD functions, but
rather
calling the double functions instead--as the patch that Ken has been
working on does.  A desirable option is to allow direct aliasing when
possible to avoid the overhead of the re-direct function call.)
4.  Code it written to support floating-point exceptions as defined in
the C99 and IEEE754 standards.  (Newlib is mostly ready for this in
the existing routines, so writing the new stuff to allow for it makes
sense.)
5.  Code is maintainable, having sufficient comments and following
good programming practices.  (So that the diverse set of Newlib
providers
can provide maintenance or porting without undue effort if the original
author is not available.)
6.  Code is small.
7.  Code is fast.  Secondary goal:  if there is a size/speed tradeoff,
supply both, allowing user to choose with conditional compilation flag.
8.  Optionally support other IEEE754-2008-compliant encodings that are
longer than 80 bits.  (64 and shorter not supported, because that is
<=double and would map to the present double or float routines.)
 
Caveats:
A)  Routines not meeting accuracy, and/or error-reporting requirements
accepted as long as the shortcomings are clearly documented in both
source
comments and man pages.  (Allows the user to choose to use or not.
Identifies clearly for later cleanup.)
B)  Routines not meeting portability requirements can be accepted, but
need to be placed in machine directory and with clear documentation of
limitations in man pages.
C)  The C99 standard requires floating-point exception generation when
IEC 60559 (sort of a predecessor to IEEE754-2008) numbers are used (in
Appendix F).  These goals violate that by placing the FP exceptions
in #4, which is marked optional, primarily because the rest of the
Newlib math library is not compliant.  (Most of it is, but not all.)
 
* "Complete" means the function set defined by the C99 standard.
^ Accuracy is within TBD ULP.  (Is there a standard to point to?  I saw
something recently, but forget where.  It was something like .9ulp.)

These are roughly in order of importance.  As you point out, however,
speed, size, and support of multiple encoding lengths might at times be
at
odds with each other, so achieving all in every function will be
impossible.  This is the reason for breaking them into ordered steps, to
establish priorities.
 
From a realistic point of view, (ambitious, but realizing that we don't
have infinite time available), numbers 1-3 are requirements.  The
remainder are objectives of decreasing importance.  (While it sure
would be great to have easy-to-read code, for example, it's better to
have a hard-to-read-but-works-well routine (like much of the fdlibm
stuff) than to not have that routine at all.)
 
Some more items would need to be added for a working specification,
such as a little more specificity as to what "portable" means.  (Things
'like <float.h> is present, but <fenv.h> is not guaranteed to be
(although it would be later when floating-point exceptions were
"enabled");
long long is available', etc.)
 
Potential discussion points:
Is this requirement/goal list complete?
It the list too much?
  Does it make any sense to attempt binary128?  (Should I make up a
quick
  survey to send out to attempt to determine what people are using or
  might be shortly, or does it make sense just to start with it since
  it will come some day?  etc.)
Are they in the right order?
  Should size be ranked above speed?  I put them in that order because
  Newlib is meant to be more lean, for embedded systems where size can
  be more important.
Do people prefer errno error handling, or floating-point exception error
handling?  (i.e. (math_errhandling & MATH_ERRNO != 0) or
(math_errhandling & MATH_ERREXCEPT != 0)?)
Does anybody care about the non-standard fdlibm error handling stuff?
I'd like to ditch it and use one (or both) of the two standard methods
(for the new long double stuff, that is--existing stuff kept as-is).
etc.
 
I apologize for this being so long, but it makes sense to plan
carefully before starting, as Tim's questions demonstrate.
 
Craig