Use of C99 extra long double math functions after r236148

classic Classic list List threaded Threaded
100 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Use of C99 extra long double math functions after r236148

Rainer Hurling
Yesterday r236148 (Allow inclusion of libc++ <cmath> to work after
including math.h) was comitted to head, many thanks.

Does this mean, that extra long double functions like acoshl, expm1l or
log1pl are now "really implemented"? As far as I understand, they had
only been declared before?

If this is right, are they usable on a recent CURRENT, built with gcc42
(system compiler), by ports which use gcc46 (not clang)? If not, are
there any plans to implement these functions in the near future?

The use of C99 extra long double functions would be of interest for
example for programs like math/R, especially its upcoming releases.

Many thanks for any clarification.

Regards,
Rainer Hurling
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

David Chisnall-2
On 28 May 2012, at 05:35, Rainer Hurling wrote:

> Yesterday r236148 (Allow inclusion of libc++ <cmath> to work after including math.h) was comitted to head, many thanks.
>
> Does this mean, that extra long double functions like acoshl, expm1l or log1pl are now "really implemented"? As far as I understand, they had only been declared before?

They are still not implemented.  The <cmath> header in libc++ provides wrappers around these functions for C++, but if they are not declared then the compiler throws an error.  Now there is a linker error if they are used, but if they are not used then it works irrespective of whether you just include <cmath> or do undefined things like include <math.h> first.

> If this is right, are they usable on a recent CURRENT, built with gcc42 (system compiler), by ports which use gcc46 (not clang)? If not, are there any plans to implement these functions in the near future?

I think they're one of the last bits of C99 / C11 that anyone actually cares about (C11 unicode support being another), so they'll probably get done at some point, but doing them correctly is nontrivial, except on platforms where double and long double are the same.  

> The use of C99 extra long double functions would be of interest for example for programs like math/R, especially its upcoming releases.

I would be very wary of anything that depends on long double.  The C spec makes no constraints on the range of float, double, or long double, but by convention on most platforms float is an IEEE 754 32-bit floating point value and double is 64-bit.  No such conventions apply to long doubles and I know of (widely deployed) platforms where they are 64 bits, 80 bits and 128 bits, respectively.  I believe on PowerPC FreeBSD actually gets it wrong and uses 64 bits even though the platform ABI spec recommends using 128 bits.  x86 uses 80-bit x87 values (although sizeof(long double) may be 16 because they have some padding bytes in memory).  If your program is tolerant of a potential variation in precision between 64 bits and 128 bits, then it is probably tolerant of just using doubles.

David_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

Rainer Hurling
On 28.05.2012 10:41 (UTC+1), David Chisnall wrote:
> On 28 May 2012, at 05:35, Rainer Hurling wrote:

First I should note that I am by no means an expert in C / C++ or C99
standards. So my comments are only on a level of someone who is using
FreeBSD for scientific purposes like GIS and math applications and who
is the maintainer of some scientific ports (like math/saga).

>> Yesterday r236148 (Allow inclusion of libc++<cmath>  to work after including math.h) was comitted to head, many thanks.
>>
>> Does this mean, that extra long double functions like acoshl, expm1l or log1pl are now "really implemented"? As far as I understand, they had only been declared before?
>
> They are still not implemented.  The<cmath>  header in libc++ provides wrappers around these functions for C++, but if they are not declared then the compiler throws an error.  Now there is a linker error if they are used, but if they are not used then it works irrespective of whether you just include<cmath>  or do undefined things like include<math.h>  first.

Ok, that's what I had supposed. Because the main difference between
r236147 and r2136148 seems to be the define of _MATH_EXTRA_H_, the rest
is more a type of binning?

>> If this is right, are they usable on a recent CURRENT, built with gcc42 (system compiler), by ports which use gcc46 (not clang)? If not, are there any plans to implement these functions in the near future?
>
> I think they're one of the last bits of C99 / C11 that anyone actually cares about (C11 unicode support being another), so they'll probably get done at some point, but doing them correctly is nontrivial, except on platforms where double and long double are the same.

Yes, I agree. These outstanding long double math functions (like log1pl)
and better unicode support are really needed for some important third
party projects like R or SAGA GIS.

In the past I have read several times discussions about the correctness
of long double functions on FreeBSD. Some drafts have been dismissed
because of there inaccuracy in special cases. Also was discussed to get
missing libm routines from NetBSD [1]. It appears as if we have to wait
some more time ...

>> The use of C99 extra long double functions would be of interest for example for programs like math/R, especially its upcoming releases.
>
> I would be very wary of anything that depends on long double.  The C spec makes no constraints on the range of float, double, or long double, but by convention on most platforms float is an IEEE 754 32-bit floating point value and double is 64-bit.  No such conventions apply to long doubles and I know of (widely deployed) platforms where they are 64 bits, 80 bits and 128 bits, respectively.  I believe on PowerPC FreeBSD actually gets it wrong and uses 64 bits even though the platform ABI spec recommends using 128 bits.  x86 uses 80-bit x87 values (although sizeof(long double) may be 16 because they have some padding bytes in memory).  If your program is tolerant of a potential variation in precision between 64 bits and 128 bits, then it is probably tolerant of just using doubles.

