Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 May 2012 16:28:17 +0200
From:      Rainer Hurling <rhurlin@gwdg.de>
To:        David Chisnall <theraven@FreeBSD.org>
Cc:        freebsd-current@FreeBSD.org
Subject:   Re: Use of C99 extra long double math functions after r236148
Message-ID:  <4FC38B81.6000302@gwdg.de>
In-Reply-To: <DFE44442-A1B1-40B3-9A79-874BD2BE45E7@FreeBSD.org>
References:  <4FC30090.4070003@gwdg.de> <4D8CF7D2-CBEE-438E-A9E7-9C47A8892622@FreeBSD.org> <4FC36FE1.9080908@gwdg.de> <DFE44442-A1B1-40B3-9A79-874BD2BE45E7@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FC38B81.6000302>