Bug converting numbers?

Bug converting numbers?

[Markus Mottl]

Hello - Bonjour!

I have encountered unexpected behaviour converting integers to floats:

# let x = 7.;;
val x : float = 7
# let y = float 7;;
val y : float = 7
# x == y;;
- : bool = false

The internal representation of "7." is obviously different to "float 7".
Is there some reason to it? This makes it hard to write things like:

if a_float == float (truncate a_float) ...

if one wants to check whether a float can actually be represented as
an integer...

français:
La représentation de "7." et évidemment differente de "float 7".
Est-ce qu'il y a une raison? C'est un problème si on veut verifier si un
"float" peut être représenté comme "int"...

Regards,
Markus Mottl

-- 
*  Markus Mottl              |  University of Economics and       *
*  Department of Applied     |  Business Administration           *
*  Computer Science          |  Vienna, Austria                   *
*  mottl@miss.wu-wien.ac.at  |  http://miss.wu-wien.ac.at/~mottl  *

Re: Bug converting numbers?

[Pierre Weis]

> Hello - Bonjour!
> 
> I have encountered unexpected behaviour converting integers to floats:
> 
> # let x = 7.;;
> val x : float = 7
> # let y = float 7;;
> val y : float = 7
> # x == y;;
> - : bool = false
> 
> The internal representation of "7." is obviously different to "float 7".
> Is there some reason to it? This makes it hard to write things like:
> 
> if a_float == float (truncate a_float) ...
> 
> if one wants to check whether a float can actually be represented as
> an integer...

For a more exhaustive discussion on this problem, see the Caml FAQ:
<http://caml.inria.fr/FAQ/FAQ_EXPERT-eng.html#egalite>.

The problem here is that you missed the right equality predicate: you
must use = instead of ==. Remember that == means unicity of
representation, not semantical equality of values. For instance:

# "ok" == "ok";;
- : bool = false

"ok" is not the same object as (another) "ok". In contrast, "ok" is
equal to (any other) "ok":

# "ok" = "ok";; 
- : bool = true

So there is no problem of floating point numbers conversion, since the
same (unexpected ?) behaviour still apply if we remove conversions:

# 1.0 == 1.0;;
- : bool = false

(it means that floats may be allocated and then stored in different memory
locations).

Using = your predicate works fine:

let represented_has_an_integer f = f = float (truncate f);;
val represented_has_an_integer : float -> bool = <fun>

And now:

# represented_has_an_integer 7.0;;
- : bool = true

Remember that the == predicate is not for casual uses: you should know
something about value representations in your Caml system to use it
safely. In doubt, use the regular = predicate.

> français:
> La représentation de "7." et évidemment differente de "float 7".
> Est-ce qu'il y a une raison? C'est un problème si on veut verifier si un
> "float" peut être représenté comme "int"...

Pour une discussion plus complète du problème voir
<http://caml.inria.fr/FAQ/FAQ_EXPERT-fra.html#egalite>.

Le comportement que vous observez vient de ce que les flottants sont
des structures de données (généralement) allouées en mémoire. Or vous
utilisez le prédicat == qui teste l'identité physique, au lieu de =
qui teste l'égalité sémantique. Le test == donne alors des résultats
surprenants:

# 1.0 == 1.0;;
- : bool = false

Il suffit d'utiliser = pour que tout rentre dans l'ordre.

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/

Re: Bug converting numbers?

[Markus Mottl]

Hello - Bonjour!

> The problem here is that you missed the right equality predicate: you
> must use = instead of ==. Remember that == means unicity of
> representation, not semantical equality of values. For instance:

> Remember that the == predicate is not for casual uses: you should know
> something about value representations in your Caml system to use it
> safely. In doubt, use the regular = predicate.

Ah, everything clear! Having programmed in other languages lately, where
'==' means semantical equality, I easily read over this bug, although
I knew that there exist two operators for testing semantic equality or
representational identity respectively in Ocaml.

Especially, because:

# 1 == 1;;
- : bool = true

but

# 1.0 == 1.0;;
- : bool = false

This is certainly not, what the casual Ocaml-user expects...

Since there are probably many Ocaml-users who also use languages where
'==' expresses semantic equality (C/C++ is not the only one - e.g. Haskell
also uses this operator), wouldn't it be a good idea to take a different
operator than '==' for checking representational identity? As I had to
realize, such bugs can be really hard to track down. And since this
operator is probably not so often in use in "normal" Ocaml-programs,
it would not really effect too many developers.

Best regards,
Markus Mottl


français:

Beaucoup de programmeurs en Ocaml aussi écrivent aux langues ou '=='
exprime l'égalité sémantique.  Ne serait-il pas une bonne idée de
prendre un operateur différent en place de "==" pour exprimer l'identité
de représentation en Ocaml? Comme je ai du voir, il peut être très
difficile de trouver des erreurs de cette sorte.
Parce-que ce n'est pas un operateur souvant utilisé, je ne crois pas
que ce changement aie un effet fort aux developeurs.

Amicalement,
Markus Mottl

-- 
*  Markus Mottl              |  University of Economics and       *
*  Department of Applied     |  Business Administration           *
*  Computer Science          |  Vienna, Austria                   *
*  mottl@miss.wu-wien.ac.at  |  http://miss.wu-wien.ac.at/~mottl  *