On 30/09/16 14:13 +0100, Szabolcs Nagy wrote:
On 30/09/16 10:35, Szabolcs Nagy wrote:
On 29/09/16 14:37, Andre Vieira (lists) wrote:
On arm-none-eabi I'm seeing a failure for the long double type and inputs:
{ 1e-2l, 1e-4l, 1e-4l, 0.0150004999375l }
The abs(frac) is higher than the
On 30/09/16 10:35, Szabolcs Nagy wrote:
> On 29/09/16 14:37, Andre Vieira (lists) wrote:
>>
>> On arm-none-eabi I'm seeing a failure for the long double type and inputs:
>> { 1e-2l, 1e-4l, 1e-4l, 0.0150004999375l }
>>
>> The abs(frac) is higher than the toler: 1.73455e-16 vs 1e-16. Is that
On 29/09/16 14:37, Andre Vieira (lists) wrote:
>
> On arm-none-eabi I'm seeing a failure for the long double type and inputs:
> { 1e-2l, 1e-4l, 1e-4l, 0.0150004999375l }
>
> The abs(frac) is higher than the toler: 1.73455e-16 vs 1e-16. Is that a
> reasonable difference? Should we raise
On 29/09/16 14:37 +0100, Andre Vieira (lists) wrote:
Hi Jonathan,
On 27/09/16 16:11, Jonathan Wakely wrote:
The test might not be very good, but tests some small integer values
and some other values where accuracy is lost for one or other of the
alternative implementations mentioned above. If
Hi Jonathan,
On 27/09/16 16:11, Jonathan Wakely wrote:
>
> The test might not be very good, but tests some small integer values
> and some other values where accuracy is lost for one or other of the
> alternative implementations mentioned above. If this FAILs for some
> 32-bit targets we might
On 29/09/16 13:12 +0100, Jonathan Wakely wrote:
On 29/09/16 14:02 +0200, Rainer Orth wrote:
Hi Jonathan,
If only there was some way the Solaris team could contact us so we
could coordinate and stop adding more and more hacks to mess with each
others headers. But I assume they don't have
On 29/09/16 14:02 +0200, Rainer Orth wrote:
Hi Jonathan,
If only there was some way the Solaris team could contact us so we
could coordinate and stop adding more and more hacks to mess with each
others headers. But I assume they don't have access to the www or
email, because the only other
Hi Jonathan,
>>If only there was some way the Solaris team could contact us so we
>>could coordinate and stop adding more and more hacks to mess with each
>>others headers. But I assume they don't have access to the www or
>>email, because the only other explanation is too rude to say on a
On 29/09/16 11:47 +0100, Jonathan Wakely wrote:
On 29/09/16 12:39 +0200, Rainer Orth wrote:
Hi Jonathan,
That would suggest Solaris uses include/c_std/cmath (where I forgot to
add the new overloads) rather than include/c_global/cmath ... is that
right?
Alternatively it's using
Hi Jonathan,
>>It turns out the #undef's are from :
>>
>>#if __cplusplus >= 201103L
>>#undef _GLIBCXX_USE_C99_MATH
>>#undef _GLIBCXX_USE_C99_MATH_TR1
>>#endif
>>
>>No idea what this nonsense is trying to accomplish! It's already in
>>Solaris 11.3, however.
>
> Wow.
>
> If only there was some
On 29/09/16 12:39 +0200, Rainer Orth wrote:
Hi Jonathan,
That would suggest Solaris uses include/c_std/cmath (where I forgot to
add the new overloads) rather than include/c_global/cmath ... is that
right?
Alternatively it's using c_global/cmath but _GLIBCXX_USE_C99_MATH_TR1
is not defined,
Hi Jonathan,
>>That would suggest Solaris uses include/c_std/cmath (where I forgot to
>>add the new overloads) rather than include/c_global/cmath ... is that
>>right?
>
> Alternatively it's using c_global/cmath but _GLIBCXX_USE_C99_MATH_TR1
> is not defined, as the new overloads are inside that
Hi Jonathan,
> That would suggest Solaris uses include/c_std/cmath (where I forgot to
> add the new overloads) rather than include/c_global/cmath ... is that
> right?
no, include/cmath points to the c_global version.
Rainer
--
On 29/09/16 10:10 +0100, Jonathan Wakely wrote:
On 29/09/16 10:54 +0200, Rainer Orth wrote:
Hi Jonathan,
This adds the new 3D std::hypot() functions. This implementation seems
to be faster than the naïve sqrt(x*x + y*y + z*z) implementation, or
hypot(hypot(x, y), z), and should be a bit more
On 29/09/16 10:54 +0200, Rainer Orth wrote:
Hi Jonathan,
This adds the new 3D std::hypot() functions. This implementation seems
to be faster than the naïve sqrt(x*x + y*y + z*z) implementation, or
hypot(hypot(x, y), z), and should be a bit more accurate at very large
or very small values due
Hi Jonathan,
> This adds the new 3D std::hypot() functions. This implementation seems
> to be faster than the naïve sqrt(x*x + y*y + z*z) implementation, or
> hypot(hypot(x, y), z), and should be a bit more accurate at very large
> or very small values due to reducing the arguments by the largest
On 28/09/16 12:40 +, Joseph Myers wrote:
On Wed, 28 Sep 2016, Jonathan Wakely wrote:
On 27/09/16 23:28 +, Joseph Myers wrote:
> On Tue, 27 Sep 2016, Jonathan Wakely wrote:
>
> > This adds the new 3D std::hypot() functions. This implementation seems
> > to be faster than the naïve
On Wed, 28 Sep 2016, Jonathan Wakely wrote:
> On 27/09/16 23:28 +, Joseph Myers wrote:
> > On Tue, 27 Sep 2016, Jonathan Wakely wrote:
> >
> > > This adds the new 3D std::hypot() functions. This implementation seems
> > > to be faster than the naïve sqrt(x*x + y*y + z*z) implementation, or
>
On 28/09/16 13:31 +0200, Marc Glisse wrote:
On Wed, 28 Sep 2016, Jonathan Wakely wrote:
On 27/09/16 23:28 +, Joseph Myers wrote:
On Tue, 27 Sep 2016, Jonathan Wakely wrote:
This adds the new 3D std::hypot() functions. This implementation seems
to be faster than the naïve sqrt(x*x + y*y
On Wed, 28 Sep 2016, Jonathan Wakely wrote:
On 27/09/16 23:28 +, Joseph Myers wrote:
On Tue, 27 Sep 2016, Jonathan Wakely wrote:
This adds the new 3D std::hypot() functions. This implementation seems
to be faster than the naïve sqrt(x*x + y*y + z*z) implementation, or
hypot(hypot(x, y),
On 27/09/16 23:50 +0200, Marc Glisse wrote:
On Tue, 27 Sep 2016, Jonathan Wakely wrote:
This adds the new 3D std::hypot() functions. This implementation seems
to be faster than the naïve sqrt(x*x + y*y + z*z) implementation, or
hypot(hypot(x, y), z), and should be a bit more accurate at very
On 27/09/16 23:28 +, Joseph Myers wrote:
On Tue, 27 Sep 2016, Jonathan Wakely wrote:
This adds the new 3D std::hypot() functions. This implementation seems
to be faster than the naïve sqrt(x*x + y*y + z*z) implementation, or
hypot(hypot(x, y), z), and should be a bit more accurate at very
On Tue, 27 Sep 2016, Jonathan Wakely wrote:
> This adds the new 3D std::hypot() functions. This implementation seems
> to be faster than the naïve sqrt(x*x + y*y + z*z) implementation, or
> hypot(hypot(x, y), z), and should be a bit more accurate at very large
> or very small values due to
On Tue, 27 Sep 2016, Jonathan Wakely wrote:
This adds the new 3D std::hypot() functions. This implementation seems
to be faster than the naïve sqrt(x*x + y*y + z*z) implementation, or
hypot(hypot(x, y), z), and should be a bit more accurate at very large
or very small values due to reducing the
This adds the new 3D std::hypot() functions. This implementation seems
to be faster than the naïve sqrt(x*x + y*y + z*z) implementation, or
hypot(hypot(x, y), z), and should be a bit more accurate at very large
or very small values due to reducing the arguments by the largest one.
Improvements
25 matches
Mail list logo
