[Python-Dev] RE: [Python-checkins] python/dist/src/Objects complexobject.c,2.57,2.58

[Guido van Rossum]

[Tim]
> Not if you ask me.  Because two mathematically equivalent
> expressions can yield different results when evaluated via computer
> fp arithmetic, it's impossible to guess whether a computed complex
> result "really" has a non-zero imaginary part (indeed, under the
> constructive reals, answering that question is equivalent to solving
> the halting problem -- it's not just the finitude of fp arithmetic
> that's to blame for the uncertainty, and the uncertainty runs deep).

I presume that you also object against allowing certain
"int-requiring" operations (like use as sequence index) on floats when
the fraction is zero.

Unified numbers are rapidly becoming less attractive this way...

> In practical terms, this means the imaginary part of a given complex
> expression can "round to 0", or not, depending on accidents of
> implementation, evaluation order, platform library implementation,
> and fp hardware.  If the language can't define when a complex
> expression is safe to use in a non-complex context, or even
> guarantee that a given fixed complex expression will yield the same
> "is or isn't?" answer across platforms or releases, the best you can
> say about it is "implementation defined -- use at your own risk".
> I'd rather force the issue in my code by explicitly tossing the
> imaginary component.  Note that this implies all numeric types
> should grow .real and .imag attributes (else code can't be generic,
> or has to resort to type checks, or maybe just
> 
>     try:
>         x = x.real
>     except AttributeError:
>         pass
> 
> is good enough).

To me, unified numbers means that there's only one numeric type, and
it always has the same properties.  That means that all numbers must
have an imag field, which is zero when it's not a complex number.

But it seems you want some other indicator that says it's never been
part of a calculation involving complex numbers...

> Another possibility for x-platform x-release consistency is to keep
> and maintain an "exact?" bit with numbers, and barf on a complex
> value with a non-exact 0 imaginary part.  This isn't really useful,
> though, unless e.g.  the exact bit remains set for 24./4. but not
> 24./5. (assuming the inputs are exact), and then carefully defining
> when exactness is and isn't preserved is a major undertaking.

Unified numbers are becoming even less attractive...

> BTW, I'm more a fan of Common Lisp's concessions to numeric reality
> than to Scheme's attempt to wish numeric unpleasantness away.  CL
> generally allows for "upward" conversion by magic, but generally
> never "downward".  So, e.g., CL's divmod equivalent allows int,
> ratio and float arguments, but never complex.  That's a recipe for
> x-platform sanity <wink>.  See
> 
> http://www.math.uio.no/cltl/clm/node121.html#SECTION001600000000000000000
> 
> and especially
> 
> http://www.math.uio.no/cltl/clm/node130.html#SECTION001660000000000000000

Too much to read. :-(

But if the end result is that users will write trunc() or round()
calls whenever they have a float value that they believe is an int and
that they want to use in an int context -- but then when it's not even
close to an int, they won't notice.

Let's call the whole thing off,

--Guido van Rossum (home page: http://www.python.org/~guido/)