Hi Wilco,
On Thu, Nov 08, 2018 at 01:33:19PM +, Wilco Dijkstra wrote:
> > But the max. error in sinh/cosh/atanh is less than 2 ULP, with some math
> > libraries. It could be < 1 ULP, in theory, so sinh(atanh(x)) less than
> > 2 ULP even.
>
> You can't add ULP errors in general - a tiny
On Sat, Nov 10, 2018 at 6:36 AM Segher Boessenkool
wrote:
>
> On Fri, Nov 09, 2018 at 01:03:55PM -0700, Jeff Law wrote:
> > >> And signed zeroes. Yeah. I think it would have to be
> > >> flag_unsafe_math_optimizations + some more.
> > >
> > > Indeed.
> > So we need to give Giuliano some clear
On Fri, Nov 09, 2018 at 01:03:55PM -0700, Jeff Law wrote:
> >> And signed zeroes. Yeah. I think it would have to be
> >> flag_unsafe_math_optimizations + some more.
> >
> > Indeed.
> So we need to give Giuliano some clear guidance on guarding. This is
> out of my area of expertise, so looking
Hi. Sorry for the late reply :P
> But the max. error in sinh/cosh/atanh is less than 2 ULP, with some math
> ibraries. It could be < 1 ULP, in theory, so sinh(atanh(x)) less than
>2 ULP even.
Sorry, but doesn't the user agree to sacrifice precision for
performance when -ffast-math is enabled?
On 11/8/18 6:33 AM, Wilco Dijkstra wrote:
> Hi,
>
>> But the max. error in sinh/cosh/atanh is less than 2 ULP, with some math
>> libraries. It could be < 1 ULP, in theory, so sinh(atanh(x)) less than
>> 2 ULP even.
>
> You can't add ULP errors in general - a tiny difference in the input can
>
Hi,
> But the max. error in sinh/cosh/atanh is less than 2 ULP, with some math
> libraries. It could be < 1 ULP, in theory, so sinh(atanh(x)) less than
> 2 ULP even.
You can't add ULP errors in general - a tiny difference in the input can
make a huge difference in the result if the derivative
On Wed, Nov 07, 2018 at 10:34:30PM +, Wilco Dijkstra wrote:
> Hi Jeff,
>
> > So if we're going from 0->2 ULPs in some cases, do we want to guard it
> > with one of the various options, if so, which? Giuliano's follow-up
> > will still have the potential for 2ULPs.
>
> The ULP difference is
Hi Jeff,
> So if we're going from 0->2 ULPs in some cases, do we want to guard it
> with one of the various options, if so, which? Giuliano's follow-up
> will still have the potential for 2ULPs.
The ULP difference is not important since the individual math functions
already have ULP of 3 or
On 10/23/18 3:17 AM, Richard Biener wrote:
> On Mon, Oct 22, 2018 at 10:09 PM Jeff Law wrote:
>>
>> On 10/20/18 9:47 AM, Giuliano Augusto Faulin Belinassi wrote:
>>> So I did some further investigation comparing the ULP error.
>>>
>>> With the formula that Wilco Dijkstra provided, there are cases
Hi,
>> Generally the goal is 1ULP in round to nearest
>
> Has that changed recently? At least in the past for double the goal has
> been always .5ULP in round to nearest.
Yes. 0.5 ULP (perfect rounding) as a goal was insane as it caused ridiculous
slowdowns in the 10x range for no apparent
On Tue, Oct 23, 2018 at 10:37:54AM +, Wilco Dijkstra wrote:
> >> So I think the runtime math libraries shoot for .5 ULP (yes, they don't
> >> always make it, but that's their goal). We should probably have the
> >> same goal. Going from 0 to 2 ULPs would be considered bad.
>
> Generally the
Hi,
>> So I think the runtime math libraries shoot for .5 ULP (yes, they don't
>> always make it, but that's their goal). We should probably have the
>> same goal. Going from 0 to 2 ULPs would be considered bad.
Generally the goal is 1ULP in round to nearest - other rounding modes may have
On Mon, Oct 22, 2018 at 10:09 PM Jeff Law wrote:
>
> On 10/20/18 9:47 AM, Giuliano Augusto Faulin Belinassi wrote:
> > So I did some further investigation comparing the ULP error.
> >
> > With the formula that Wilco Dijkstra provided, there are cases where
> > the substitution is super precise.
>
On 10/20/18 9:47 AM, Giuliano Augusto Faulin Belinassi wrote:
> So I did some further investigation comparing the ULP error.
>
> With the formula that Wilco Dijkstra provided, there are cases where
> the substitution is super precise.
> With floats:
> with input : =
So I did some further investigation comparing the ULP error.
With the formula that Wilco Dijkstra provided, there are cases where
the substitution is super precise.
With floats:
with input : = 9.9940395355224609375000e-01
sinh: before: =
Hi,
>> Maybe I am crazy, or the labels here are wrong, but that looks like the
>> error is three times as *big* after the patch. I.e. it worsened instead
>> of improving.
This error is actually 1ULP, so just a rounding error. Can't expect any better
than that!
> with input : =
Jakub Jelinek wrote:
> At this point this seems like something that shouldn't be done inline
> anymore, so either we don't do this optimization at all, because the errors
> are far bigger than what is acceptable even for -ffast-math, or we have a
> library function that does the sinh (tanh (x))
> Maybe I am crazy, or the labels here are wrong, but that looks like the
> error is three times as *big* after the patch. I.e. it worsened instead
> of improving.
Oh, sorry. I was not clear in my previous message.
The error did not improved with regard to the original formula. What I
meant is
On Fri, Oct 19, 2018 at 01:39:01PM +, Wilco Dijkstra wrote:
> >> Did you enable FMA? I'd expect 1 - x*x to be accurate with FMA, so the
> >> relative error
> >> should be much better. If there is no FMA, 2*(1-fabs(x)) - (1-fabs(x))^2
> >> should be
> >> more accurate when abs(x)>0.5 and
Hi all,
On Fri, Oct 19, 2018 at 09:21:07AM -0300, Giuliano Augusto Faulin Belinassi
wrote:
> > Did you enable FMA? I'd expect 1 - x*x to be accurate with FMA, so the
> > relative error
> > should be much better. If there is no FMA, 2*(1-fabs(x)) - (1-fabs(x))^2
> > should be
> > more accurate
Hi,
>> Did you enable FMA? I'd expect 1 - x*x to be accurate with FMA, so the
>> relative error
>> should be much better. If there is no FMA, 2*(1-fabs(x)) - (1-fabs(x))^2
>> should be
>> more accurate when abs(x)>0.5 and still much faster.
>
>No, but I will check how to enable it if FMA is
Hello,
> Did you enable FMA? I'd expect 1 - x*x to be accurate with FMA, so the
> relative error
> should be much better. If there is no FMA, 2*(1-fabs(x)) - (1-fabs(x))^2
> should be
> more accurate when abs(x)>0.5 and still much faster.
No, but I will check how to enable it if FMA is
Hi,
> Well, I compared the results before and after the simplifications with a
> 512-bit
> precise mpfr value. Unfortunately, I found that sometimes the error is very
> noticeable :-( .
Did you enable FMA? I'd expect 1 - x*x to be accurate with FMA, so the relative
error
should be much better.
On 10/18, Jeff Law wrote:
> On 10/17/18 4:21 PM, Giuliano Augusto Faulin Belinassi wrote:
> > Oh, please note that the error that I'm talking about is the
> > comparison with the result obtained before and after the
> > simplification. It is possible that the result obtained after the
> >
On 10/17/18 4:21 PM, Giuliano Augusto Faulin Belinassi wrote:
> Oh, please note that the error that I'm talking about is the
> comparison with the result obtained before and after the
> simplification. It is possible that the result obtained after the
> simplification be more precise when compared
Oh, please note that the error that I'm talking about is the
comparison with the result obtained before and after the
simplification. It is possible that the result obtained after the
simplification be more precise when compared to an arbitrary precise
value (example, a 30 digits precise
On 10/17/18 3:25 PM, Giuliano Augusto Faulin Belinassi wrote:
>> Hmm, do we have problems as we get close to -1 or 1 where the outputs of
>> the two forms might diverge?
>
> Well, I did some minor testing with that with input x around nextafter(1, -1);
> There are a minor imprecision when
> Hmm, do we have problems as we get close to -1 or 1 where the outputs of
> the two forms might diverge?
Well, I did some minor testing with that with input x around nextafter(1, -1);
There are a minor imprecision when comparing directly with
sinh(atanh(x)) and cosh(atanh(x)).
* On 32-bits
On 10/12/18 8:36 AM, Giuliano Augusto Faulin Belinassi wrote:
> Hello.
> I don't think there is a need for overflow handling here because
> the argument is bound by the argument of the sqrt function :-)
Yea, I guess you're right. The domain of arctanh is -1 to 1, so I guess
we're safe there.
Hello.
I don't think there is a need for overflow handling here because
the argument is bound by the argument of the sqrt function :-)
Since we have to compute sqrt (1 - x*x), the input is only valid
if 1 - x*x >= 0, implying that -1 <= x <= 1. For any x outside of this
set, the sqrt will
On 8/7/18 2:00 PM, Giuliano Augusto Faulin Belinassi wrote:
> Related with bug 86829, but for hyperbolic trigonometric functions.
> This patch adds substitution rules to both sinh(tanh(x)) -> x / sqrt(1
> - x*x) and cosh(tanh(x)) -> 1 / sqrt(1 - x*x). Notice that the both
> formulas has division
Thanks. Ok, so the expressions you gave are undefined for x==1, which says
that substituting something that is also undefined for x==1 is permitted. You
can argue from "undefined" rather than relying on IEEE features like NaN or
infinite.
paul
> On Aug 8, 2018, at 2:57 PM, Giuliano
Sorry about that. In the e-mail text field I wrote sinh(tanh(x)) and
cosh(tanh(x)) where it was supposed to be sinh(atanh(x)) and
cosh(atanh(x)), thus I am talking about the inverse hyperbolic tangent
function. The patch code and comments are still correct.
On Wed, Aug 8, 2018 at 10:58 AM, Paul
Now I'm puzzled.
I don't see how an infinite would show up in the original expression. I don't
know hyperbolic functions, so I just constructed a small test program, and the
original vs. the substitution you mention are not at all similar.
paul
> On Aug 7, 2018, at 4:42 PM, Giuliano
That is a good question because I didn't know that such targets
exists. Any suggestion?
On Tue, Aug 7, 2018 at 5:29 PM, Paul Koning wrote:
>
>
>> On Aug 7, 2018, at 4:00 PM, Giuliano Augusto Faulin Belinassi
>> wrote:
>>
>> Related with bug 86829, but for hyperbolic trigonometric functions.
> On Aug 7, 2018, at 4:00 PM, Giuliano Augusto Faulin Belinassi
> wrote:
>
> Related with bug 86829, but for hyperbolic trigonometric functions.
> This patch adds substitution rules to both sinh(tanh(x)) -> x / sqrt(1
> - x*x) and cosh(tanh(x)) -> 1 / sqrt(1 - x*x). Notice that the both
>
Related with bug 86829, but for hyperbolic trigonometric functions.
This patch adds substitution rules to both sinh(tanh(x)) -> x / sqrt(1
- x*x) and cosh(tanh(x)) -> 1 / sqrt(1 - x*x). Notice that the both
formulas has division by 0, but it causes no harm because 1/(+0) ->
+infinity, thus the
37 matches
Mail list logo
