On 2012-02-18 14:38:01 +, James Courtier-Dutton wrote:
> Would it be useful to have some lib functions:
> remainder_2pi(x, &remainder) /* returns remainder of x / 2Pi */
> remainder_pi2(x, &remainder, "ient) /* returns remainder of x /
> (Pi/2) with a quotient returned so you can tell whe
On 13 February 2012 15:24, Vincent Lefevre wrote:
> On 2012-02-10 17:41:49 +, Andrew Haley wrote:
>> On 02/10/2012 05:31 PM, Paweł Sikora wrote:
>> > it would be also nice to see functions for reducing argument range in
>> > public api.
>> > finally the end-user can use e.g. sin(reduce(x)) to
On 02/16/2012 04:21 PM, Joseph S. Myers wrote:
On Thu, 16 Feb 2012, Andrew Haley wrote:
On 02/16/2012 02:42 PM, Vincent Lefevre wrote:
C99 doesn't require directed rounding modes, but as long as they
are claimed to be supported by, they should work:
Ah, I see. So, we could bring gcc+glibc
On Thu, 16 Feb 2012, Andrew Haley wrote:
> On 02/16/2012 02:42 PM, Vincent Lefevre wrote:
> > On 2012-02-15 15:18:45 +, Andrew Haley wrote:
> > > > On 02/15/2012 09:30 AM, Vincent Lefevre wrote:
> > > > > > >> But to be absolutely clear, glibc's libm doesn't have a problem
> > > > > > > >>
On Thu, 16 Feb 2012, Vincent Lefevre wrote:
> Note that functions are not required to honor the rounding
> direction mode (F.9#10). So, locally resetting the rounding mode to
> nearest in these functions would be correct, I think (I don't know
> how this can affect signal handlers, when a signal
On 2012-02-16 14:51:26 +, Andrew Haley wrote:
> Ah, I see. So, we could bring gcc+glibc into compliance by not
> defining the rounding mode macros.
Yes, but... Directed rounding modes can also be used with the
arithmetic operations only, on which there are no problems at the
implementation le
On 02/16/2012 02:42 PM, Vincent Lefevre wrote:
On 2012-02-15 15:18:45 +, Andrew Haley wrote:
> On 02/15/2012 09:30 AM, Vincent Lefevre wrote:
> >> But to be absolutely clear, glibc's libm doesn't have a problem
> >> meeting C99, AFAIK.
> > That's not quite correct. It is completely
On 2012-02-15 15:18:45 +, Andrew Haley wrote:
> On 02/15/2012 09:30 AM, Vincent Lefevre wrote:
> >> But to be absolutely clear, glibc's libm doesn't have a problem
> >> > meeting C99, AFAIK.
> > That's not quite correct. It is completely broken in directed
> > rounding modes (up to crashes).
>
On 02/15/2012 09:30 AM, Vincent Lefevre wrote:
>> But to be absolutely clear, glibc's libm doesn't have a problem
>> > meeting C99, AFAIK.
> That's not quite correct. It is completely broken in directed
> rounding modes (up to crashes).
Eh? C99 doesn't require directed rounding modes. I'll grant
On Tue, 14 Feb 2012, Christoph Lauter wrote:
> As a matter of course, we'd be more than happy to get your input (and even
> guidance w.r.t. copyright management and coding conventions) on and during
> that project.
* GNU projects do not automatically need copyright assignments to the FSF
(some d
On Thu, 9 Feb 2012, Andrew Haley wrote:
> On 02/09/2012 04:53 PM, Joseph S. Myers wrote:
> > My view is that we should have a "GNU libm" project whose purpose is not
> > to install a library directly but to provide functions for use in other
> > projects (much like gnulib, but the functions coul
On Tue, Feb 14, 2012 at 7:54 PM, Christoph Lauter
wrote:
> Hello,
>
> first of all, let me apologize for my late answer to this very exciting
> email thread.
>
> As pointed out several times, the current libm suffers from several
> disadvantages:
>
> * The current libm code is a mix of codes comin
On 2012-02-14 17:04:52 +, Andrew Haley wrote:
> On 02/14/2012 04:54 PM, Geert Bosch wrote:
> >
> > On Feb 14, 2012, at 11:44, Andrew Haley wrote:
> >
> >> On 02/14/2012 04:41 PM, Geert Bosch wrote:
> >>> Right now we don't have a library either that conforms to C99
> >>
> >> Are you sure? As
On Tue, 14 Feb 2012, Geert Bosch wrote:
> However, the glibc math library comes very close, and we can
> surely fix any remaining issues there may be. So, if we can
> use that as base, or as "fallback" library, we suddenly
> achieve some minimal accuracy guarantees across a wide
> range of platfor
On 02/14/2012 06:54 PM, Christoph Lauter wrote:
> My colleagues Jean-Michel Muller, Florent de Dinechin at École Normale
> Supérieure de Lyon/ INRIA/ CNRS and myself at Université Pierre et Marie
> Curie, Paris Sorbonne, we have been thinking of starting such a project
> for quite a while. We've
Hello,
first of all, let me apologize for my late answer to this very exciting
email thread.
As pointed out several times, the current libm suffers from several
disadvantages:
* The current libm code is a mix of codes coming from different sources,
with tables generated by different people
On Feb 13, 2012, at 09:59, Vincent Lefevre wrote:
> On 2012-02-09 15:49:37 +, Andrew Haley wrote:
>> I'd start with INRIA's crlibm.
>
> I point I'd like to correct. GNU MPFR has mainly (> 95%) been
> developed by researchers and engineers paid by INRIA. But this
> is not the case of CRlibm.
On 02/14/2012 04:54 PM, Geert Bosch wrote:
>
> On Feb 14, 2012, at 11:44, Andrew Haley wrote:
>
>> On 02/14/2012 04:41 PM, Geert Bosch wrote:
>>> Right now we don't have a library either that conforms to C99
>>
>> Are you sure? As far as I know we do. We might not meet
>> C99 Annex F, but that'
On Feb 14, 2012, at 11:44, Andrew Haley wrote:
> On 02/14/2012 04:41 PM, Geert Bosch wrote:
>> Right now we don't have a library either that conforms to C99
>
> Are you sure? As far as I know we do. We might not meet
> C99 Annex F, but that's not required.
>
>> and meets the far more relaxed
On 02/14/2012 04:41 PM, Geert Bosch wrote:
> Right now we don't have a library either that conforms to C99
Are you sure? As far as I know we do. We might not meet
C99 Annex F, but that's not required.
> and meets the far more relaxed accuracy criteria of OpenCL and
> Ada.
Andrew.
On Feb 14, 2012, at 08:22, Vincent Lefevre wrote:
> Please do not use the term binary80, as it is confusing (and
> there is a difference between this format and the formats of
> the IEEE binary{k} class concerning the implicit bit).
Yes, I first wrote extended precision, though that really is
a ge
On 02/14/2012 08:26 AM, Vincent Lefevre wrote:
On 2012-02-14 09:51:28 +, Andrew Haley wrote:
On 02/13/2012 08:00 PM, Geert Bosch wrote:
GNU Linux is quite good, but has issues with the "pow" function for
large exponents, even in current versions
Really? Even on 64-bit? I know this is a
On 2012-02-14 14:26:05 +0100, Vincent Lefevre wrote:
> On 2012-02-14 09:51:28 +, Andrew Haley wrote:
> > On 02/13/2012 08:00 PM, Geert Bosch wrote:
> > > GNU Linux is quite good, but has issues with the "pow" function for
> > > large exponents, even in current versions
> >
> > Really? Even on
On 02/14/2012 04:51 AM, Andrew Haley wrote:
On 02/13/2012 08:00 PM, Geert Bosch wrote:
GNU Linux is quite good, but has issues with the "pow" function for
large exponents, even in current versions
Really? Even on 64-bit? I know this is a problem for the 32-bit
legacy architecture, but I thou
On 2012-02-14 09:51:28 +, Andrew Haley wrote:
> On 02/13/2012 08:00 PM, Geert Bosch wrote:
> > GNU Linux is quite good, but has issues with the "pow" function for
> > large exponents, even in current versions
>
> Really? Even on 64-bit? I know this is a problem for the 32-bit
> legacy archit
On 2012-02-13 15:00:54 -0500, Geert Bosch wrote:
> Properties:
>
> [ ] Conforms to C99 for exceptional values
>(accepting/producing NaNs, infinities)
>
> [ ] Handles non-default rounding modes,
>trapping math, errno, etc.
>
> [ ] Requires IEEE compliant binary64 arithme
On 02/13/2012 08:00 PM, Geert Bosch wrote:
> GNU Linux is quite good, but has issues with the "pow" function for
> large exponents, even in current versions
Really? Even on 64-bit? I know this is a problem for the 32-bit
legacy architecture, but I thought the 64-bit pow() was OK.
Andrew.
> On 2012-02-09 12:36:01 -0500, Geert Bosch wrote:
>> I think it would make sense to have a check list of properties, and
>> use configure-based tests to categorize implementations. These tests
>> would be added as we go along.
>>
>> Criteria:
>>
>> [ ] Conforms to C99 for exceptional values
>
On Mon, 13 Feb 2012, Jakub Jelinek wrote:
> Furthermore, crlibm_init changes the i?86/x86_64 rounding mode globally,
> that is not appropriate for a general purpose math library, there you either
> need to cope with extended precision, or rely on SSE/SSE2 for float/double,
> or change the rounding
On 2012-02-10 17:41:49 +, Andrew Haley wrote:
> On 02/10/2012 05:31 PM, Paweł Sikora wrote:
> > it would be also nice to see functions for reducing argument range in
> > public api.
> > finally the end-user can use e.g. sin(reduce(x)) to get the best precision
> > with some declared cpu overhe
On 2012-02-09 15:49:37 +, Andrew Haley wrote:
> I'd start with INRIA's crlibm.
I point I'd like to correct. GNU MPFR has mainly (> 95%) been
developed by researchers and engineers paid by INRIA. But this
is not the case of CRlibm. I don't know its copyright status
(apparently, mainly ENS Lyon,
On Mon, Feb 13, 2012 at 3:32 PM, Jakub Jelinek wrote:
> On Mon, Feb 13, 2012 at 02:48:05PM +0100, Richard Guenther wrote:
>> > I think there is some consensus that crlibm is a great place to start
>> > for correctly-rounded elementary functions. I think we'd need, or at
>> > least greatly appreci
On Mon, Feb 13, 2012 at 02:48:05PM +0100, Richard Guenther wrote:
> > I think there is some consensus that crlibm is a great place to start
> > for correctly-rounded elementary functions. I think we'd need, or at
> > least greatly appreciate, some help from your team.
>
> I agree. If crlibm can
On Mon, 13 Feb 2012, Vincent Lefevre wrote:
> Also note that CRlibm supports the 4 rounding modes, while the
> IBM Accurate Mathematical Library currently used in glibc behaves
> erratically (e.g. can even crash) on directed rounding modes.
FWIW the proposed ISO C bindings to IEEE 754-2008 (still
On 2012-02-09 12:36:01 -0500, Geert Bosch wrote:
> I think it would make sense to have a check list of properties, and
> use configure-based tests to categorize implementations. These tests
> would be added as we go along.
>
> Criteria:
>
> [ ] Conforms to C99 for exceptional values
> (acc
On 2012-02-09 17:18:25 +, Joseph S. Myers wrote:
> The crlibm approach, involving exhaustive searches for worst cases for
> directed rounding, could as I understand it work for functions of one
> float, double or 80-bit long double argument, but I think the exhaustive
> searches are still in
On Mon, Feb 13, 2012 at 2:32 PM, Andrew Haley wrote:
> On 02/13/2012 01:11 PM, Vincent Lefevre wrote:
>> On 2012-02-09 16:01:48 +, Andrew Haley wrote:
>>> On 02/09/2012 03:59 PM, Richard Guenther wrote:
>
Maybe. Nothing would prevent us from composing from multiple sources
of course
On 02/13/2012 01:11 PM, Vincent Lefevre wrote:
> On 2012-02-09 16:01:48 +, Andrew Haley wrote:
>> On 02/09/2012 03:59 PM, Richard Guenther wrote:
>>> Maybe. Nothing would prevent us from composing from multiple sources
>>> of course. crlibm also only provides double precision routines.
>>
>>
On 2012-02-09 16:01:48 +, Andrew Haley wrote:
> On 02/09/2012 03:59 PM, Richard Guenther wrote:
> > On Thu, Feb 9, 2012 at 4:57 PM, Andrew Haley wrote:
> >> On 02/09/2012 03:56 PM, Michael Matz wrote:
> >>> Hi,
> >>>
> >>> On Thu, 9 Feb 2012, Andrew Haley wrote:
> >>>
> On 02/09/2012 03:2
On Fri, Feb 10, 2012 at 5:25 PM, Geert Bosch wrote:
>
> On Feb 10, 2012, at 05:07, Richard Guenther wrote:
>
>> On Thu, Feb 9, 2012 at 8:16 PM, Geert Bosch wrote:
>>> I don't agree having such a libm is the ultimate goal. It could be
>>> a first step along the way, addressing correctness issues.
On Thu, Feb 09, 2012 at 04:59:55PM +0100, Richard Guenther wrote:
> On Thu, Feb 9, 2012 at 4:57 PM, Andrew Haley wrote:
> > On 02/09/2012 03:56 PM, Michael Matz wrote:
> >> On Thu, 9 Feb 2012, Andrew Haley wrote:
> >>
> >>> On 02/09/2012 03:28 PM, Richard Guenther wrote:
> So - do you have an
On Friday 10 of February 2012 17:41:49 Andrew Haley wrote:
> On 02/10/2012 05:31 PM, Paweł Sikora wrote:
> > it would be also nice to see functions for reducing argument range in
> > public api.
> > finally the end-user can use e.g. sin(reduce(x)) to get the best precision
> > with some declared c
On 02/10/2012 05:31 PM, Paweł Sikora wrote:
> it would be also nice to see functions for reducing argument range in public
> api.
> finally the end-user can use e.g. sin(reduce(x)) to get the best precision
> with some declared cpu overhead.
Hmm. I'm not sure this is such a terrific idea: each f
On Fri, 10 Feb 2012, Geert Bosch wrote:
> Right. I even understand where he is coming from. Adding new interfaces
> is indeed a big deal as they'll pretty much have to stay around forever.
And: even if the interface is a known, public, standard, stable interface,
glibc may still not be the right
On Friday 10 of February 2012 13:30:25 James Courtier-Dutton wrote:
> On 10 February 2012 10:42, Andrew Haley wrote:
> > On 02/10/2012 10:07 AM, Richard Guenther wrote:
> >>
> >> The issue with libm in glibc here is that Drepper absolutely does
> >> not want new ABIs in libm - he believes that for
On Fri, 10 Feb 2012, Geert Bosch wrote:
> On Feb 9, 2012, at 15:33, Joseph S. Myers wrote:
> > For a few, yes, inline support (such as already exists for some functions
> > on some targets) makes sense. But for some more complicated cases it
> > seems plausible that LTO information in a library
On Feb 10, 2012, at 05:07, Richard Guenther wrote:
> On Thu, Feb 9, 2012 at 8:16 PM, Geert Bosch wrote:
>> I don't agree having such a libm is the ultimate goal. It could be
>> a first step along the way, addressing correctness issues. This
>> would be great progress, but does not remove the nee
On Feb 9, 2012, at 15:33, Joseph S. Myers wrote:
> For a few, yes, inline support (such as already exists for some functions
> on some targets) makes sense. But for some more complicated cases it
> seems plausible that LTO information in a library might be an appropriate
> way of inlining whil
On 10 February 2012 14:36, Andrew Haley wrote:
> On 02/10/2012 02:24 PM, James Courtier-Dutton wrote:
>> On 10 February 2012 14:05, Andrew Haley wrote:
>>> On 02/10/2012 01:30 PM, James Courtier-Dutton wrote:
On 10 February 2012 10:42, Andrew Haley wrote:
I think a starting point
On 02/10/2012 02:24 PM, James Courtier-Dutton wrote:
> On 10 February 2012 14:05, Andrew Haley wrote:
>> On 02/10/2012 01:30 PM, James Courtier-Dutton wrote:
>>> On 10 February 2012 10:42, Andrew Haley wrote:
>>>
>>> I think a starting point would be at least documenting correctly the
>>> accurac
On 10 February 2012 14:05, Andrew Haley wrote:
> On 02/10/2012 01:30 PM, James Courtier-Dutton wrote:
>> On 10 February 2012 10:42, Andrew Haley wrote:
>>
>> I think a starting point would be at least documenting correctly the
>> accuracy of the current libm, because what is currently in the
>> d
On 02/10/2012 01:30 PM, James Courtier-Dutton wrote:
> On 10 February 2012 10:42, Andrew Haley wrote:
>
> I think a starting point would be at least documenting correctly the
> accuracy of the current libm, because what is currently in the
> documents is obviously wrong.
> It certainly does not d
On Fri, 10 Feb 2012, Richard Guenther wrote:
> I don't buy the argument that inlining math routines (apart from those
> we already handle) would improve performance. What will improve
> performance is to have separate entry points to the routines
> to skip errno handling, NaN/Inf checking or roun
On 10 February 2012 10:42, Andrew Haley wrote:
> On 02/10/2012 10:07 AM, Richard Guenther wrote:
>>
>> The issue with libm in glibc here is that Drepper absolutely does
>> not want new ABIs in libm - he believes that for example vectorized
>> routines do not belong there (nor the SSE calling-conve
On 02/10/2012 10:07 AM, Richard Guenther wrote:
>
> The issue with libm in glibc here is that Drepper absolutely does
> not want new ABIs in libm - he believes that for example vectorized
> routines do not belong there (nor the SSE calling-convention variants
> for i686 I tried to push once).
Tha
On Thu, Feb 9, 2012 at 8:16 PM, Geert Bosch wrote:
>
> On Feb 9, 2012, at 12:55, Joseph S. Myers wrote:
>
>> No, that's not the case. Rather, the point would be that both GCC's
>> library and glibc's end up being based on the new GNU project (which might
>> take some code from glibc and some from
On Thu, 9 Feb 2012, Geert Bosch wrote:
> I don't agree having such a libm is the ultimate goal. It could be
> a first step along the way, addressing correctness issues. This
Indeed, I think having it as a first step makes sense - with subsequent
development done in that context.
> would be grea
On Thu, 9 Feb 2012, Andrew Haley wrote:
> > No, the point of the separate project would be to be used by both glibc
> > and GCC (and possibly other GNU projects such as GSL) - because
> > cooperation among the various projects wanting such functions is the right
> > way to do things.
>
> Well,
On Feb 9, 2012, at 12:55, Joseph S. Myers wrote:
> No, that's not the case. Rather, the point would be that both GCC's
> library and glibc's end up being based on the new GNU project (which might
> take some code from glibc and some from elsewhere - and quite possibly
> write some from scratc
On 02/09/2012 06:00 PM, Joseph S. Myers wrote:
> On Thu, 9 Feb 2012, Andrew Haley wrote:
>
>> On 02/09/2012 04:53 PM, Joseph S. Myers wrote:
>>> My view is that we should have a "GNU libm" project whose purpose is not
>>> to install a library directly but to provide functions for use in other
>>
On Thu, 9 Feb 2012, Andrew Haley wrote:
> On 02/09/2012 04:53 PM, Joseph S. Myers wrote:
> > My view is that we should have a "GNU libm" project whose purpose is not
> > to install a library directly but to provide functions for use in other
> > projects (much like gnulib, but the functions coul
On Thu, 9 Feb 2012, Geert Bosch wrote:
> While I think it would be great if there were a suitable
> GNU libm project that we could directly use, this seems to only
> make sense if this could be based on the current glibc math
> library. As far as I understand, it is unlikely that we
No, that's no
On 02/09/2012 04:53 PM, Joseph S. Myers wrote:
> My view is that we should have a "GNU libm" project whose purpose is not
> to install a library directly but to provide functions for use in other
> projects (much like gnulib, but the functions could presume that they were
> being built with rece
On Feb 9, 2012, at 10:28, Richard Guenther wrote:
> Yes, definitely! OTOH last time I added the toplevel libgcc-math directory
> and populated it with sources from glibc RMS objected violently and I had
> to remove it again. So we at least need to find a different source of
> math routines to st
On Thu, 9 Feb 2012, Andrew Haley wrote:
> Okay, but the crlibm algorithms could be extended to long
> doubles and, presumably, floats. Where's Vincent Lefevre
> when you need him? :-)
The crlibm approach, involving exhaustive searches for worst cases for
directed rounding, could as I understa
On Thu, 9 Feb 2012, Richard Guenther wrote:
> > Given the fact that GCC already needs to know pretty much everything
> > about these functions for optimizations and constant folding, and is
> > in the best situation to choose specific implementations (-ffast-math
> > or not, -frounding-math or not
Hi,
On Thu, 9 Feb 2012, Andrew Haley wrote:
> >>> So - do you have an idea what routines we can start off with to get
> >>> a full C99 set of routines for float, double and long double? The
> >>> last time I was exploring the idea again I was looking at the BSD
> >>> libm.
> >>
> >> I'd start
Hi,
On Thu, 9 Feb 2012, James Courtier-Dutton wrote:
> Results when compiled for 32bit x86.
> gcc -m32 -g -O0 -c -o sincos1.o sincos1.c
> gcc -m32 -static -g -o sincos1 sincos1.o -lm
>
> ./sincos1
> sin = 4.62613040764601746e-01
> sinl = 0.46261304076460176
> sincos = 4.62613040764601746e-01
> s
On 02/09/2012 03:59 PM, Richard Guenther wrote:
> On Thu, Feb 9, 2012 at 4:57 PM, Andrew Haley wrote:
>> On 02/09/2012 03:56 PM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Thu, 9 Feb 2012, Andrew Haley wrote:
>>>
On 02/09/2012 03:28 PM, Richard Guenther wrote:
> So - do you have an idea what
On Thu, Feb 9, 2012 at 4:57 PM, Andrew Haley wrote:
> On 02/09/2012 03:56 PM, Michael Matz wrote:
>> Hi,
>>
>> On Thu, 9 Feb 2012, Andrew Haley wrote:
>>
>>> On 02/09/2012 03:28 PM, Richard Guenther wrote:
So - do you have an idea what routines we can start off with to get
a full C99 set
On 02/09/2012 03:55 PM, James Courtier-Dutton wrote:
> Results for x86_64
> gcc -g -O0 -c -o sincos1.o sincos1.c
> gcc -static -g -o sincos1 sincos1.o -lm
>
> ./sincos1
> sin = -8.52200849767188795e-01(uses xmm register intructions)
> sinl = 0.46261304076460176 (uses fprem and fsin)
On 02/09/2012 03:56 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 9 Feb 2012, Andrew Haley wrote:
>
>> On 02/09/2012 03:28 PM, Richard Guenther wrote:
>>> So - do you have an idea what routines we can start off with to get
>>> a full C99 set of routines for float, double and long double? The last
>>
Hi,
On Thu, 9 Feb 2012, Andrew Haley wrote:
> On 02/09/2012 03:28 PM, Richard Guenther wrote:
> > So - do you have an idea what routines we can start off with to get
> > a full C99 set of routines for float, double and long double? The last
> > time I was exploring the idea again I was looking a
On 9 February 2012 14:51, James Courtier-Dutton wrote:
> 2012/2/9 Andrew Haley :
>> On 02/09/2012 01:38 PM, Tim Prince wrote:
>>> x87 built-ins should be a fair compromise between speed, code size, and
>>> accuracy, for long double, on most CPUs. As Richard says, it's
>>> certainly possible to do
On 02/09/2012 03:28 PM, Richard Guenther wrote:
> So - do you have an idea what routines we can start off with to get
> a full C99 set of routines for float, double and long double? The last
> time I was exploring the idea again I was looking at the BSD libm.
I'd start with INRIA's crlibm.
Andre
On Thu, Feb 9, 2012 at 4:20 PM, Geert Bosch wrote:
>
> On Feb 9, 2012, at 08:46, Andrew Haley wrote:
>> n 02/09/2012 01:38 PM, Tim Prince wrote:
>>> x87 built-ins should be a fair compromise between speed, code size, and
>>> accuracy, for long double, on most CPUs. As Richard says, it's
>>> certa
On Feb 9, 2012, at 08:46, Andrew Haley wrote:
> n 02/09/2012 01:38 PM, Tim Prince wrote:
>> x87 built-ins should be a fair compromise between speed, code size, and
>> accuracy, for long double, on most CPUs. As Richard says, it's
>> certainly possible to do better in the context of SSE, but gcc
On 02/09/2012 02:51 PM, James Courtier-Dutton wrote:
> 2012/2/9 Andrew Haley :
>> On 02/09/2012 01:38 PM, Tim Prince wrote:
>>> x87 built-ins should be a fair compromise between speed, code size, and
>>> accuracy, for long double, on most CPUs. As Richard says, it's
>>> certainly possible to do be
2012/2/9 Andrew Haley :
> On 02/09/2012 01:38 PM, Tim Prince wrote:
>> x87 built-ins should be a fair compromise between speed, code size, and
>> accuracy, for long double, on most CPUs. As Richard says, it's
>> certainly possible to do better in the context of SSE, but gcc doesn't
>> know anythin
On 02/09/2012 01:38 PM, Tim Prince wrote:
> x87 built-ins should be a fair compromise between speed, code size, and
> accuracy, for long double, on most CPUs. As Richard says, it's
> certainly possible to do better in the context of SSE, but gcc doesn't
> know anything about the quality of math
On 2/9/2012 5:55 AM, Richard Guenther wrote:
On Thu, Feb 9, 2012 at 11:35 AM, Andrew Haley wrote:
On 02/09/2012 10:20 AM, James Courtier-Dutton wrote:
From what I can see, on x86_64, the hardware fsin(x) is more accurate
than the hardware fsincos(x).
As you gradually increase the size of X fr
On Thu, Feb 9, 2012 at 11:35 AM, Andrew Haley wrote:
> On 02/09/2012 10:20 AM, James Courtier-Dutton wrote:
>> From what I can see, on x86_64, the hardware fsin(x) is more accurate
>> than the hardware fsincos(x).
>> As you gradually increase the size of X from 0 to 10e22, fsincos(x)
>> diverges f
On 02/09/2012 10:20 AM, James Courtier-Dutton wrote:
> From what I can see, on x86_64, the hardware fsin(x) is more accurate
> than the hardware fsincos(x).
> As you gradually increase the size of X from 0 to 10e22, fsincos(x)
> diverges from the correct accurate value quicker than fsin(x) does.
>
On 3 February 2012 21:48, Vincent Lefevre wrote:
> On 2012-02-03 17:44:21 +0100, Michael Matz wrote:
>> Hi,
>>
>> On Fri, 3 Feb 2012, Vincent Lefevre wrote:
>>
>> > > > For the glibc, I've finally reported a bug here:
>> > > >
>> > > > http://sourceware.org/bugzilla/show_bug.cgi?id=13658
>> > >
On Mon, Feb 6, 2012 at 1:29 PM, Vincent Lefevre wrote:
> On 2012-02-06 12:54:09 +0100, Richard Guenther wrote:
>> Note that you are comparing a constant folded sin() result against
>> sincos() (or sin() and cos()). Use
>>
>> #include
>> #include
>>
>> int main (void)
>> {
>> double x, c, s;
>>
On 2012-02-06 12:54:09 +0100, Richard Guenther wrote:
> Note that you are comparing a constant folded sin() result against
> sincos() (or sin() and cos()). Use
>
> #include
> #include
>
> int main (void)
> {
> double x, c, s;
> volatile double v;
>
> x = 1.0e22;
> v = x;
> x = v;
>
On Sat, Feb 4, 2012 at 11:20 AM, James Courtier-Dutton
wrote:
> On 4 February 2012 00:06, Vincent Lefevre wrote:
>> On 2012-02-03 17:40:05 +0100, Dominique Dhumieres wrote:
>>> While I fail to see how the "correct value" of
>>> cos(4.47460300787e+182)+sin(4.47460300787e+182)
>>> can be defined in
On 2012-02-05 20:52:39 +, Dave Korn wrote:
> On 05/02/2012 19:01, Vincent Lefevre wrote:
> > On 2012-02-04 13:00:45 +0100, Andreas Schwab wrote:
> >> But it is indistinguishable from 10^22+pi. So both -0.8522008497671888
> >> and 0.8522008497671888 are correct results, or anything inbetween.
>
On 05/02/2012 19:01, Vincent Lefevre wrote:
> On 2012-02-04 13:00:45 +0100, Andreas Schwab wrote:
>> But it is indistinguishable from 10^22+pi. So both -0.8522008497671888
>> and 0.8522008497671888 are correct results, or anything inbetween.
>
> No, 10^22 and 10^22+pi are different numbers.
O
On Feb 5, 2012, at 11:08, James Courtier-Dutton wrote:
> But, r should be
> 5.26300791462049950360708478127784... or
> -1.020177392559086973318201985281...
> according to wolfram alpha and most arbitrary maths libs I tried.
>
> I need to do a bit more digging, but this might point to a bug in th
On 2012-02-04 13:00:45 +0100, Andreas Schwab wrote:
> But it is indistinguishable from 10^22+pi. So both -0.8522008497671888
> and 0.8522008497671888 are correct results, or anything inbetween.
No, 10^22 and 10^22+pi are different numbers. You are not
following the IEEE 754 model, where each inpu
On 02/05/2012 11:08 AM, James Courtier-Dutton wrote:
Hi,
I looked at this a bit closer.
sin(1.0e22) is outside the +-2^63 range, so FPREM1 is used to bring it
inside the range.
So, I looked at FPREM1 a bit closer.
#include
#include
int main (void)
{
long double x, r, m;
x = 1.0e22;
// x
Hi,
I looked at this a bit closer.
sin(1.0e22) is outside the +-2^63 range, so FPREM1 is used to bring it
inside the range.
So, I looked at FPREM1 a bit closer.
#include
#include
int main (void)
{
long double x, r, m;
x = 1.0e22;
// x = 5.26300791462049950360708478127784; <- This is what t
On 04/02/2012 10:20, James Courtier-Dutton wrote:
>> #include
>> #include
>>
>> int main (void)
>> {
>> double x, c, s;
>> volatile double v;
>>
>> x = 1.0e22;
>> s = sin (x);
>> printf ("sin(%.17g) = %.17g\n", x, s);
>>
>> v = x;
>> x = v;
>> c = cos (x);
>> s = sin (x);
>> printf ("s
On 2/4/2012 9:57 AM, Andreas Schwab wrote:
\
How can the sine function know which of the millions of numbers
represented by 0x1.0f0cf064dd591p+73 are meant? Applying the sine to
this interval covers the whole result domain of the function.
The idea that an IEEE number necessarily represents an
Robert Dewar writes:
> On 2/4/2012 9:09 AM, Andreas Schwab wrote:
>> Robert Dewar writes:
>>
>>> But if you write a literal that can be represented exactly, then it is
>>> perfectly reasonable to expect trig functions to give the proper
>>> result, which is unambiguous in this case.
>>
>> How do
On 2/4/2012 9:09 AM, Andreas Schwab wrote:
Robert Dewar writes:
But if you write a literal that can be represented exactly, then it is
perfectly reasonable to expect trig functions to give the proper
result, which is unambiguous in this case.
How do you know that the number is exact?
Sorry
Robert Dewar writes:
> But if you write a literal that can be represented exactly, then it is
> perfectly reasonable to expect trig functions to give the proper
> result, which is unambiguous in this case.
How do you know that the number is exact?
Andreas.
--
Andreas Schwab, sch...@linux-m68k
On 2/4/2012 7:00 AM, Andreas Schwab wrote:
Vincent Lefevre writes:
Wrong. 53 bits of precision. And 10^22 is the last power of 10
exactly representable in double precision (FYI, this example has
been chosen because of this property).
But it is indistinguishable from 10^22+pi. So both -0.852
Vincent Lefevre writes:
> Wrong. 53 bits of precision. And 10^22 is the last power of 10
> exactly representable in double precision (FYI, this example has
> been chosen because of this property).
But it is indistinguishable from 10^22+pi. So both -0.8522008497671888
and 0.8522008497671888 are
1 - 100 of 124 matches
Mail list logo
