[Matrix-SIG] NumericFix.py

[Pearu Peterson]

Thank you, Andrew Mullhaupt. Yours answer explained me well why my
ideas raised so much oposition from the python people in matrix-sig.
So, I will rest to call my proposals as fixes to python as
the choise is made so many years ago by programmers and I will
respect this because they created this great language.

In conclusion, all that I want is that my computer code will contain
minimal amount of character and information that are not directly related 
to my mathematical problem in hand.
I believe that this is realizable in python and I will certainly
continue to shape the python possibilities to my needs.

With best regards,
     Pearu

Pearu Peterson <pearu@ioc.ee>, MSc, Researcer
Department of Mechanics and Applied Mathematics          http://koer.ioc.ee/~pearu/
Institute of Cybernetics at Tallinn Technical University Phone: (+3722) 527907
Akadeemia rd. 21, 12618 Tallinn ESTONIA                  Fax:   (+372) 6397039

On Mon, 16 Nov 1998, Andrew P. Mullhaupt wrote:

> 
> -----Original Message-----
> From: Konrad Hinsen <hinsen@cnrs-orleans.fr>
> To: pearu@egoist.ioc.ee <pearu@egoist.ioc.ee>
> Cc: matrix-sig@python.org <matrix-sig@python.org>
> Date: Monday, November 16, 1998 11:19 AM
> Subject: Re: [Matrix-SIG] NumericFix.py
> 
> 
> >> The problem is that in order to get sqrt(-1) one has
> >> to write sqrt(-1+0j) which, I think, is quite weird.
> >
> >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.
> 
> 
> The arguments for automatically widening to complex in an interpreted
> language are better.
> 
> The two sensible choices are either a domain error (which is what I get with
> python) or automatic widening, which is better.
> 
> It's not the end of the world that python uses the domain error, though. You
> can get around this with try/except.
> 
> It all boils down to whether you believe the programmer _expects_ the result
> to widen or 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.
> 
> It's definitely advantageous in scientific computing to make the other
> choice, but this is one that would require pervasive modification of python,
> and so we're about ten years too late to do anything about it now.
> 
> The choice that has been made is not catastrophic, although in some cases
> annoying, but shouldn't be reconsidered at this point.
> 
> Later,
> Andrew Mullhaupt
> 
> 
>