Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NaNs Just Don't Get No Respect

drdobbs.com

Post reply on HN
Print view View original

21–30 of 36 posts

Re: NaNs Just Don't Get No Respect

#21

Post by justincormack »

tikhonj wrote: post #8
Evbn wrote: post #7

Earlier quoted context omitted.

Would you prefer NaN be another type, like Maybe? And have to all math in a monad or with chronically repeated case analysis?It's necessary complexity, whichever way you do it.

Oh, I don't really have a good solution in mind--it's just annoying. I guess one option would be to just declare that all NaNs are equal--I'm pretty sure that's how bottoms work in Haskell, and it seems that NaN is essentially a floating-point version of bottom.

There are however multiple bit patterns for NaN which complicates that.

Re: NaNs Just Don't Get No Respect

#22

Post by duaneb »

saurik wrote: post #20

The things this author likes about NaN are also properties of NULL in many environments (that NULL cannot be compared to NULL, that operating on NULL returns NULL, etc.); so while you might not see many languages default initializing things to NaN, you do see them default initializing things to NULL with similar effect.

Except this is actually worse, since there are many possible values which evaluate to NaN.

EDIT: I do not know how D implements NaNs; they may have magic to make them more sane to work with.

Re: NaNs Just Don't Get No Respect

#23

Post by WalterBright »

duaneb wrote: post #22
saurik wrote: post #20

The things this author likes about NaN are also properties of NULL in many environments (that NULL cannot be compared to NULL, that operating on NULL returns NULL, etc.); so while you might not see many languages default initializing things to NaN, you do see them default initializing things to NULL with similar effect.

Except this is actually worse, since there are many possible values which evaluate to NaN. EDIT: I do not know how D implements NaNs; they may have magic to make them more sane to work with.

D does not implement NaNs, it just relies on the IEEE FP hardware to do it.

What D does do is expose NaNs so the programmer can rely on their existence and use them in a straightforward manner.

Re: NaNs Just Don't Get No Respect

#24

Post by tikhonj »

justincormack wrote: post #21
tikhonj wrote: post #8

Earlier quoted context omitted.

Oh, I don't really have a good solution in mind--it's just annoying. I guess one option would be to just declare that all NaNs are equal--I'm pretty sure that's how bottoms work in Haskell, and it seems that NaN is essentially a floating-point version of bottom.

There are however multiple bit patterns for NaN which complicates that.

Yes. I was actually thinking about this. However, you have a similar problem with the current model: two NaNs can have the same bit pattern, but still have to be unequal.

This is somewhat simpler--as long as either argument to (==) is NaN the answer is False. However, you still have to figure out that at least one bit pattern corresponds to NaN. If you want them to be equal, you would have to figure out that both are NaN. This is certainly a little more difficult, but I think it isn't much worse than the current scenario.

Re: NaNs Just Don't Get No Respect

#25

Post by justincormack »

tikhonj wrote: post #24
justincormack wrote: post #21

Earlier quoted context omitted.

There are however multiple bit patterns for NaN which complicates that.

Yes. I was actually thinking about this. However, you have a similar problem with the current model: two NaNs can have the same bit pattern, but still have to be unequal. This is somewhat simpler--as long as either argument to (==) is NaN the answer is False. However, you still have to figure out that at least one bit pattern corresponds to NaN. If you want them to be equal, you would have to figure out that both are…

I think though you currently just subtract them and test equality to zero, so it is all done by the hardware.

Re: NaNs Just Don't Get No Respect

#26

Post by zurn »

malkia wrote: post #14

There are much worse thing than NaN's. They are called denormals. These appear when dealing at the same time with lots of big numbers (very far away from 0) in operations with lots small numbers (close to 0). In such cases the FPU (or whatever deals with fp numbers), switches to a format that could be very inefficient producing an order of magnitude slower operations. For example when dealing with IIR filters in audi…

Denormals are part of IEEE fp. If your implementation is too slow, you can often trade correctness for speed by turning them off in the C/C++ runtimes.

They're also a sign you're skirting on the limits of FP precision (or worse) so a bit of numerical analysis might still be a good idea...

Re: NaNs Just Don't Get No Respect

#27

Post by malkia »

zurn wrote: post #26
malkia wrote: post #14

There are much worse thing than NaN's. They are called denormals. These appear when dealing at the same time with lots of big numbers (very far away from 0) in operations with lots small numbers (close to 0). In such cases the FPU (or whatever deals with fp numbers), switches to a format that could be very inefficient producing an order of magnitude slower operations. For example when dealing with IIR filters in audi…

Denormals are part of IEEE fp. If your implementation is too slow, you can often trade correctness for speed by turning them off in the C/C++ runtimes. They're also a sign you're skirting on the limits of FP precision (or worse) so a bit of numerical analysis might still be a good idea...

You cannot simply turned them off everywhere. On certain platforms they are produced always, and nothing can be done, but openly deal with them (by expecting them to happen).

Re: NaNs Just Don't Get No Respect

#28

Post by joshAg »

shrughes wrote: post #18
noblethrasher wrote: post #17

Earlier quoted context omitted.

He was specifically talking about equivalence on floating point types. Integers don't have or need NaN.

I was talking about integer values (with floating point representation) being multiplied and added (and divided and floored, I suppose).

even just addition and multiplication with floats make simple equivalence a horrible idea, due to uncertainty.

For example:

    float a = 1.0;
    float b = 1000.0;
    for (int i = 0; i
There is no guarantee that a == b. Floats make everything more complicated, even simple addition: http://en.wikipedia.org/wiki/Kahan_summation_algorithm

Re: NaNs Just Don't Get No Respect

#29

Post by joshAg »

shrughes wrote: post #16
joshAg wrote: post #10

Earlier quoted context omitted.

Attmepting to just use simple equivalence with any floating point type a horrible idea to begin with, even without NaNs. You should instead declare equivalence if the absolute difference between the two numbers is less than some bound based on what you're doing and not look for bit equivalency. However, you should be able to examine two NaNs and declare them "equivalent" (for certain definitions of equivalence) by in…

That's not true, there are plenty of cases where using equivalence is just fine. Integer arithmetic, and algorithms that are more reliably written not to contain any empty intervals are two examples.

If you mean arithmetic on floating point numbers that only store integers, then no equivalence is not ok, because there are examples where bit equivalence fails. One example is repeatedly adding 1.0 to a float something like 1 trillion times versus multiplying 1000000.0 by 1000000.0

What do you mean by

    algorithms that are more reliably written not to contain any empty intervals are two examples.

Re: NaNs Just Don't Get No Respect

#30

Post by Evbn »

tikhonj wrote: post #8
Evbn wrote: post #7

Earlier quoted context omitted.

Would you prefer NaN be another type, like Maybe? And have to all math in a monad or with chronically repeated case analysis?It's necessary complexity, whichever way you do it.

Oh, I don't really have a good solution in mind--it's just annoying. I guess one option would be to just declare that all NaNs are equal--I'm pretty sure that's how bottoms work in Haskell, and it seems that NaN is essentially a floating-point version of bottom.

If you try to compare something to bottom (undefined), your program will crash. Try it.
Post reply on HN