Talk:Ieee arithmetic - Revision history

Peter gummer at 13:55, 10 February 2010

2010-02-10T13:55:36Z

Clemahieu at 01:59, 10 February 2010

2010-02-10T01:59:47Z

Clemahieu at 01:59, 10 February 2010

2010-02-10T01:59:23Z

Manus at 01:52, 10 February 2010

2010-02-10T01:52:24Z

Peter gummer at 23:54, 9 February 2010

2010-02-09T23:54:35Z

Peter gummer at 23:53, 9 February 2010

2010-02-09T23:53:59Z

Clemahieu at 20:09, 9 February 2010

2010-02-09T20:09:48Z

Peter gummer: Moved signature to the usual location. It looked like Colin's words were written by Manu!

2010-02-06T03:42:00Z

Moved signature to the usual location. It looked like Colin's words were written by Manu!

Colin-adams at 07:41, 5 February 2010

2010-02-05T07:41:28Z

Manus at 20:19, 4 February 2010

2010-02-04T20:19:57Z

@@ Line 41: / Line 41: @@
 :'''--[[User:Clemahieu|Clemahieu]] 20:09, 9 February 2010 (UTC)''': Wouldn't comparing NAN to NAN be a good use of an exception?
-::'''--[[User:Peter gummer|Peter gummer]] 23:53, 9 February 2010 (UTC)''' You mean an exception as in a precondition violation?
+::'''--[[User:Peter gummer|Peter gummer]] 23:53, 9 February 2010 (UTC)''': You mean an exception as in a precondition violation?
 :::'''--[[User:Clemahieu|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.
 :'''--[[User:Manus|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.

@@ Line 43: / Line 43: @@
 ::'''--[[User:Peter gummer|Peter gummer]] 23:53, 9 February 2010 (UTC)''' You mean an exception as in a precondition violation?
-:::'''----''' 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.
+:::'''--[[User:Clemahieu|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.
 :'''--[[User:Manus|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.

← Older revision		Revision as of 01:59, 10 February 2010
Line 42:		Line 42:

	::'''--[[User:Peter gummer\|Peter gummer]] 23:53, 9 February 2010 (UTC)''' You mean an exception as in a precondition violation?		::'''--[[User:Peter gummer\|Peter gummer]] 23:53, 9 February 2010 (UTC)''' You mean an exception as in a precondition violation?
		+
		+	:::'''----''' 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.

	:'''--[[User:Manus\|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.		:'''--[[User:Manus\|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.

← Older revision		Revision as of 01:52, 10 February 2010
Line 42:		Line 42:

	::'''--[[User:Peter gummer\|Peter gummer]] 23:53, 9 February 2010 (UTC)''' You mean an exception as in a precondition violation?		::'''--[[User:Peter gummer\|Peter gummer]] 23:53, 9 February 2010 (UTC)''' You mean an exception as in a precondition violation?
		+
		+	:'''--[[User:Manus\|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.

← Older revision		Revision as of 23:54, 9 February 2010
Line 41:		Line 41:
	:'''--[[User:Clemahieu\|Clemahieu]] 20:09, 9 February 2010 (UTC)''': Wouldn't comparing NAN to NAN be a good use of an exception?		:'''--[[User:Clemahieu\|Clemahieu]] 20:09, 9 February 2010 (UTC)''': Wouldn't comparing NAN to NAN be a good use of an exception?

−	::'''--[[User:Peter gummer\|Peter gummer]] 23:53, 9 February 2010 (UTC) You mean an exception as in a precondition violation?	+	::'''--[[User:Peter gummer\|Peter gummer]] 23:53, 9 February 2010 (UTC)''' You mean an exception as in a precondition violation?

← Older revision		Revision as of 23:53, 9 February 2010
Line 40:		Line 40:

	:'''--[[User:Clemahieu\|Clemahieu]] 20:09, 9 February 2010 (UTC)''': Wouldn't comparing NAN to NAN be a good use of an exception?		:'''--[[User:Clemahieu\|Clemahieu]] 20:09, 9 February 2010 (UTC)''': Wouldn't comparing NAN to NAN be a good use of an exception?
		+
		+	::'''--[[User:Peter gummer\|Peter gummer]] 23:53, 9 February 2010 (UTC) You mean an exception as in a precondition violation?

← Older revision		Revision as of 20:09, 9 February 2010
Line 38:		Line 38:

	You '''have''' to abide by the standard, as that is what the hardware implements. You can't pretend NaNs don't exist.		You '''have''' to abide by the standard, as that is what the hardware implements. You can't pretend NaNs don't exist.
		+
		+	:'''--[[User:Clemahieu\|Clemahieu]] 20:09, 9 February 2010 (UTC)''': Wouldn't comparing NAN to NAN be a good use of an exception?

@@ Line 33: / Line 33: @@
 :'''--[[User:Manus|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.
 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.
---[[User:Colin-adams|Colin-adams]] 07:41, 5 February 2010 (UTC)

← Older revision		Revision as of 07:41, 5 February 2010
Line 32:		Line 32:

	:'''--[[User:Manus\|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.		:'''--[[User:Manus\|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.
		+
		+	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.
		+	--[[User:Colin-adams\|Colin-adams]] 07:41, 5 February 2010 (UTC)

@@ Line 10: / Line 10: @@
 Does it affect the benchmarks?
 :'''--[[User:Manus|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.
-::'''--[[User:Manus|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 I haven't looked at the generated assembly code.
+::'''--[[User:Manus|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.
 '''--[[User:Colin-adams|Colin-adams]] 14:48, 3 February 2010 (UTC)'''