[Caml-list] floating point input/conversion

[Caml-list] floating point input/conversion

[Stefan Ratschan]

For the functions float_of_string and read_float the OCaml manual is
very vague: "Convert the given string to a float".

In fact, this sentence is wrong. For example, the number 0.1 does not
have a floating point representation, only approximations to it.

So what is the exact specification of these functions? Which number is
taken if the given string does not have a floating point representation?
The nearest one? The nearest one up to 2ulps? Is the current rounding
mode taken into account?

Stefan Ratschan



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] floating point input/conversion

[Olivier Andrieu]

 > Stefan Ratschan [Fri, 22 Oct 2004]:
 > For the functions float_of_string and read_float the OCaml manual is
 > very vague: "Convert the given string to a float".
 > 
 > In fact, this sentence is wrong. For example, the number 0.1 does not
 > have a floating point representation, only approximations to it.
 > 
 > So what is the exact specification of these functions? Which number is
 > taken if the given string does not have a floating point representation?
 > The nearest one? The nearest one up to 2ulps? 

float_of_string basically just calls strtod() from the C library (see
caml_float_of_string in byterun/floats.c). strtod's behaviour is
specified in the C standard, which says:

« the result is either the nearest representable value, or the larger
or smaller representable value immediately adjacent to the nearest
representable value, chosen in an implementation-defined manner. »

So I guess the answer is 'it depends'.

> Is the current rounding mode taken into account?

Probably not because strtod() is supposed to give the same result than
a float constant in the source code.

-- 
   Olivier

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] floating point input/conversion

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

Stefan Ratschan wrote:
> For the functions float_of_string and read_float the OCaml manual is
> very vague: "Convert the given string to a float".
> 
> In fact, this sentence is wrong. For example, the number 0.1 does not
> have a floating point representation, only approximations to it.
> 

Probably worst is the conversion from num to float (Num.float_of_num) 
which goes (or at least used to, I did not check 3.08.1) through
decimal representation as a string and is therefore not in constant time
as it could. This prevents a good implementation of what is called "lazy 
rational number" (you compute a float, but if it is not precise enough, 
then you compute an exact rational number)

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature. The public key is
stored on www.keyserver.net
---------------------------------------------

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Caml-list] floating point input/conversion

[Pierre Weis]

> Stefan Ratschan wrote:
> >For the functions float_of_string and read_float the OCaml manual is
> >very vague: "Convert the given string to a float".
> >
> >In fact, this sentence is wrong. For example, the number 0.1 does not
> >have a floating point representation, only approximations to it.
> >
> 
> Probably worst is the conversion from num to float (Num.float_of_num) 
> which goes (or at least used to, I did not check 3.08.1) through
> decimal representation as a string and is therefore not in constant time
> as it could. This prevents a good implementation of what is called "lazy 
> rational number" (you compute a float, but if it is not precise enough, 
> then you compute an exact rational number)
> 
> -- 
> Christophe Raffalli

If you have a patch to perform the conversion in linear time, we will
be more than happy to incorporate it into the library.

Thanks in advance,

-- 
Pierre Weis

INRIA, Projet Cristal, http://pauillac.inria.fr/~weis

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners