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

[eric]

> Yikes.  That little operation is a bit nasty for me.  Explanation: in S (and
hence in R, the stat languages that I referred to a while back),
> ~ is the "model building" operator, i.e. "y ~ x" refers to "y = x + e", where
> e is the associated error term (go back to linear models or regression, if you
will)_.  I'd like to extend SciPy to use this language at some point, and direct
would be better than having to quote it (but that's probably where we will end
up).

I can't see how you'll get around quoting things really.  I can imagine adding
this to weave though.  Something like a weave.r('y ~ x') or something like that.
I don't know if any of the machinery there is helpful for this or not, but it
does fit into the overall goals of the weave package (mixing other languages
into Python).

>
> I rarely need conjugation, but readily acknowledge that other computational
areas really need that feature.

Yep.  I guess Travis' main point here is that conjugation is used a whole lot
more than bitwise inversion in the scientific/engineering computing worlds and
it would be a better use of the symbol.  A quick search of the entire standard
library for ~ as bitwise inversion turned up about 8 occurrences.  conjugate()
shows up that many times in scipy alone, and we're not near finished with it.
We'll make do with conj() though. :-)

eric

>
> best,
> -tony
>
>
>
> On Tue, 26 Feb 2002, eric wrote:
>
> >
> >
> > > On Sunday 24 February 2002 01:24 am, you wrote:
> > > > I finally realized that with a simple change we can use the unary
operator
> > > > on floats and complex numbers to mean complex conjugation.
> > > >
> > > > I've made the simple change in the CVS version of fastumath.
> > > >
> > > > So, in scipy complex-conjugation is as simple as
> > > >
> > > > ~a
> > > >
> > > > if a is a complex number (or a float).
> > > >
> > > > The only problem is that if a is an integer it still means bitwise
> > > > inversion.
> > > >
> > > > Is the added convenience worth the possible confusion?  The problem is
that
> > > > complex conjugation happens all the time, but bitwise inversion rarely.
> > >
> > > So, what if we made ~ consistently complex conjugation and eliminated the
> > > confusion.  The invert would still be available as a function call.
> > >
> > > We could also make changes to any of the other symbols as well while we
are
> > > at it if the demand is there.  We can do this without making any changes
to
> > > Numeric as well.
> > >
> > > Let me know.  If no one likes the idea but likes writing
conjugate(myarray)
> > > everywhere then I'll back out the changes.
> >
> >
> > 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:
> >
> >
> >     >>> def conj_test(a,b):
> >     ...    return ~a + ~b
> >     ...
> >
> >     # Try it with two integers
> >     >>> conj_test(1,1)
> >     -4
> >
> >     # Now with two complex values
> >     >>> conj_test(1+0j,1+0j)
> >     Traceback (most recent call last):
> >       File "<stdin>", line 1, in ?
> >       File "<stdin>", line 2, in conj_test
> >     TypeError: bad operand type for unary ~
> >
> >     # now try an array -- this produces the results we want
> >     >>> a=array((1+0j))
> >     >>> conj_test(a,a)
> >     (2+0j)
> >
> >     # but mixing an array with an integer returns bogus results
> >     >>> conj_test(a,1)
> >     (-1+0j)
> >
> >     # and mixing with a scalar complex fails.
> >     >>> conj_test(a,1+0j)
> >     Traceback (most recent call last):
> >       File "<stdin>", line 1, in ?
> >       File "<stdin>", line 2, in conj_test
> >     TypeError: bad operand type for unary ~
> >
> > It might be possible to overload the ~ operator in Python2.2 for complex
values
> > so that it worked correctly (I haven't looked into the new type/class stuff
> > much), but if we did, it is effectively a language change to Python.  In the
> > complex number arena, I don't think it would break much code, but it does
have
> > that potential.  We need to think long and hard about such decisions and
would
> > do better to lobby Guido et al. about such a change (I sorely want a __cmp__
for
> > complex numbers to work with some default behavior).
> >
> > But even if we got it fixed for complex scalars, the fact that
conj_test(1,1)
> > would return completely different results than conj_test(1+0j,1+0j) is a
show
> > stopper to me.  I'd be all for ~ universally meaning conjugate, but its been
in
> > the language for to long for this to happen.
> >
> > Could we shorten the name to conj()?  Its not as good as ~, but it does cut
down
> > on typing and is obvious to those who would use it.
> >
> > eric
> >
> >
> >
> >
> > _______________________________________________
> > Scipy-dev mailing list
> > Scipy-dev at scipy.net
> > http://www.scipy.net/mailman/listinfo/scipy-dev
> >
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev
>