Yes, I think in most cases math/R is tolerant enough of just using
doubles. But in the near future they plan to implement much more of the
C99 stuff and their tolerance to offer workarounds for FreeBSD shrinks
from release to release [2]. So these problems will increase :-(

Many thanks for your fast und well explained answer, I really appreciate it.

Rainer

> David


[1]
http://lists.freebsd.org/pipermail/freebsd-standards/2011-February/002119.html

[2] https://stat.ethz.ch/pipermail/r-devel/2012-May/064128.html

And some more places I found interesting about C99 and FreeBSD

[3] http://www.freebsd.org/projects/c99/index.html

[4] http://wiki.freebsd.org/MissingMathStuff

[5] http://marc.info/?l=freebsd-standards&m=123158761305427

[6]
http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/028030.html

[7]
http://www.koders.com/c/fid164FD2F50C9AAA63119A641875824455B3AE6B55.aspx?s=log1pl.c

[8] http://www.mail-archive.com/bug-gnulib@.../msg26571.html

[9] http://leaf.dragonflybsd.org/mailarchive/commits/2011-12/msg00190.html
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

David Chisnall-2
On 28 May 2012, at 13:30, Rainer Hurling wrote:

> On 28.05.2012 10:41 (UTC+1), David Chisnall wrote:
>> On 28 May 2012, at 05:35, Rainer Hurling wrote:
>
> Ok, that's what I had supposed. Because the main difference between r236147 and r2136148 seems to be the define of _MATH_EXTRA_H_, the rest is more a type of binning?

Yes, it's just about making libc++'s cmath header compile, nothing more.  

> Yes, I agree. These outstanding long double math functions (like log1pl) and better unicode support are really needed for some important third party projects like R or SAGA GIS.

I very much doubt that anything is using the C11 unicode stuff yet, since no compiler or libc currently supports it...

> In the past I have read several times discussions about the correctness of long double functions on FreeBSD. Some drafts have been dismissed because of there inaccuracy in special cases. Also was discussed to get missing libm routines from NetBSD [1]. It appears as if we have to wait some more time ...

I thought we did pull in some NetBSD libm stuff recently.  Not sure what the status of that is, you'd need to check with das@.

> Yes, I think in most cases math/R is tolerant enough of just using doubles. But in the near future they plan to implement much more of the C99 stuff and their tolerance to offer workarounds for FreeBSD shrinks from release to release [2]. So these problems will increase :-(

Reading that email, it seems that they would prefer a function that exists and returns the wrong result to one that does not exist.  If this is really the attitude of the developers of R, then I shall make absolutely certain that I avoid using R for anything where I actually care about the results, and would strongly encourage everyone else to do the same.  

In general, (sane) people use the long double versions because they need the extra precision and care about the result.  We could easily implement the long double versions now as toy versions that just called the double versions, but that would upset a lot of people who actually care about accuracy, who are the main target audience for these functions.  

David_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

Rainer Hurling
On 28.05.2012 14:49 (UTC+1), David Chisnall wrote:
> On 28 May 2012, at 13:30, Rainer Hurling wrote:
>
>> On 28.05.2012 10:41 (UTC+1), David Chisnall wrote:
>>> On 28 May 2012, at 05:35, Rainer Hurling wrote:
>>
>> Ok, that's what I had supposed. Because the main difference between r236147 and r2136148 seems to be the define of _MATH_EXTRA_H_, the rest is more a type of binning?
>
> Yes, it's just about making libc++'s cmath header compile, nothing more.

I see, thanks.

>> Yes, I agree. These outstanding long double math functions (like log1pl) and better unicode support are really needed for some important third party projects like R or SAGA GIS.
>
> I very much doubt that anything is using the C11 unicode stuff yet, since no compiler or libc currently supports it...

Of course you are right with C11 unicode stuff.

I thougt more about my actual problems to get the right charset
conversions between different apps, i.e. qgis <-> wxgtk29 <-> saga gis.
Or using Gnome apps (utf8) on windowmaker using ISO8859-15. But this is
OT here, sorry.

>> In the past I have read several times discussions about the correctness of long double functions on FreeBSD. Some drafts have been dismissed because of there inaccuracy in special cases. Also was discussed to get missing libm routines from NetBSD [1]. It appears as if we have to wait some more time ...
>
> I thought we did pull in some NetBSD libm stuff recently.  Not sure what the status of that is, you'd need to check with das@.

I am not aware of it and will have a look. But this did not implement
the missing long double functions.

>> Yes, I think in most cases math/R is tolerant enough of just using doubles. But in the near future they plan to implement much more of the C99 stuff and their tolerance to offer workarounds for FreeBSD shrinks from release to release [2]. So these problems will increase :-(
>
> Reading that email, it seems that they would prefer a function that exists and returns the wrong result to one that does not exist.  If this is really the attitude of the developers of R, then I shall make absolutely certain that I avoid using R for anything where I actually care about the results, and would strongly encourage everyone else to do the same.

This was a statement of just one (though not unimportant) person from
the R Core team. I don't think that this is the only view of R Core
developers. On the other hand he is the person, who actually did most of
the stuff within R for years now to circumvent the problems running on
FreeBSD.

> In general, (sane) people use the long double versions because they need the extra precision and care about the result.  We could easily implement the long double versions now as toy versions that just called the double versions, but that would upset a lot of people who actually care about accuracy, who are the main target audience for these functions.

It seems to be a general trend (outside of FreeBSD) to implement more
and more stuff at the cost of quality. I am certain that for many
FreeBSD users accuracy is more important than completeness, especially
for scientists.

Nevertheless this policy brings some problems in the real world ;-)

Thanks again for your thoughts,
Rainer

> David
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

Montgomery-Smith, Stephen
One thing that could be done is to have a "math/cephes" port that adds
the extra C99 math functions.  This is already done in the math/sage
port, using a rather clever patch due to Peter Jeremy, that applies to
the cephes code.

What it would do is to create a /usr/local/lib/libm.so that would
provide the extra functions not currently included in /lib/libm.so, and
then link in /lib/libm.so as well.  It would also create its own
/usr/local/include/math.h and /usr/local/include/complex.h as well.

What do you guys think?  Do you want someone to start experimenting with
this idea?  I could do it, but probably not for a little while.

Stephen

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

Steve Kargl
On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:

> One thing that could be done is to have a "math/cephes" port that adds
> the extra C99 math functions.  This is already done in the math/sage
> port, using a rather clever patch due to Peter Jeremy, that applies to
> the cephes code.
>
> What it would do is to create a /usr/local/lib/libm.so that would
> provide the extra functions not currently included in /lib/libm.so, and
> then link in /lib/libm.so as well.  It would also create its own
> /usr/local/include/math.h and /usr/local/include/complex.h as well.
>
> What do you guys think?  Do you want someone to start experimenting with
> this idea?  I could do it, but probably not for a little while.
>

This is a horrible, horrible, horrible idea.  Have you
looked at the cephes code, particularly the complex.h
functions?

--
Steve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

Peter Jeremy-8
In reply to this post by Montgomery-Smith, Stephen
On 2012-May-28 11:01:24 -0500, Stephen Montgomery-Smith <[hidden email]> wrote:
>One thing that could be done is to have a "math/cephes" port that adds
>the extra C99 math functions.  This is already done in the math/sage
>port, using a rather clever patch due to Peter Jeremy, that applies to
>the cephes code.
>
>What it would do is to create a /usr/local/lib/libm.so that would
>provide the extra functions not currently included in /lib/libm.so, and
>then link in /lib/libm.so as well.  It would also create its own
>/usr/local/include/math.h and /usr/local/include/complex.h as well.

Basically, as long as the compiler searches /usr/local/{include,lib}
before the base include/lib then <math.h>, <complex.h> and -lm give
the application a complete C99 math implementation by using base
functions where they exist and cephes functions where they don't.

The patch I wrote for sage can be found at
http://trac.sagemath.org/sage_trac/ticket/9543
If there's any interest, I could produce a port for this.

Another option would be to import cephes into base and use it to
provide the missing C99 functions.  Cephes includes copyright notices
but the closest I can find to a license is:
"   Some software in this archive may be from the book _Methods and
 Programs for Mathematical Functions_ (Prentice-Hall or Simon & Schuster
 International, 1989) or from the Cephes Mathematical Library, a
 commercial product. In either event, it is copyrighted by the author.
 What you see here may be used freely but it comes with no support or
 guarantee."

--
Peter Jeremy

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

Montgomery-Smith, Stephen
In reply to this post by Steve Kargl
On 05/28/2012 03:31 PM, Steve Kargl wrote:

> On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
>> One thing that could be done is to have a "math/cephes" port that adds
>> the extra C99 math functions.  This is already done in the math/sage
>> port, using a rather clever patch due to Peter Jeremy, that applies to
>> the cephes code.
>>
>> What it would do is to create a /usr/local/lib/libm.so that would
>> provide the extra functions not currently included in /lib/libm.so, and
>> then link in /lib/libm.so as well.  It would also create its own
>> /usr/local/include/math.h and /usr/local/include/complex.h as well.
>>
>> What do you guys think?  Do you want someone to start experimenting with
>> this idea?  I could do it, but probably not for a little while.
>>
>
> This is a horrible, horrible, horrible idea.  Have you
> looked at the cephes code, particularly the complex.h
> functions?

I have only taken a very cursory look.  What should I specifically look
for in seeing that the code is bad?

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

Peter Jeremy-8
In reply to this post by Steve Kargl
On 2012-May-28 13:31:59 -0700, Steve Kargl <[hidden email]> wrote:
>On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
>> One thing that could be done is to have a "math/cephes" port that adds
>> the extra C99 math functions.  This is already done in the math/sage
>> port, using a rather clever patch due to Peter Jeremy, that applies to
>> the cephes code.
...
>This is a horrible, horrible, horrible idea.  Have you
>looked at the cephes code, particularly the complex.h
>functions?

The cephes code is somewhat a mess layout-wise.  Algorithmetically,
it seems somewhat variable - some functions are implemented (hopefully
correctly) using semi-numerical techniques, whereas others just use
mathematical identities which will result in precision loss - though
most of the functions include accuracy information.

I agree it would be far preferable to have a properly validated C99
libm with all functions having maximum errors of a no more than a few
LSB over their complete domain, as well as correct support for signed
zeroes, infinities and signalling and non-signalling NaNs but that is
a non-trivial undertaking.

In the interim, how should FreeBSD handle apps that want a C99 libm?
1) Fail to build them
2) Provide possibly imperfect fallbacks for the unimplemented bits.

