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

Guido van Rossum guido@python.org
Mon, 15 Apr 2002 18:19:23 -0400

[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 . 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/)