Not a Number - Revision history

Manus: Added category

2007-05-30T18:29:11Z

Added category

Colin-adams: Added not about equality_operator in postconditions

2007-05-15T15:42:58Z

Added not about equality_operator in postconditions

Paulb: Fixed code markup

2007-05-08T16:37:52Z

Fixed code markup

Colin-adams at 15:28, 8 May 2007

2007-05-08T15:28:13Z

New page

If you are writing programs in an environment where NaNs (Not-a-Number) crop up a lot, as I am, then turning on assertion checking beyond require level is not, in general, practical. The problem is not performance, but the fact that no NaN compares equal to any number, including itself. And for good reason.

So when you encounter a postcondition such as this from class <eiffel>ARRAY</eiffel>:

<eiffel>
put (v: like item; i: INTEGER_32)
-- Replace `i'-th entry, if in index interval, by `v'.
require -- from TABLE
valid_key: valid_index (i)
require -- from TO_SPECIAL
valid_index: valid_index (i)
do
area.put (v, i - lower)
ensure then -- from INDEXABLE
insertion_done: item (i) = v
ensure -- from TO_SPECIAL
inserted: item (i) = v
end
</eiffel>

you will get a violation if <eiffel>item</eiffel> is of type <eiffel>REAL_64</eiffel> (for instance), and <eiffel>v</eiffel> is a NaN.

And such postconditions are pervasive.

This is a serious difficulty with Eiffel at the moment. So I am putting forward the following proposal as a starter to kick off a community discussion.

The essence of my proposal is to add a routine named <eiffel>is_numerically_equal (a_other: NUMERIC): BOOLEAN<eiffel> to class <eiffel>NUMERIC</eiffel>.

This will differ from <eiffel>is_equal</eiffel> in that if either operand is a NaN, then the result is guaranteed to be False. Whereas <eiffel>is_equal</eiffel> will return True if ''both'' operands are NaNs.

Now it is important that the <eiffel>=</eiffel> operator can continue to be used in the traditional mathmatical sense for numbers. So it will have to differ in its definition for class <eiffel>NUMERIC</eiffel> from all other classes.

← Older revision		Revision as of 18:29, 30 May 2007
Line 1:		Line 1:
		+	[[Category:ECMA]]
	If you are writing programs in an environment where NaNs (Not-a-Number) crop up a lot, as I am, then turning on assertion checking beyond require level is not, in general, practical. The problem is not performance, but the fact that no NaN compares equal to any number, including itself. And for good reason.		If you are writing programs in an environment where NaNs (Not-a-Number) crop up a lot, as I am, then turning on assertion checking beyond require level is not, in general, practical. The problem is not performance, but the fact that no NaN compares equal to any number, including itself. And for good reason.

← Older revision		Revision as of 15:42, 15 May 2007
Line 29:		Line 29:
	This will differ from <eiffel>is_equal</eiffel> in that if either operand is a NaN, then the result is guaranteed to be False. Whereas <eiffel>is_equal</eiffel> will return True if ''both'' operands are NaNs.		This will differ from <eiffel>is_equal</eiffel> in that if either operand is a NaN, then the result is guaranteed to be False. Whereas <eiffel>is_equal</eiffel> will return True if ''both'' operands are NaNs.

−	Now it is important that the <eiffel>=</eiffel> operator can continue to be used in the traditional mathmatical sense for numbers. So it will have to differ in its definition for class <eiffel>NUMERIC</eiffel> from all other classes.	+	Now it is important that the <eiffel>=</eiffel> operator can continue to be used in the traditional mathmatical sense for numbers. So it will have to differ in its definition for class <eiffel>NUMERIC</eiffel> from all other classes. This will be a language change, since ECMA states that = uses is_equal.
		+
		+	This means that postcondition like:
		+
		+	<eiffel>insertion_done: item (i) = v</eiffel>
		+
		+	from <eiffel>INDEXABLE</eiffel> need to be re-written to use <eiffel>~</eiffel>.

@@ Line 25: / Line 25: @@
 This is a serious difficulty with Eiffel at the moment. So I am putting forward the following proposal as a starter to kick off a community discussion.
-The essence of my proposal is to add a routine named <eiffel>is_numerically_equal (a_other: NUMERIC): BOOLEAN<eiffel> to class <eiffel>NUMERIC</eiffel>.
+The essence of my proposal is to add a routine named <eiffel>is_numerically_equal (a_other: NUMERIC): BOOLEAN</eiffel> to class <eiffel>NUMERIC</eiffel>.
 This will differ from <eiffel>is_equal</eiffel> in that if either operand is a NaN, then the result is guaranteed to be False. Whereas <eiffel>is_equal</eiffel> will return True if ''both'' operands are NaNs.
 Now it is important that the <eiffel>=</eiffel> operator can continue to be used in the traditional mathmatical sense for numbers. So it will have to differ in its definition for class <eiffel>NUMERIC</eiffel> from all other classes.