If someone (I don't have the expertise) wants to identify the cephes
functions that are sub-standard, we can include link-time warnings
(as done for eg gets(3)) when they are used.

--
Peter Jeremy

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

Steve Kargl
In reply to this post by Montgomery-Smith, Stephen
On Mon, May 28, 2012 at 04:19:22PM -0500, Stephen Montgomery-Smith wrote:

> On 05/28/2012 03:31 PM, Steve Kargl wrote:
> >On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
> >>One thing that could be done is to have a "math/cephes" port that adds
> >>the extra C99 math functions.  This is already done in the math/sage
> >>port, using a rather clever patch due to Peter Jeremy, that applies to
> >>the cephes code.
> >>
> >>What it would do is to create a /usr/local/lib/libm.so that would
> >>provide the extra functions not currently included in /lib/libm.so, and
> >>then link in /lib/libm.so as well.  It would also create its own
> >>/usr/local/include/math.h and /usr/local/include/complex.h as well.
> >>
> >>What do you guys think?  Do you want someone to start experimenting with
> >>this idea?  I could do it, but probably not for a little while.
> >>
> >
> >This is a horrible, horrible, horrible idea.  Have you
> >looked at the cephes code, particularly the complex.h
> >functions?
>
> I have only taken a very cursory look.  What should I specifically look
> for in seeing that the code is bad?

Well, to start with, the extra C99 math functions that
are missing in libm include a few for the long double type
and many (if not most) of the complex functions for any
type.  Cephes at best will give you float, double, and ld80, but
not ld128 versions of the functions.  Then, there is fun little fact
that neither (base) gcc nor clang nor gcc less than 4.6 does
complex arithematic correctly; so, one needs to jump through
hoops to get the correct answer (See Annex G in n1256.pdf).
One item of particular importance in Annex G is the behavior
of the functions for Re(z) and/or Im(z) being +-0, +-Inf, and
NaN.

--
Steve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

Steve Kargl
In reply to this post by Peter Jeremy-8
On Tue, May 29, 2012 at 08:04:36AM +1000, Peter Jeremy wrote:

> On 2012-May-28 13:31:59 -0700, Steve Kargl <[hidden email]> wrote:
> >On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
> >> One thing that could be done is to have a "math/cephes" port that adds
> >> the extra C99 math functions.  This is already done in the math/sage
> >> port, using a rather clever patch due to Peter Jeremy, that applies to
> >> the cephes code.
> ...
> >This is a horrible, horrible, horrible idea.  Have you
> >looked at the cephes code, particularly the complex.h
> >functions?
>
> The cephes code is somewhat a mess layout-wise.  Algorithmetically,
> it seems somewhat variable - some functions are implemented (hopefully
> correctly) using semi-numerical techniques, whereas others just use
> mathematical identities which will result in precision loss - though
> most of the functions include accuracy information.
>
> I agree it would be far preferable to have a properly validated C99
> libm with all functions having maximum errors of a no more than a few
> LSB over their complete domain, as well as correct support for signed
> zeroes, infinities and signalling and non-signalling NaNs but that is
> a non-trivial undertaking.
>
> In the interim, how should FreeBSD handle apps that want a C99 libm?
> 1) Fail to build them
> 2) Provide possibly imperfect fallbacks for the unimplemented bits.
>
> If someone (I don't have the expertise) wants to identify the cephes
> functions that are sub-standard, we can include link-time warnings
> (as done for eg gets(3)) when they are used.

Given that cephes was written years before C99 was even
conceived, I suspect all functions are sub-standard.  For
example, AFAIK, none of the long double functions are
appropriate for any platform that has an 128-bit long double;
as cephes was written for an Intel 80-bit format.

If portmgr or a port maintainer wants to use a library with
untested implementations of missing libm functions, please do
not put it into /usr/local/lib and call it libm.

--
Steve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

Steve Kargl
In reply to this post by Peter Jeremy-8
On Tue, May 29, 2012 at 07:05:07AM +1000, Peter Jeremy wrote:

> On 2012-May-28 11:01:24 -0500, Stephen Montgomery-Smith <[hidden email]> wrote:
> >One thing that could be done is to have a "math/cephes" port that adds
> >the extra C99 math functions.  This is already done in the math/sage
> >port, using a rather clever patch due to Peter Jeremy, that applies to
> >the cephes code.
> >
> >What it would do is to create a /usr/local/lib/libm.so that would
> >provide the extra functions not currently included in /lib/libm.so, and
> >then link in /lib/libm.so as well.  It would also create its own
> >/usr/local/include/math.h and /usr/local/include/complex.h as well.
>
> Basically, as long as the compiler searches /usr/local/{include,lib}
> before the base include/lib then <math.h>, <complex.h> and -lm give
> the application a complete C99 math implementation by using base
> functions where they exist and cephes functions where they don't.
>
> The patch I wrote for sage can be found at
> http://trac.sagemath.org/sage_trac/ticket/9543
> If there's any interest, I could produce a port for this.
>
> Another option would be to import cephes into base and use it to
> provide the missing C99 functions.  Cephes includes copyright notices
> but the closest I can find to a license is:
> "   Some software in this archive may be from the book _Methods and
>  Programs for Mathematical Functions_ (Prentice-Hall or Simon & Schuster
>  International, 1989) or from the Cephes Mathematical Library, a
>  commercial product. In either event, it is copyrighted by the author.
>  What you see here may be used freely but it comes with no support or
>  guarantee."

Please talk to das@ (although I believe he's finishing up his
dissertation).  I recall that he's stated that he looked into
using cephes, and concluded that it is not suitable for libm.

Note there is also

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147599

which I've also objected to importing into libm.

--
Steve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

Montgomery-Smith, Stephen
In reply to this post by Steve Kargl
On 05/28/2012 05:17 PM, Steve Kargl wrote:

> On Mon, May 28, 2012 at 04:19:22PM -0500, Stephen Montgomery-Smith wrote:
>> On 05/28/2012 03:31 PM, Steve Kargl wrote:
>>> On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
>>>> One thing that could be done is to have a "math/cephes" port that adds
>>>> the extra C99 math functions.  This is already done in the math/sage
>>>> port, using a rather clever patch due to Peter Jeremy, that applies to
>>>> the cephes code.
>>>>
>>>> What it would do is to create a /usr/local/lib/libm.so that would
>>>> provide the extra functions not currently included in /lib/libm.so, and
>>>> then link in /lib/libm.so as well.  It would also create its own
>>>> /usr/local/include/math.h and /usr/local/include/complex.h as well.
>>>>
>>>> What do you guys think?  Do you want someone to start experimenting with
>>>> this idea?  I could do it, but probably not for a little while.
>>>>
>>>
>>> This is a horrible, horrible, horrible idea.  Have you
>>> looked at the cephes code, particularly the complex.h
>>> functions?
>>
>> I have only taken a very cursory look.  What should I specifically look
>> for in seeing that the code is bad?
>
> Well, to start with, the extra C99 math functions that
> are missing in libm include a few for the long double type
> and many (if not most) of the complex functions for any
> type.  Cephes at best will give you float, double, and ld80, but
> not ld128 versions of the functions.  Then, there is fun little fact
> that neither (base) gcc nor clang nor gcc less than 4.6 does
> complex arithematic correctly; so, one needs to jump through
> hoops to get the correct answer (See Annex G in n1256.pdf).
> One item of particular importance in Annex G is the behavior
> of the functions for Re(z) and/or Im(z) being +-0, +-Inf, and
> NaN.
>

IMHO these problems are definitely not bad enough to avoid making a
math/cephes port.  I for one would definitely like to have some kind of
implementation of ccosh, even if it gets a few things wrong when it is
fed Nan or I*Inf or such like as its input.  I mean, if clang or gcc46
doesn't even get this right, how can we expect better from libm?

Also, a really nice thing about Jeremy's patch is that it automatically
detects which functions are already included in the base libm, and only
adds functions not already in libm.

And ld80 is better than nothing if ld128 isn't available.

I would avoid cephes only if it got some of the answers horribly wrong
(as in erf(100) being something like -14232 as the openoffice
implementation of the erf function used to report).

I say, lets go ahead and add a math/cephes port.

By the way, do you have an opinion on the complex functions used in
Linux?  (I tried reading the glibc code, but I could only find chains of
macros and functions calling each other, and I could never find where
the actual work was performed.)

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

Steve Kargl
On Mon, May 28, 2012 at 06:03:37PM -0500, Stephen Montgomery-Smith wrote:

> On 05/28/2012 05:17 PM, Steve Kargl wrote:
> >On Mon, May 28, 2012 at 04:19:22PM -0500, Stephen Montgomery-Smith wrote:
> >>On 05/28/2012 03:31 PM, Steve Kargl wrote:
> >>>On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
> >>>>One thing that could be done is to have a "math/cephes" port that adds
> >>>>the extra C99 math functions.  This is already done in the math/sage
> >>>>port, using a rather clever patch due to Peter Jeremy, that applies to
> >>>>the cephes code.
> >>>>
> >>>>What it would do is to create a /usr/local/lib/libm.so that would
> >>>>provide the extra functions not currently included in /lib/libm.so, and
> >>>>then link in /lib/libm.so as well.  It would also create its own
> >>>>/usr/local/include/math.h and /usr/local/include/complex.h as well.
> >>>>
> >>>>What do you guys think?  Do you want someone to start experimenting with
> >>>>this idea?  I could do it, but probably not for a little while.
> >>>>
> >>>
> >>>This is a horrible, horrible, horrible idea.  Have you
> >>>looked at the cephes code, particularly the complex.h
> >>>functions?
> >>
> >>I have only taken a very cursory look.  What should I specifically look
> >>for in seeing that the code is bad?
> >
> >Well, to start with, the extra C99 math functions that
> >are missing in libm include a few for the long double type
> >and many (if not most) of the complex functions for any
> >type.  Cephes at best will give you float, double, and ld80, but
> >not ld128 versions of the functions.  Then, there is fun little fact
> >that neither (base) gcc nor clang nor gcc less than 4.6 does
> >complex arithematic correctly; so, one needs to jump through
> >hoops to get the correct answer (See Annex G in n1256.pdf).
> >One item of particular importance in Annex G is the behavior
> >of the functions for Re(z) and/or Im(z) being +-0, +-Inf, and
> >NaN.
> >
>
> IMHO these problems are definitely not bad enough to avoid making a
> math/cephes port.  I for one would definitely like to have some kind of
> implementation of ccosh, even if it gets a few things wrong when it is
> fed Nan or I*Inf or such like as its input.  I mean, if clang or gcc46
> doesn't even get this right, how can we expect better from libm?

Search the llvm and gcc bug databases, I'm the person that informed
both that they can't deal with complex arithematic correctly.

Interesting that you mention ccosh.

>From clog.c in http://www.netlib.org/cephes/cmath.tgz

void
ccosh (z, w)
     cmplx *z, *w;
{
  double x, y;
  x = z->r;
  y = z->i;
  w->r = cosh (x) * cos (y);
  w->i = sinh (x) * sin (y);
}

>From clog.c in http://www.netlib.org/cephes/c9x-complex

double complex
ccosh (z)
     double complex z;
{
  double complex w;
  double x, y;

  x = creal(z);
  y = cimag(z);
  w = cosh (x) * cos (y)  +  (sinh (x) * sin (y)) * I;
  return (w);
}

See math_private.h about the above.

And, finally,

:
/*-
 * Copyright (c) 2005 Bruce D. Evans and Steven G. Kargl
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice unmodified, this list of conditions, and the following
 *    disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
 * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
 * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
 * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
 * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
 * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

/*
 * Hyperbolic cosine of a complex argument z = x + i y.
 *
 * cosh(z) = cosh(x+iy)
 *         = cosh(x) cos(y) + i sinh(x) sin(y).
 *
 * Exceptional values are noted in the comments within the source code.
 * These values and the return value were taken from n1124.pdf.
 */

#include <sys/cdefs.h>
__FBSDID("$FreeBSD: head/lib/msun/src/s_ccosh.c 226599 2011-10-21 06:29:32Z das $");

#include <complex.h>
#include <math.h>

#include "math_private.h"

static const double huge = 0x1p1023;

double complex
ccosh(double complex z)
{
        double x, y, h;
        int32_t hx, hy, ix, iy, lx, ly;

        x = creal(z);
        y = cimag(z);

        EXTRACT_WORDS(hx, lx, x);
        EXTRACT_WORDS(hy, ly, y);

        ix = 0x7fffffff & hx;
        iy = 0x7fffffff & hy;

        /* Handle the nearly-non-exceptional cases where x and y are finite. */
        if (ix < 0x7ff00000 && iy < 0x7ff00000) {
                if ((iy | ly) == 0)
                        return (cpack(cosh(x), x * y));
                if (ix < 0x40360000) /* small x: normal case */
                        return (cpack(cosh(x) * cos(y), sinh(x) * sin(y)));

                /* |x| >= 22, so cosh(x) ~= exp(|x|) */
                if (ix < 0x40862e42) {
                        /* x < 710: exp(|x|) won't overflow */
                        h = exp(fabs(x)) * 0.5;
                        return (cpack(h * cos(y), copysign(h, x) * sin(y)));
                } else if (ix < 0x4096bbaa) {
                        /* x < 1455: scale to avoid overflow */
                        z = __ldexp_cexp(cpack(fabs(x), y), -1);
                        return (cpack(creal(z), cimag(z) * copysign(1, x)));
                } else {
                        /* x >= 1455: the result always overflows */
                        h = huge * x;
                        return (cpack(h * h * cos(y), h * sin(y)));
                }
        }

        /*
         * cosh(+-0 +- I Inf) = dNaN + I sign(d(+-0, dNaN))0.
         * The sign of 0 in the result is unspecified.  Choice = normally
         * the same as dNaN.  Raise the invalid floating-point exception.
         *
         * cosh(+-0 +- I NaN) = d(NaN) + I sign(d(+-0, NaN))0.
         * The sign of 0 in the result is unspecified.  Choice = normally
         * the same as d(NaN).
         */
        if ((ix | lx) == 0 && iy >= 0x7ff00000)
                return (cpack(y - y, copysign(0, x * (y - y))));

        /*
         * cosh(+-Inf +- I 0) = +Inf + I (+-)(+-)0.
         *
         * cosh(NaN +- I 0)   = d(NaN) + I sign(d(NaN, +-0))0.
         * The sign of 0 in the result is unspecified.
         */
        if ((iy | ly) == 0 && ix >= 0x7ff00000) {
                if (((hx & 0xfffff) | lx) == 0)
                        return (cpack(x * x, copysign(0, x) * y));
                return (cpack(x * x, copysign(0, (x + x) * y)));
        }

        /*
         * cosh(x +- I Inf) = dNaN + I dNaN.
         * Raise the invalid floating-point exception for finite nonzero x.
         *
         * cosh(x + I NaN) = d(NaN) + I d(NaN).
         * Optionally raises the invalid floating-point exception for finite
         * nonzero x.  Choice = don't raise (except for signaling NaNs).
         */
        if (ix < 0x7ff00000 && iy >= 0x7ff00000)
                return (cpack(y - y, x * (y - y)));

        /*
         * cosh(+-Inf + I NaN)  = +Inf + I d(NaN).
         *
         * cosh(+-Inf +- I Inf) = +Inf + I dNaN.
         * The sign of Inf in the result is unspecified.  Choice = always +.
         * Raise the invalid floating-point exception.
         *
         * cosh(+-Inf + I y)   = +Inf cos(y) +- I Inf sin(y)
         */
        if (ix >= 0x7ff00000 && ((hx & 0xfffff) | lx) == 0) {
                if (iy >= 0x7ff00000)
                        return (cpack(x * x, x * (y - y)));
                return (cpack((x * x) * cos(y), x * sin(y)));
        }

        /*
         * cosh(NaN + I NaN)  = d(NaN) + I d(NaN).
         *
         * cosh(NaN +- I Inf) = d(NaN) + I d(NaN).
         * Optionally raises the invalid floating-point exception.
         * Choice = raise.
         *
         * cosh(NaN + I y)    = d(NaN) + I d(NaN).
         * Optionally raises the invalid floating-point exception for finite
         * nonzero y.  Choice = don't raise (except for signaling NaNs).
         */
        return (cpack((x * x) * (y - y), (x + x) * (y - y)));
}

And, one gets ccos for free.

double complex
ccos(double complex z)
{

        /* ccos(z) = ccosh(I * z) */
        return (ccosh(cpack(-cimag(z), creal(z))));
}

> Also, a really nice thing about Jeremy's patch is that it automatically
> detects which functions are already included in the base libm, and only
> adds functions not already in libm.
>
> And ld80 is better than nothing if ld128 isn't available.
>
> I would avoid cephes only if it got some of the answers horribly wrong
> (as in erf(100) being something like -14232 as the openoffice
> implementation of the erf function used to report).

Who's writing the code to test the implementations?  That is
better much the problem.  Without testing, one might get an
implementation that appears to work until it doesn't!  It took
me 3+ years to get sqrtl() into libm, but bde and das (and
myself) wanted to make sure the code worked.  

> By the way, do you have an opinion on the complex functions used in
> Linux?  (I tried reading the glibc code, but I could only find chains of
> macros and functions calling each other, and I could never find where
> the actual work was performed.)

I haven't looked at glibc code in years, because I hack on libm
when I can.  I do not want to run into questions about whether
my code is tainted by the gpl.

--
Steve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

Montgomery-Smith, Stephen
On 05/28/2012 06:30 PM, Steve Kargl wrote:

>
>> From clog.c in http://www.netlib.org/cephes/c9x-complex
>
> double complex
> ccosh (z)
>       double complex z;
> {
>    double complex w;
>    double x, y;
>
>    x = creal(z);
>    y = cimag(z);
>    w = cosh (x) * cos (y)  +  (sinh (x) * sin (y)) * I;
>    return (w);
> }
>
> See math_private.h about the above.
>

I looked in math_private.h - I presume you meant
lib/msun/src/math_private.h.  I wasn't able to find anything about ccosh
there.

I think that for a rough and ready ccosh, this is high enough quality
for a math/cephes port.

I do agree that it might not be high enough quality to make FreeBSD base.

(Although I don't think I have ever been in a situation where I would
have been tripped up by a transcendental function that responded
incorrectly to exceptional input.)



> And, finally,

Yes, it is very nice.

>
> Who's writing the code to test the implementations?  That is
> better much the problem.  Without testing, one might get an
> implementation that appears to work until it doesn't!  It took
> me 3+ years to get sqrtl() into libm, but bde and das (and
> myself) wanted to make sure the code worked.

Fair enough if we are talking about the base system.

> I haven't looked at glibc code in years, because I hack on libm
> when I can.  I do not want to run into questions about whether
> my code is tainted by the gpl.
>

They had similar lists of exceptions.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

Steve Kargl
On Mon, May 28, 2012 at 06:44:42PM -0500, Stephen Montgomery-Smith wrote:

> On 05/28/2012 06:30 PM, Steve Kargl wrote:
>
> >
> >>From clog.c in http://www.netlib.org/cephes/c9x-complex
> >
> >double complex
> >ccosh (z)
> >      double complex z;
> >{
> >   double complex w;
> >   double x, y;
> >
> >   x = creal(z);
> >   y = cimag(z);
> >   w = cosh (x) * cos (y)  +  (sinh (x) * sin (y)) * I;
> >   return (w);
> >}
> >
> >See math_private.h about the above.
> >
>
> I looked in math_private.h - I presume you meant
> lib/msun/src/math_private.h.  I wasn't able to find anything about ccosh
> there.
>
> I think that for a rough and ready ccosh, this is high enough quality
> for a math/cephes port.

That's the problem.  It is not acceptable (imo).  The comment in
math_private.h that is relevant is

/*
 * Inline functions that can be used to construct complex values.
 *
 * The C99 standard intends x+I*y to be used for this, but x+I*y is
 * currently unusable in general since gcc introduces many overflow,
 * underflow, sign and efficiency bugs by rewriting I*y as
 * (0.0+I)*(y+0.0*I) and laboriously computing the full complex product.
 * In particular, I*Inf is corrupted to NaN+I*Inf, and I*-0 is corrupted
 * to -0.0+I*0.0.
 */

Those wrong +-0 mean you may up end up on the worng riemann sheet,
and that NaN propagates.

--
Steve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

Montgomery-Smith, Stephen
On 05/28/2012 07:07 PM, Steve Kargl wrote:

> On Mon, May 28, 2012 at 06:44:42PM -0500, Stephen Montgomery-Smith wrote:
>> On 05/28/2012 06:30 PM, Steve Kargl wrote:
>>
>>>
>>> > From clog.c in http://www.netlib.org/cephes/c9x-complex
>>>
>>> double complex
>>> ccosh (z)
>>>       double complex z;
>>> {
>>>    double complex w;
>>>    double x, y;
>>>
>>>    x = creal(z);
>>>    y = cimag(z);
>>>    w = cosh (x) * cos (y)  +  (sinh (x) * sin (y)) * I;
>>>    return (w);
>>> }
>>>
>>> See math_private.h about the above.
>>>
>>
>> I looked in math_private.h - I presume you meant
>> lib/msun/src/math_private.h.  I wasn't able to find anything about ccosh
>> there.
>>
>> I think that for a rough and ready ccosh, this is high enough quality
>> for a math/cephes port.
>
> That's the problem.  It is not acceptable (imo).  The comment in
> math_private.h that is relevant is
>
> /*
>   * Inline functions that can be used to construct complex values.
>   *
>   * The C99 standard intends x+I*y to be used for this, but x+I*y is
>   * currently unusable in general since gcc introduces many overflow,
>   * underflow, sign and efficiency bugs by rewriting I*y as
>   * (0.0+I)*(y+0.0*I) and laboriously computing the full complex product.
>   * In particular, I*Inf is corrupted to NaN+I*Inf, and I*-0 is corrupted
>   * to -0.0+I*0.0.
>   */
>
> Those wrong +-0 mean you may up end up on the worng riemann sheet,
> and that NaN propagates.
>

OK, I agree with you that gcc fails to be C99 compliant.  But I disagree
with you that this is a big deal.

1.  By being so picky about being so precise, FreeBSD is behind the time
line in rolling out a usable set of C99 functions.  The compilers and
operating systems have many bugs, and if we waited until we were totally
sure that all the bugs were gone, we wouldn't have any operating system
to work with at all.  Why be more picky with floating point arithmetic
than the other aspects of FreeBSD?

2.  If I was really worried about being on the correct Riemann sheet, I
would code very, very carefully, and not rely on numerical accuracy of
any kind of floating point calculation.  There is a certain mathematical
inconsistency in introducing 0, -0 and Inf+I*Inf, and the number of
times programmers really want a very specific kind of behavior for
exceptions is so rare that they are better off writing their own wrapper
code than relying on any library functions.  (For example, is there a
difference between 0 and +0?  If not, does -(0) compute to 0 or -0?  I
can see circumstances where I sometimes want one, and sometimes the other.)

3.  But to counter my own argument, it highly bothers me that in C that
"(-5)%3" evaluates to "-2" and not to "1".  That bug^H^H^H feature has
truly bitten me.  And I have had lengthy arguments online with some C
experts as to why "1" should be the correct answer, without being able
to convince them.  If it were up to me, the whole of the C standard
would be scrapped, and rewritten with everything exactly the same except
for this one thing.  But to those I argued with, I seem just as picky as
you seem when you insist that 0 and -0 are different.  So what do I do?
  I live with it, just like we all live in an imperfect world.

If I had a choice between correcting the C standard for "%" or solving
world hunger, I would definitely settle for the second.  And maybe the C
programming language, for all its imperfections, has helped push
frontiers of technology sufficiently that someone is less hungry than
they would have otherwise been.  And if those resources used to feed
people had been redirected to fix the C standard, then maybe a few more
people would be hungry.

In the end, I do think it is good to ultimately settle on good C99
compliant code.  But having something intermediate that mostly works is
better than nothing.  Especially if it exists only in the ports, and not
in the base code.

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

Peter Jeremy-8
On 2012-May-28 15:54:06 -0700, Steve Kargl <[hidden email]> wrote:
>Given that cephes was written years before C99 was even
>conceived, I suspect all functions are sub-standard.

Well, most of cephes was written before C99.  The C99 parts of
cephes were written to turn it into a complete C99 implementation.

>  For
>example, AFAIK, none of the long double functions are
>appropriate for any platform that has an 128-bit long double;
>as cephes was written for an Intel 80-bit format.

FreeBSD currently supports:
64-bit long doubles on ARM, MIPS and PowerPC;
80-bit long doubles on amd64, i386 and iA64;
128-bit long doubles on SPARC.

The lack of LD128 in cephes therefore only affects one (not widely
used) platform.  The lack of even de facto standards for long
double mean that any applications wanting to use them already need
to cope with at least a 2:1 precision range.

>If portmgr or a port maintainer wants to use a library with
>untested implementations of missing libm functions, please do
>not put it into /usr/local/lib and call it libm.

There some test code in cephes.  Can you point me to a suitable test
suite for LD80 and LD128?  The reason for calling it libm is to avoid
having to hack every consumer to add an additional library.

On 2012-May-28 16:30:35 -0700, Steve Kargl <[hidden email]> wrote:
>Who's writing the code to test the implementations?  That is
>better much the problem.  Without testing, one might get an
>implementation that appears to work until it doesn't!

That is equally true of the rest of FreeBSD.  The list of open PRs
suggests that FreeBSD still has a fair way to go before reaching
perfection.  And, most of this thread has been about using this code
in ports - where the bar is much lower.  Who is writing the code to
test all the other ports?  What is so special about this particular
proposed port that it needs to come with solid-gold credentials?

>  It took
>me 3+ years to get sqrtl() into libm, but bde and das (and
>myself) wanted to make sure the code worked.

Last time I checked (a couple of years ago), FreeBSD was missing 65
C99 libm functions.  At 3 years per function, we should have C99
support available early in the 23rd century - which may be a bit late.

On 2012-May-28 22:03:43 -0500, Stephen Montgomery-Smith <[hidden email]> wrote:
>1.  By being so picky about being so precise, FreeBSD is behind the time
>line in rolling out a usable set of C99 functions.

And at the current rate, we'll all be long dead before they are
available.  Whilst I'd far prefer to have a properly verifed library
function, I think we are better off with an implementation that has
some caveats regarding edge-case behaviour than having nothing.

>In the end, I do think it is good to ultimately settle on good C99
>compliant code.  But having something intermediate that mostly works is
>better than nothing.  Especially if it exists only in the ports, and not
>in the base code.

I agree with this sentiment.

What do people do on other free OSs?  Does a tested open source C99
libm exist anywhere?  glibc implements cpow(x,y) as cexp(y*clog(x))
and cephes does better than that.  Is FreeBSD wasting its time writing
"correct" C99 code because all the libm consumers expect no better
than what glibc offers?

I agree that writing correct libm functions is hard.  I think a lot of
the problem is that it's a mix of lots of boilerplate code testing for
special conditions and edge cases that is boring to write and fiddly
to get right, together with a kernel that is a pile of polynomial
evaluations full of magic numbers that needs specialist skills to
write.  If we could get someone with the relevant skills to formally
list all the special conditions & edge cases for each function, it
should be possible to generate both the library C code and test cases
from that - which would remove a lot of the tedium.

--
Peter Jeremy

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Use of C99 extra long double math functions after r236148

Steve Kargl
On Tue, May 29, 2012 at 02:56:13PM +1000, Peter Jeremy wrote:
> On 2012-May-28 15:54:06 -0700, Steve Kargl <[hidden email]> wrote:
>
> There some test code in cephes.  Can you point me to a suitable test
> suite for LD80 and LD128?  The reason for calling it libm is to avoid
> having to hack every consumer to add an additional library.

I can't point you to test code.  When I work on a function,
I write test code.

> >  It took
> >me 3+ years to get sqrtl() into libm, but bde and das (and
> >myself) wanted to make sure the code worked.
>
> Last time I checked (a couple of years ago), FreeBSD was missing 65
> C99 libm functions.  At 3 years per function, we should have C99
> support available early in the 23rd century - which may be a bit late.

sqrtl() is a bit special in that IEEE 754 requires that
it have no more than 0.5 ULP for all arguments in all
roundng modes.  As to other functions, I've been trying
for 10+ years to get some of these into FreeBSD.  I can
assure you that there has never been a rush of people
volunteering to help or a rush of people willing to fund
the development of the necessary code.

>
> On 2012-May-28 22:03:43 -0500, Stephen Montgomery-Smith <[hidden email]> wrote:
> >1.  By being so picky about being so precise, FreeBSD is behind the time
> >line in rolling out a usable set of C99 functions.
>
> And at the current rate, we'll all be long dead before they are
> available.

It seems you've had "a couple of years" to implement one or
more of the missing functions.  Yes, we'll all be dead before
libm is C99 ready because no one, other than bde@, das@ and
myself, has been willing to actually help write the code.  I
know that at least one of those three people has had no time
in the last year or two work on libm.

--
Steve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
12345