Difference between revisions of "Talk:Ieee arithmetic"

Latest revision as of 05:55, 10 February 2010

--Alexander Kogtenkov 3 February 2010 (UTC) Most probably C compilers inline functions, but just to be sure, I'd convert them into the macros:

#define to_raw_bits(d) *((EIF_NATURAL_64*)&(d))
 
#define eif_is_nan_bits(value) ((value & ~RTU64C(0x8000000000000000)) > RTU64C(0x7ff0000000000000))
 
#define eif_is_nan(v) ((*((EIF_NATURAL_64 *)&(v)) & ~RTU64C(0x8000000000000000)) > RTU64C(0x7ff0000000000000))

Does it affect the benchmarks?

--manus 17:59, 3 February 2010 (UTC) Actually it does not on Windows for sure, I've verified that it was inlined. But you are right that those could be simply defined as macros.

--manus 20:25, 3 February 2010 (UTC) I've done again some of the benchmarks and on windows at least, some of them are slower when I use a macro. I'm no sure why as I haven't looked at the generated assembly code.

--Colin-adams 14:48, 3 February 2010 (UTC) Not IEEE arithmetic, nor maths, NaN = NaN is never true. And placing NaNs in a sort order isn't write either - REAL_32/64 are not totally ordered types.

--manus 17:57, 3 February 2010 (UTC) How do you solve the problem of assertions then in ARRAY.put for example?

--Alexander Kogtenkov 20:01, 3 February 2010 (UTC)

• Does it mean that REAL_GENERAL should inherit PART_COMPARABLE rather than COMPARABLE?
• Do we need 2 equality queries: one that tells two objects represent the same value (it is used to ensure copy does what is expected, and it is used to implement ~) and the other one that tells that the numbers are equal in terms of ordering relation of (PART_)COMPARABLE?

--Colin-adams 12:37, 4 February 2010 (UTC): Postcondition for {ARRAY}.put should read:

inserted: v = v  implies (item (i) = v)
undefined_case: v /= V implies (item (i) /= item (1))

--manus 19:50, 4 February 2010 (UTC): I'm sure you realize that this is not feasible as there are so many of those assertions in actual Eiffel code.

--Colin-adams 12:42, 4 February 2010 (UTC): I have previously suggested separating the notion of numerical equality and object equality. Eric said that we use = for three different notions, i think, but I don't remember what these were. Certainly PART_COMPARABLE is better than COMPARABLE for IEEE math types. I'm not sure if that is sufficient or not.

--manus 19:50, 4 February 2010 (UTC): The question is not whether or not we adhere to a standard. The question is if that standard makes sense in Eiffel. And clearly it does not. It breaks too much of the good assumption we have been making about equality. In absence of conversion which is pure syntactic sugare, the following is a fundamental aspect of Eiffel: x := y implies x = y.

--Colin-adams 07:41, 5 February 2010 (UTC) I advocate changing all postconditions to that form where necessary. it is perfectly reasonable thing to do. The current situation means it is not possible to turn postcondition checking on routinely. This is very bad for Design by Contract in practice. I suffer from this every day at work.

You have to abide by the standard, as that is what the hardware implements. You can't pretend NaNs don't exist.

--Clemahieu 20:09, 9 February 2010 (UTC): Wouldn't comparing NAN to NAN be a good use of an exception?

--Peter gummer 23:53, 9 February 2010 (UTC): You mean an exception as in a precondition violation?

--Clemahieu 01:59, 10 February 2010 (UTC) I was thinking more like divide-by-zero but a "NAN comparison" exception. This would essentially mean a NAN shouldn't be assigned. Like if a C function returned >= 0 for success and equality and various < 0 for errors, how do you compare equality in the error region? Well you don't, it's an error; we use exceptions in Eiffel for errors.

--manus 01:52, 10 February 2010 (UTC): I was not around in the discussion from 20 years ago regarding NaN, but reading some reasoning for NaN in the context of scientific computation it is clear that they wanted the value NaN to throw an exception whenever NaN was used in an operation because correctness of the computation was important. Over the years, it was transformed into the missing value paradigm (you put NaN when you actually don't know, and if you do some computation and get NaN, then it means that you don't know the result of the computation). Both approaches are interesting and it all depends on the kind of applications you are creating.

--Peter gummer 13:55, 10 February 2010 (UTC): Bertrand Meyer discusses this on his blog http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/ : "There is, by the way, a technique that accepts booleans as we love them ... and achieves mathematical rigor. If operations involving NaNs truly give us pimples, we can make any such operation trigger an exception. ... The downside, of course, is that just about everywhere the program must be ready to handle the exception in some way. It is unlikely that in practice many people would be comfortable with such a solution."