float precision on AMD64

float precision on AMD64

[Mike Lin]

Hi folks,

ints are appropriately wider on AMD64 ocaml, but floats don't seem to
be...max_float and epsilon_float are the same on my 64-bit machine as
on a 32-bit, while max_int is larger. Is this by design?

Re: [Caml-list] float precision on AMD64

[Robert Roessler]

Mike Lin wrote:

> Hi folks,
> 
> ints are appropriately wider on AMD64 ocaml, but floats don't seem to
> be...max_float and epsilon_float are the same on my 64-bit machine as
> on a 32-bit, while max_int is larger. Is this by design?

This is probably because "floats" in standard (32-bit) OCaml are 
already "doubles" (they use IEEE 64-bit floating point representation). :)

Robert Roessler
roessler@rftp.com
http://www.rftp.com

Re: [Caml-list] float precision on AMD64

[sejourne_kevin]

Robert Roessler wrote :
> This is probably because "floats" in standard (32-bit) OCaml are already
> "doubles" (they use IEEE 64-bit floating point representation). :)

So is it possible to have a module of unboxed float with lesser
precision? just like integer.


Kévin.

Re: [Caml-list] float precision on AMD64

[Ville-Pertti Keinonen]

sejourne_kevin wrote:
> So is it possible to have a module of unboxed float with lesser
> precision? just like integer.

Integers aren't boxed but they are tagged.  For floating point, I 
suspect that any reasonably fast way of handling a tag bit would 
interfere with rounding.

Re: [Caml-list] float precision on AMD64

[Ville-Pertti Keinonen]

sejourne_kevin wrote:

> Do you want to say that one small logical operation (' and ' or '
> shift') after the evaluation of an expression ' float ' will be slower
> than the management of it box?

Shifting floats wouldn't make much sense, but you could just clear/set 
the tag bit (it would be the least significant bit of the mantissa). 
However, this would be insufficient if you wanted control over rounding 
(you could only have round-toward-zero).

Of course someone content with losing a bit of precision from the 
mantissa probably wouldn't care too much about rounding.

Re: [Caml-list] float precision on AMD64

[Ville-Pertti Keinonen]

sejourne_kevin wrote:

> The programs who works with floats in 32 bits shall also work with
> floats in 64 bits without one bit from the mantissa, no?

Extra precision does not automatically translate to things just working 
"better", as people have noticed based on the unfortunate x87 design 
choices.  Besides, lots of (most?) programs want full 64-bit floats. 
Certainly OCaml programs would expect them.

> So, what are we waiting for unbox the floats?
> Historical reason(C code wrote that use the box representation of the
> floats) ?

OCaml is already capable of unboxing 64-bit floats when stored in arrays 
or records containing only floats.  By using those, you should get 
reasonable efficiency.

While tagged floats might be a usable solution for some situations, I'm 
sure I wouldn't be the only person unhappy with the situation if they 
were made the default.  In OCaml they'd also be incompatible with 
polymorphic compare; unlike other values with a tagged representation, 
they can't be compared as if they were integers.

Re: [Caml-list] float precision on AMD64

[sejourne_kevin]

Ville-Pertti Keinonen wrote :
> [..] For floating point, I
> suspect that any reasonably fast way of handling a tag bit would
> interfere with rounding.
> 

Do you want to say that one small logical operation (' and ' or '
shift') after the evaluation of an expression ' float ' will be slower
than the management of it box?


Kévin.

Re: [Caml-list] float precision on AMD64

[sejourne_kevin]

Ville-Pertti Keinonen a écrit :
> sejourne_kevin wrote:
> 
>> Do you want to say that one small logical operation (' and ' or '
>> shift') after the evaluation of an expression ' float ' will be slower
>> than the management of it box?
> 
> 
> Shifting floats wouldn't make much sense, but you could just clear/set
> the tag bit (it would be the least significant bit of the mantissa).
> However, this would be insufficient if you wanted control over rounding
> (you could only have round-toward-zero).
> 
> Of course someone content with losing a bit of precision from the
> mantissa probably wouldn't care too much about rounding.
> 

The programs who works with floats in 32 bits shall also work with
floats in 64 bits without one bit from the mantissa, no?

So, what are we waiting for unbox the floats?
Historical reason(C code wrote that use the box representation of the
floats) ?


Kévin.

Re: [Caml-list] float precision on AMD64

[Alan Falloon]

Your arguments against unboxing 64-bit floats are compelling, except one:

Ville-Pertti Keinonen wrote:

> While tagged floats might be a usable solution for some situations, 
> I'm sure I wouldn't be the only person unhappy with the situation if 
> they were made the default.  In OCaml they'd also be incompatible with 
> polymorphic compare; unlike other values with a tagged representation, 
> they can't be compared as if they were integers.

If we assume IEEE floating point format, then they can be compared as 
integers. See the section "Comparing using integers" in

http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm

Although equality comparisons are dangerous, of course.

Re: [Caml-list] float precision on AMD64

[Ville-Pertti Keinonen]

Alan Falloon wrote:

> If we assume IEEE floating point format, then they can be compared as 
> integers. See the section "Comparing using integers" in

> http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm

As the above link notes, since integers on most machines are 
twos-complement and not sign-magnitude, it doesn't work right for 
negative floats.

Working around this isn't possible without knowing it's actually a float 
(in which case a floating point compare could just be used, anyhow).

Re: [Caml-list] float precision on AMD64

[Alan Falloon]

Ville-Pertti Keinonen wrote:

> As the above link notes, since integers on most machines are 
> twos-complement and not sign-magnitude, it doesn't work right for 
> negative floats.
>
> Working around this isn't possible without knowing it's actually a 
> float (in which case a floating point compare could just be used, 
> anyhow).

My mistake. I shouldn't be posting first thing Monday morning.