In my opinion, variants A and B are a poor man's solution. The problem is in classes REAL_32 and REAL_64. So the fix should be applied in these classes, not in all possible clients of these classes. NaN is breaking Eiffel assertions even in these REAL classes. The invariant "recursive_equality" inherited from ANY is violated. Because of NaN we don't have the total order relation that is promised by the inheritance from COMPARABLE. From example:

    print ({REAL_64}.nan >= 3.0)
    print ({REAL_64}.nan.to_reference >= (3.0).to_reference)

the first one (everything built-in) returns False, the second one (using code inherited from COMPARABLE) returns True.

So I would favor variants C or D. But not only equality should be addressed but also comparison operators. And we should probably add:

    ieee_is_less alias "#<" (other: like Current): BOOLEAN

or something like that (and similar routines for the other comparison operators and equality) for the users who want to get the IEEE semantics.
Of course, this will break existing code. So we need to keep the ECF option, but perhaps change its default value to be True.

Now, between variants C and D, I ran this test:

		local
			s: SPECIAL [REAL_64]
		do
			create s.make_filled ({REAL_64}.nan, 1)
			print (s.is_deep_equal (s))

and it returns True. I guess that `is_deep_equal' uses bit-wise equality in this case. If so, then perhaps variant D should be used.

For the record, the following code:

		f
			local
				r: REAL_64
				s: SPECIAL [REAL_64]
			do
				r := {REAL_64}.nan
				create s.make_filled (r, 1)
				print (r.is_equal (r)); print ("%N")
				print (r.standard_is_equal (r)); print ("%N")
				--print (r.is_deep_equal (r)); print ("%N")
				print (s.is_equal (s)); print ("%N")
				print (s.standard_is_equal (s)); print ("%N")
				print (s.is_deep_equal (s)); print ("%N")
			end

produces:

False
False
True
True
True

REAL_64.is_deep_equal has been commented out because it produces a segmentation violation.

--
Eric Bezault