On ARM, it turns out that comparisons with NaN can be made to do the
right thing with no code penalty, by a more careful selection of
condition code values in the subsequent conditional branch. The
meaning of the CC bits in the PSR is subtly different when they've
been copied from the floating
it would be reasonable to try to follow the standard, unless it's stupid,
ill-advised, or impossible (or all three).
Not impossible, maybe a bit tricky to stop the linkers from reordering
things. The cost would be (at least) one extra instruction for each
'if' statement with a floating point
it would be reasonable to try to follow the standard, unless it's stupid,
ill-advised, or impossible (or all three).
I was a little ambiguous. I meant that statement in general, but I in the
particular case of floating-point, being fundamental, probably should work
as now defined,
and I
The Plan 9 C compilers do not appear to be compliant with the IEEE floating
point standard when making comparisons with NaN (not a number) values.
The standard says a comparison with one or both operands NaN is unordered,
ie all relations evaluate to false, except != which is always true.
amd64 does yet something else.
amd64 (a == b) (a = b) (a b) (b == a) (b = a) (b a)
386 (a b) (a = b) (a == b) (b a) (b = a) (b == a)
arm (a b) (a = b) (a != b) (b a) (b = a) (b != a)
mips(a b) (a = b) (a != b) (b a) (b = a) (b != a)
mainly the assumption, in the compiler
how about another option, just a bug.
what i mean is, the need for fixing it depends on how much
havoc this issue causes.
- erik
at least in terms of passing floating point test suites
(like python's) the NaN issue doesn't come up
Actually it was a test suite that revealed the NaN errors.
I wouldn't think it's something anyone needs in normal
day-to-day computation, but sometimes boxes must be ticked.
On Wed Aug 21 12:09:26 EDT 2013, 9f...@hamnavoe.com wrote:
at least in terms of passing floating point test suites
(like python's) the NaN issue doesn't come up
Actually it was a test suite that revealed the NaN errors.
I wouldn't think it's something anyone needs in normal
day-to-day
On Aug 21, 2013, at 9:55 AM, erik quanstrom quans...@quanstro.net wrote:
On Wed Aug 21 12:09:26 EDT 2013, 9f...@hamnavoe.com wrote:
at least in terms of passing floating point test suites
(like python's) the NaN issue doesn't come up
Actually it was a test suite that revealed the NaN
On Wed Aug 21 13:43:54 EDT 2013, ba...@bitblocks.com wrote:
On Aug 21, 2013, at 9:55 AM, erik quanstrom quans...@quanstro.net wrote:
On Wed Aug 21 12:09:26 EDT 2013, 9f...@hamnavoe.com wrote:
at least in terms of passing floating point test suites
(like python's) the NaN issue doesn't
On Wed Aug 21 13:43:54 EDT 2013, ba...@bitblocks.com wrote:
On Aug 21, 2013, at 9:55 AM, erik quanstrom quans...@quanstro.net wrote:
On Wed Aug 21 12:09:26 EDT 2013, 9f...@hamnavoe.com wrote:
Actually it was a test suite that revealed the NaN errors.
I wouldn't think it's something anyone
by this i ment to refer to -0.
But the subject line says comparisons with NaN. Start another
thread about signed zero if you like. (I'm not facing a test
suite objecting to those at the moment.)
what i mean is, the need for fixing it depends on how much
havoc this issue causes.
Well, there is also the question of whether anything at all will break
if the bug is fixed. If not, then the answer is simple.
++L
I think that if there is a generally-accepted standard for the behaviour of
a language's handling of floating-point numbers,
it would be reasonable to try to follow the standard, unless it's stupid,
ill-advised, or impossible (or all three).
That reply to the Stack Overflow post -- and this might
On Wed Aug 21 14:23:48 EDT 2013, lu...@proxima.alt.za wrote:
what i mean is, the need for fixing it depends on how much
havoc this issue causes.
Well, there is also the question of whether anything at all will break
if the bug is fixed. If not, then the answer is simple.
fortunately,
15 matches
Mail list logo
