A dangerous topic for everyone :-)
I've been working with some unittests involving comparing the output of
different but theoretically equivalent versions of the same calculation. To my
surprise, calculations which I assumed would produce identical output, were
failing equality tests.
It se
On 12/06/2013 05:47 AM, Joseph Rushton Wakeling wrote:
> I decided to check by writing out the whole floating-point
> numbers formatted with %.80f. This confirmed my suspicion that the
> numbers were indeed identical.
Are they identical when printed with %a?
Ali
On 06/12/13 15:02, Ali Çehreli wrote:
Are they identical when printed with %a?
On my 64-bit Linux system, yes. I'll push an updated patch to test and see if
the various 32-bit systems report similar results (I was getting failures on
32-bit Darwin, BSD and Linux).
Thanks very much for the
On 06/12/13 15:02, Ali Çehreli wrote:
Are they identical when printed with %a?
Yes. You can see some of the results here (for the 32-bit systems where I was
getting failures):
https://d.puremagic.com/test-results/pull.ghtml?projectid=1&runid=811923&logid=6
https://d.puremagic.com/test-result
On Friday, 6 December 2013 at 14:58:31 UTC, Joseph Rushton
Wakeling wrote:
On 06/12/13 15:02, Ali Çehreli wrote:
Are they identical when printed with %a?
Yes. You can see some of the results here (for the 32-bit
systems where I was getting failures):
https://d.puremagic.com/test-results/pul
e.g. see this paper
http://software.intel.com/sites/default/files/article/164389/fp-consistency-122712_1.pdf
On Friday, 6 December 2013 at 13:47:12 UTC, Joseph Rushton
Wakeling wrote:
A dangerous topic for everyone :-)
I've been working with some unittests involving comparing the
output of different but theoretically equivalent versions of
the same calculation. To my surprise, calculations which I
On 07/12/13 09:29, Abdulhaq wrote:
Some time ago in a test I had written (C++) apparently identical floating point
operations were returning different answers (in the 17th/18th sign fig), when
re-running the same code with the same data. The paper described how the result
could change if the numb
On 07/12/13 12:08, Joseph Rushton Wakeling wrote:
On 07/12/13 09:29, Abdulhaq wrote:
Some time ago in a test I had written (C++) apparently identical floating point
operations were returning different answers (in the 17th/18th sign fig), when
re-running the same code with the same data. The pape
... I thought I did, but now I'm up against an interesting
conundrum: while equality == comparison can fail here for
32-bit, isIdentical comparison can fail even for 64-bit,
although only for the release-mode build.
What's particularly odd is that if before calling
assert(isIdentical( ...
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 revie
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, technica
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 cach
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)
h
17 matches
Mail list logo
