On 08/12/13 09:44, Abdulhaq wrote:
> It's generally held that checking FP numbers for exact equality isn't practical
> and it's better to go for equality within a certain tolerance - any reason why
> you're not happy with that :-)?

Well, 2 reasons -- one was that in the pull request there was a reviewer request to check for exact equality.  The other is that quite obviously these quantities _are_ really equal and can be predictably and reliably checked as such if the quantities concerned are writefln'd to screen before the assert is called.

To give context, you're talking about a comparison of

     (a ^^ 2.0) * 1.0 + 0.0  == a ^^ 2.0

(or, alternatively, the same but using isIdentical).

I'm curious to confirm why placing writefln statements before the isIdentical check should change its behaviour (I assume flushing the FPU cache?) and whether this can be reliably done without writing output to screen.

But yes, you're right, if I get to the end of the day without finding a way to make exact equality comparison work, I will just give up and go back to my original solution of approxEqual.  I'm just hoping to come out of this having learned some new tricks, rather than falling back to the workarounds I already know :-)

On 12/08/2013 01:55 AM, Joseph Rushton Wakeling wrote:

> back to my original solution of approxEqual

I don't know whether it helps here but just to complete the picture, there is also std.math.feqrel:

  http://dlang.org/phobos/std_math.html#.feqrel

Ali

On 08/12/13 12:13, Ali Çehreli wrote:
> I don't know whether it helps here but just to complete the picture, there is
> also std.math.feqrel:
>
>    http://dlang.org/phobos/std_math.html#.feqrel

Thanks! :-)  Checking the value of feqrel followed by isIdentical looks like it might work.  (OK, technically the two are telling you equivalent things, but I'd rather have built-in redundancy of the tests than revert to approxEqual.)

> To give context, you're talking about a comparison of
>
>      (a ^^ 2.0) * 1.0 + 0.0  == a ^^ 2.0
>
> (or, alternatively, the same but using isIdentical).
>
> I'm curious to confirm why placing writefln statements before the isIdentical check should change its behaviour (I assume flushing the FPU cache?) and whether this can be reliably done without writing output to screen.
>

It's an interesting question. If I was attacking this problem I think I'd look at the assembly generated by the compiler, write a little self contained assembly program, and see if I could replicate it. I don't think it's a compiler problem - but what do I know!.

I was tidying up my emails at work and by coincidence I found the original paper that I was referring to, it's very pertinent to this discussion and interesting too,

The pitfalls of verifying floating-point computations
David Monniaux (LIENS, Verimag - Imag)

http://arxiv.org/abs/cs/0701192

On 07/12/13 11:52, John Colvin wrote:
> I'm pretty sure D is free to do this, it goes with the whole
> more-precision-is-better-precision philosophy.

I'm not complaining about better precision, I just want my equality comparisons to be predictable -- arguably a losing cause :-)

On 09/12/13 12:43, Abdulhaq wrote:
> I was tidying up my emails at work and by coincidence I found the original paper
> that I was referring to, it's very pertinent to this discussion and interesting
> too,
>
> The pitfalls of verifying floating-point computations
> David Monniaux (LIENS, Verimag - Imag)
>
> http://arxiv.org/abs/cs/0701192

Thank you very much!  That's very useful.

I managed to find a way to not trigger equality or isIdentical failures, just by calling std.math.feqrel on the quantities first (and comparing its result to double.mant_dig).  I guess this is also a case of taking the variables off the FPU; I'm not experienced enough with assembly to be confident taking the program apart and analysing it that way.