[Matrix-SIG] NumericFix.py

Tim Peters tim_one@email.msn.com
Tue, 17 Nov 1998 17:31:04 -0500


[pearu@egoist.ioc.ee]
> The problem is that in order to get sqrt(-1) one has
> to write sqrt(-1+0j) which, I think, is quite weird.

[Konrad Hinsen]
> Well, it may be surprising, but it's the outcome of a design
> decision, not a bug. There are good arguments for making the
> functions behave like they do, once you consider that most
> practical applications do not require complex numbers.

[Andrew P. Mullhaupt]
> The arguments for automatically widening to complex in an
> interpreted language are better.

I don't know that it has much to do with interpreting (vs compiling?), but
it has a lot to do with the principle of least surprise across *all* a
language's users.  sqrt in particular is often used in mundane business math
(your basic $5 calculator has a sqrt key for a reason <wink>), and in those
apps sqrt(negative) is always "an error".  The presumption is that Python
users sophisticated enough to know what a complex number is are also
sophisticated enough to do something to get one.

> The two sensible choices are either a domain error (which is what
> I get with python) or automatic widening, which is better.

Better for some users, definitely.

> ...
> It all boils down to whether you believe the programmer _expects_
> the result to widen or not.

Yes, and it's thought that most Python users do not.

> The consistency of this with the rest of the language has a lot to do
> with this expectation. If integer division and floating point division
> share the same syntax (in python they do) then since 3/5 is expected to
> produce 0 and not 0.6 then the dice have already been rolled.

There was quite a firestorm over int/int on c.l.py a few months ago.  This
is a case Guido would change *if he could*, because truncation surprises
many new users of all stripes.  So much so that the Alice (3D graphics for
beginners) project actually changed the semantics of int/int in their
embedded version of Python.  Alas, there's far too much code out there that
relies on truncation now, and even the suggestion that it be changed in the
hypothetical "Python 2" provoked curiously outraged howling.

Nevertheless, if Python 2 ever does come to pass, I bet half of an apple
will finally be better than nothing <wink>.

although-feeding-it-sqrt(negative-apple)-will-still-barf-ly y'rs  - tim