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

[Marcin 'Qrczak' Kowalczyk]

Mon, 30 Jul 2001 18:58:48 GMT, Bengt Richter <bokr at accessone.com> pisze:

> 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?

I'm not. Because I don't use float at all when I need exact results,
and I don't care if it happened to be exact in case I don't need
exactness (and used float).

> 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.

I didn't know that. And I never heard of using it. Perhaps it's not
that useful :-)

I don't blame language designers; IMHO it's not worth the complication.

> 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?

If numbers are integers, I use int, not float. It's very rare when
I must use float in order to represent data *and* they can be exact.

>>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."

There is a function which does some computation. We give it data tagged
as exact and the result happens to be tagged as exact. It only tells
us that this particular result is exact; results on different exact
data will not necessarily be exact.

But exactness is usually a static property. Either we need it, because
for example correctness of the computation depends on comparisons
of true mathematical results, or because we want the result to be
independent of the language implementation - or we don't need exactness
and don't care. *We* set up the program in order to preserve exactness
or to run fast and in predictable space (and we can't have both).

If we need exactness, it's too late when the compiler said us that
we didn't get it. If we don't need exactness, we can't easily tell
how much inexact the result really is, so why to make a special
significance to the rare case when it happened to be exact?

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK