[mercury-users] IEEE float (was: Newbie problem)

[Fergus Henderson]

On 22-Jun-1999, Richard A. O'Keefe <ok at atlas.otago.ac.nz> wrote:
> If I may summaries Fergus Henderson's reply, at the risk of caricature:
> 1. Mercury's floating point arithmetic is *deliberately* **NOT**
>    IEEE-compatible, even on platforms that claim (not always rightly)
>    to offer IEEE support.
> 2. the major reason for this is the counter-intuitive behaviour of
>    IEEE arithmetic [...]
> 3. syntactically heavyweight (but probably operationally lightweight)
>    support for IEEE arithmetic as a *separate* datatype is planned
> 4. this is acceptable because most programmers don't understand IEEE
>    arithmetic anyway.

Hopefully the support for IEEE arithmetic will not need be syntactically
heavyweight.  But apart from that, yes, that is a reasonable summary.

> Let's address the main points.
> 
> 1.  The questions "is this intuitive" and "is this easy to reason about"
>     are different.  I thought Mercury was intended to be a programming
>     language for serious software engineering.  For that, we can tolerate
>     a certain amount of unintuitiveness *provided* that it pays off in
>     ease of reasoning, leading to more reliable code.
[...]
> 2.  Floating point is unintuitive no matter *what* you do to it.
[...]
> 3.  Some IEEE support is better than none.
> 
> 4.  I don't buy "programmers are not IEEE 754 experts" as an argument
>     either.  
[...]
> One thing that the Quintus people learned the hard way (starting from
> C Prolog experence) was that plugging in your own ad hoc floating point
> model is deservedly unpopular with paying customers, who want to pass
> reasonable data safely through the foreign interface in both directions
> and who *don't* want what is essentially the same expression giving
> different results in C++ and Prolog/Mercury/whatever.  Having to deal
> with two models makes life *harder* for them, not easier.

These arguments are reasonably persuasive, particularly the interoperability
issue.  You have convinced me that at very least we should not do anything
to the current implementation of `float' in Mercury that could cause
interoperability problems without first adding an alternative that
does work interoperably and that supports IEEE on appropriate platforms.

I still think it would be a good idea for Mercury to have a floating
point type that has a more intuitive semantics than IEEE float, as well
as supporting standard IEEE float for interoperability reasons.
However, on the issue of which one should be called `float',
I'm now undecided.

Perhaps if I want a more intuitive floating point type then I should try
to get it included in C++ and Haskell first and _then_ add it to Mercury ;-)

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------