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

[Bengt Richter]

On 28 Jul 2001 07:39:22 GMT, Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:

>28 Jul 2001 14:49:14 +1200, Paul Foley <see at below> pisze:
>
[...]
>> The handling of exactness is also broken.  Exactness is
>> metainformation, like units.  It's probably wrong to put it in the
Not like units. Units are problem-domain entities relating to
*mathematical values* by associating a meaning with a number valued 1.

Exactness describes the relationship of program/hardware-domain entities
to *mathematical values*. That's totally 'orthogonal' to units.
It's information that is not just associated, but generated by
monitoring the crunching of bit patterns representing numbers.

Most numeric bit patterns are designed to represent one specific
*mathematical value*. To say a numeric bit pattern is exact is
to say that the *mathematical value* it was designed to represent
is exactly the value you intended. The program can't know your
intent, but it can do something useful if you tell it a number
(i.e., its representation's relationship to your intended *mathematical
value*) is exact.

This is a Good Thing to be able to tell the computer, because it
can then track transformations of the representations and tell you
if new patterns still correspond to the *mathematical values*
you would hope for after various operations. Underflow, overflow,
roundoff, all kill exactness, and the computer can tell you. Good Thing.

>> language at all.  It's *certainly* wrong to say integers are always
>> exact and floats always inexact.
>
>Why? It's the most practical approach I know.
>
I think it *seems* practical, like putting galoshes permanently
on a particular pair of shoes, with glue no less ;-)

I suspect an artificial linkage between representation types and
exactness will ultimately restrict freedom to make design choices.

>> If the exactness flag has to carried around externally (e.g., in
>> the programmer's head) anyway, there isn't much point having an
>> inexact concept of exactness in the language.
>
>It doesn't have to be explicit in the language at all. But in practice
>ints and rationals are usually exact, and you should rarely use them
>as inexact, and that floats are inexact, and there is no much need
>to rely on the fact that in some circumstances they can be exact.
>
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

The first is of concern for a programming language. The second is not.

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, and let the computer
tell you when some operation (necessarily on representations) results
in a representation breaking exact relationship to expected *mathematical value*.

It *can* know when it can't represent the exact *mathematical result*
of an operation on exact inputs. That's when the exactness attribute
is set to false. If an input is inexact, the output can't be exact, except
for special cases like multiplying by an exact zero. I suppose dividing
a nonzero number by itself should be an exact one also.

Note that a result bit pattern generally represents *some* *mathematical
value* exactly, just possibly not the right one. If you underflow to zero,
that zero is *inexact* because it does not identify the correct
*mathematical value* of the operation.