[m-dev.] [m-users.] Comparison in the reference manual

[Julien Fischer]

Hi Mark,

On Mon, 23 Nov 2015, Mark Brown wrote:

>> Not-a-number (NaN) values complicate matters.  The current implementation of
>> builtin.compare/3 is broken, for example the following evaluates to true:
>>
>>     NaN = 0.0 * infinity,
>>     compare((=), NaN, 0.0)
>>
>> but:
>>
>>     NaN = 0.0 * infinity,
>>     unify(NaN, 0.0)
>>
>> evaluates to false.
>>
>> The IEEE 754-2008 standard (section 5.10) defines a total ordering on float
>> values, but I don't think that will work for us.  Java's Double.CompareTo
>> method treats NaN values as equal to themselves and greater than all other
>> float values (including +infinity), mainly so that you can use them in data
>> structures.  IIRC, C# does something similar.
>>
>> My inclination is that we should simply make builtin.compare/3 throw an
>> exception for NaN values on the basis that they are not ordered w.r.t other
>> float values (or indeed themselves).
>
> Fine by me.

The handling of NaN values in Mercury is spectacularly broken at the moment,
but that's another matter.

>> For completeness, you should say something about strings here too (e.g.
>> what's currently in the comment at the head of the string module.)
>
> Done.
>
> Additional diff is attached. I'll commit the change soon if there are
> no further comments.

...

> diff --git a/doc/reference_manual.texi b/doc/reference_manual.texi
> index 64a72e3..ba43b40 100644
> --- a/doc/reference_manual.texi
> +++ b/doc/reference_manual.texi
> @@ -2543,20 +2543,32 @@ As such, the standard ordering for most types is not fully defined.
>
>  For the builtin type @code{int},
>  the standard ordering is the usual numerical ordering.
> -Implementations are permitted to give inconsistent results
> -for overflowing literals.
> +Implementations should reject code containing overflowing integer literals.
>
>  For the builtin type @code{float},
>  the standard ordering approximates the usual numerical ordering.
>  If the result of @code{builtin.compare/3} is @code{(<)} or @code{(>)}
>  then this relation holds in the numerical ordering,
>  but this is not necessarily the case for @code{(=)} due to lack of precision.
> -Implementations are permitted to give inconsistent results
> -for overflowing literals.
> +In the standard ordering, ``negative'' and ``positive'' zero values are equal.
> +Implementations should replace overflowing literals
> +with the infinity of the same sign;
> +in the standard ordering positive infinity is greater than all finite values
> +and negative infinity is less than all finite values.
> +Implementations must throw an exception when comparing
> +a ``not a number'' (NaN) value.
>
>  For the builtin type @code{char}, the standard ordering is
>  the numerical ordering of the Unicode code point values.
> 
> +For the builtin type @code{string},
> +the standard ordering is implementation dependent.
> +The current implementation performs string comparison using
> +the C @code{strcmp()} function,
> +the Java @code{String.compareTo()} method, and
> +the C# @code{System.String.CompareOrdinal()} method,
> +when compiling to C, Java and C#, respectively.

That list (and for that matter the library module) omit the Erlang backend.

It's probably also worth note that the implementation is not required to
normalize strings before comparing them.

Julien.