proposed language change to int/int==float (was: PEP0238 lament)

[Bengt Richter]

On 30 Jul 2001 06:09:11 GMT, Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:

>Mon, 30 Jul 2001 04:52:53 GMT, Bengt Richter <bokr at accessone.com> pisze:
>
>> I think several notions of exactness are getting mixed.
>> 
>> Two relationships need to be separated:
>> 1. bit pattern representing a number <-> *mathematical value*
>> 2. *mathematical value* <-> significance in problem domain
>
>I disagree. The only interesting relationship is
>  number which can be represented in a bit pattern <->
>  significance in problem domain.
>
Then you are not interested in whether a bit pattern transformation
that implements a mathematical operation results in a bit pattern
that exactly represents the infinite precision mathematical result?

>The number represented can differ much from the number intended
>because some operations (e.g. subtraction of positive numbers) may
>make the result very inexact.
The key to thinking about this is to differentiate very carefully
between abstract numbers and their various representations. And between
mathematical operations and corresponding operations on representations.

>
>Which mathematical value are you talking about? The one represented
>by the bit pattern or the one which would be used if arithmetic was
>exact (assuming that it's a rational number at all)? In any case it
>boils down to the above relationship.
I was taking about all of the above, trying to clarify their relationships.

>
>> Exactness has to do with the first relationship. A particular bit
>> pattern representing a number uniquely identifies its corresponding
>> *mathematical value* by design. If the *mathematical value* is exactly
>> what you want, declare the representation exact,
>
>It's not useful to tag exact float values. Exactness depends on
The designers of the fp hardware apparently thought it was useful.
They supply a hardware status bit for that purpose, and automatically
re-tag to inexact when an operation causes that. Blame language designers
and compiler writers, not floating point hardware.

>artificial conditions. Operations on them don't always produce exact
>results.
Right, and the hardware knows when that happens. What do you mean by
artificial conditions? E.g., the double format can handle anything the
int (32 bit) format can handle exactly, and more. Would those be
artificial? 

>
>In effect sometimes by accident you might get an exact result, but
>it's not guaranteed that the same computation of different data will
>give an exact result. It's better to statically known that results
>of a computation are not exact in general.
I'm not sure what you mean by "the same computation of different data."

>
>If you want exact results, simply don't use floats. If you don't
>need exactness and know that the algorithm behaves well numerically,
>use floats for speed. I don't see the point in the compiler inferring
>whether it managed to get a particular result exact or not.
It doesn't have to infer. It can check a status bit, if the ieee754
hardware is used right.

>
>Not to mention that it's inefficient to check whether operations on
>floats preserved exactness, so you hurt those who don't need exactness.
>
How many nanoseconds are you willing to spend on it per expression that
involves floating point? The IEE754 implementation on pentiums has a
status bit that you can clear at the beginning and look at at the end.

The trouble is, you have to write a few lines of assembly to do that,
because AFAIK it's not accessible in standard C libraries. I don't know
if compilers benignly ignore it, or gratuitously clear the status sometimes.
It's a "sticky" bit, so if they ignore it, it should be possible to make
some functions that set and query it from the Python C number implementation,
at least on intel pcs. One clear and query per assignment involving fp should
do it.

There really shouldn't be that much floating point implementation code in
the interpreter or VM. I wonder what it would take to rewrite it to take
real advantage of IEEE754. That would be a real Python distinction.