[SciPy-dev] New in fastumath ~ (means conjugate on floats and complex numbers)

Fernando Perez fperez at pizero.colorado.edu
Tue Feb 26 16:37:41 EST 2002


On Tue, 26 Feb 2002, eric wrote:

> I'm not so fond of conjugate(myarray) and would rather use ~ also, but I can't
> see a safe way to do it in numerical code without changing Python itself.  My
> view is that numerical operations should work with similar behavior on both
> arrays and scalars and should produce un-ambiguous results.  I also do not think
> we should make any changes that affect standard Python code (I don't mind
> changes to Numeric's behavior though when it is appropriate).  The following set
> of examples illustrates the problems of mixing types, etc:

[snipped]

I think Eric's tests very nicely summarize the problem, and point exactly at
the 'nightmare bug' scenarios I mentioned in my earlier post, which were only
vaguely defined in my mind at the moment.

I would *love* to see a single-symbol operator for complex conjugation (and
form matrix transposition, and for expression differentiation --thinking of
symbolic extensions in the future :). But unfortunately it seems to create a
heinous minefield of tricky problems.

I'd suggest for the time being aliasing conj=conjugate (or even cnj) and
perhaps lobbying Guido for, _in the future_ allowing overloading of new
symbols in the language.

My problem with the ~ business is that it introduces very strict
type-dependencies in a language which is by design, philosophy and usage very
flexible in its handling of types. The 'pythonic' way seems to be: try and
operate on things, and either the right thing should happen or an exception
should be raised. But the ~ overloading introduces a situation where things
give _silent_ incorrect results, which to me is the worst of all possible
outcomes. 

One thing I love about python is that either things work, or I'm explicitly
told when they don't (in most cases). I really would hate to see silent modes
of failure introduced by us.

Just my 0.02,

f




More information about the SciPy-Dev mailing list