Difference between revisions of "Talk:Ieee arithmetic"

Revision as of 14:53, 9 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?