floor(0/0) should not be defined

[carette]

floor(0/0) returns some giant negative integer - it should return NaN or undefined.

The bug appears to be in some implementation of 'properFraction' in the standard library.

[from Andrej Bauer, from Barak Pearlmutter (from ???)]

[crutcher]

if decodeFloat (0.0/0.0) was changed to be undefined, then floor would be undefined.

Is there any support for this?

[squadette]

Same thing happens with exponent, significand, scaleFloat, truncate, round, and ceiling.

I believe this patch should fix the problem:

 http://mynd.rinet.ru/~alexm/floor-3070.patch

1. Of course, we get some performance hit, with two ifs for every call to those functions, and the appearance of `undefined' (may it confuse the optimizer somehow?)

However, most of them seem to be not very performance oriented (except maybe for scaleFloat).

2. However, I believe that getting

significand (0/0) = -0.75

is not right, however fast it is.

3. withValidDouble could probably be made a monad of some sort?

4. properFraction should be reindented if this patch is applied. I did not make it to minimize changes.

5. maybe we need a special compiler flag which means "do not bother checking floats for validity, let the user handle details.

Thank you,

[squadette]

Well, it seems like this whole idea of correctness really contradicts some folks' expectations about speed:

 http://hackage.haskell.org/trac/ghc/ticket/2271

 http://hackage.haskell.org/trac/ghc/ticket/1434 ("This is really a problem for me when doing signal processing, since for writing to a common audio file format or listening to a signal data has to be converted from Double to Int16.")

 http://hackage.haskell.org/trac/ghc/ticket/2281

If we add even more specializations for primitive types, what will happen to correctness?

Haskell 98 seems to ignore the question of invalid floating point arguments, however recognizing the existence of NaNs? :)

Maybe we should just explicitly state somewhere that we sacrifice correctness to speed wrt Float <-> Int domain discrepancies.

[squadette]

or, the problem is purely of expectations.

People are used to the fact that evaluating 0/0 gives Division by zero runtime error.

Haskell however is so lazy that it does not bother exiting. Maybe a special command line argument is needed -- terminate on invalid FP operations. This could be useful for beginners, gentle introductions and such.

As for the day-to-day programming we just declare that Double cannot be converted to integral types anyway, so a) invalid operations give NaN, and b) all the functions will give you literal garbage when out of the target range (incl. NaN and Infinity).

AFAIU floating point developers are used to manage evaluation details carefully anyway.

[igloo]

See also #3676

[carette]

I don't think that exact patch is quite the way to go. Actually, I think that decodeFloat should be fixed to throw an exception when encountering NaN or infinities -- that's much more compatible with IEEE 754-2008. Also, there should probably be an isFinite :: Double -> Bool function, which would help guard against 'weird' floats with one check, not two.

[simonpj]

Jacques

We are stalled on this (and I think a couple of other fp-related tickets) because we lack the sophistication in numerical methods to develop the Right Answer, and no consensus has emerged. Would you, and/or others interested in numerical aspects of programming, like to figure out what we should do, make a proposal, and ultimately send us a patch? If it's just left for GHC HQ I fear that nothing may happen.

Simon

[carette]

I can do that - but not before mid-January.

[simonmar]

closed #5683 as a duplicate of this ticket (see more commentary there).

[tristes_tigres]

I've already wrote a few things over at closed as duplicate ticket, and would like to add the comment re the discussion above. It is quite correct that explicit checking for undefined operations like 0.0/0.0 is adversely affecting performance. What is worse, it affects the performance even the vast majority of operations, where NaN would not arise. And that is precisely why NaNs? were introduced - so that you don't have to check for invalid operations, but carry on computations to the conclusion, and if it blew up along the way, you'll see it, and see exaclty what parts were affected, since the result of every operation involving NaNs? is also NaN. The IEEE 754 standard authors even thought of providing a way to indicate the source of NaN - the special bit pattern indicating NaN has some "vacant" range, that an implementation may use to indicate thse source.

In general, it is a real pity that Haskell floating point design is so not thoghtful - it could have been a great tool for numerical analyst. For instance, the big thing that Haskell got wrong is that FP operations are not pure in the sense of being fully determined by their operands. IEEE754 provides for rounding direction flags, and those can be use to check the stability of numerical algorithms experimentally. But how to fit this into Haskell type system - that's pretty fundamental question.

[simonpj]

tristes_tigres, if you had some suggestions for how Haskell's FP design could be made more thoughtful, and more useful for numerical analysts, I think folk would definitely entertain them. People with sercious numerical-analysis expertise in the Haskell community are rare, so if you are such a person we'd gladly listen to you. Don't take the status quo as cast in stone.

Simon

[tristes_tigres]

Re: simonpj

I am not sure that it is appropriate to call my limited knowledge of numerical analysis "serious expertise". But I do have some suggestions, for what it's worth, where Haskell handling of FP could be improved.

To start from the bug under discussion, I think that the suggestions to throw errors on round(0.0/0.0) are somewhat misguided and defeat the purpose of having NaNs? in the first place.

a) Inserting an "if" check will slow down (disrupt processor pipeline) every time round/ceil/floor/etc is called, even though NaNs? may occur in tiny fraction of the cases

b) Throwing exception on encountering NaN may lead to termination of the program, with many possibilities of bad things happening. It is possible that the result of invalid operation may not be actually needed, and occurred in some code left over in production by mistake (see the notorious case of Ariane 5 rocket blowing over FP exception, where precisely this happened). Clearly, this is undesirable outcome.

So how the bug can be corrected properly? By separating rounding and type conversion. It is IMHO a design error to conflate the two. Rounded floating point number is very typically used in further FP computations (I already gave an example - fdlibm sine/cosine functions). So there ought to be something like

ceilingf :: (Real a) => a -> a

floorf :: (Real a) => a -> a

truncatef :: (Real a) => => a -> a

roundf :: (Real a) => => a -> a

The existing round/floor/ceil may be implemented by adding type conversion step (if they should be implemented at all, which I am not sure about, other than for backward compatibility with existing software). It is this step where exception on NaN may be properly raised,as per IEEE 754 sec.7.1

There're possible further improvements to NaN handling beyond fixing this bug, too.

[simonpj]

Thanks. Your suggestions are indeed helpful. What this really needs is someone willing to take up the cudgels and propose, debate, and carry through the "NaN". Are there any numerical analysts who care about this stuff?