[SciPy-dev] In-place operators and casting

[Paul Barrett]

On 11/23/05, Ed Schofield <schofield at ftw.at> wrote:
>
>
> wasn't what he wanted, and he had to spend time figuring out what was
> wrong.  My idea was to turn matrices into something more user-friendly
> than arrays for users migrating from Matlab, R, etc. by redefining
> matrices' in-place operators like += to have the same upcasting behaviour
> as the regular operators like +.  Then this would be possible:
>
>
> >>> b = matrix(zeros(10))
> >>> b
> matrix([[0, 0, 0, 0, 0, 0, 0, 0, 0, 0]])
> >>> b += rand(10)
> >>> b
> matrix([[ 0.80751041,  0.61973329,  0.70726955,  0.94220288,  0.41340826,
>          0.39087675,  0.81454443,  0.25357685,  0.06850165,  0.19652445]])


I've never been on the right side of these discussions, so take my opinion
with a grain of salt.

As you noted, a += b is really just a short hand for a = a + b, so upcasting
makes sense to me. Either way the user really needs to know what he is
doing.  In one case he gets the wrong answer, makes several changes to the
code because he thinks he has made a mistake, and then realizes it is the
lack upcasting. He was hoping to do a quick and dirty calculation and
instead has wasted time with a quirk of the implementation. The other case
is that the user gets the right answer, but it takes too long to execute, so
he realizes that he needs to optimize the code, which he does by making some
small changes.  I have personally experienced such situations and find the
first case the most irritating, so I vote for upcasting.

We might also want to consider how long it took Guido to add in-place
operators to Python, since he did not consider them necessary - at least in
terms of code efficiency.

 -- Paul

--
Paul Barrett, PhD                   Johns Hopkins University
Assoc. Research Scientist     Dept of Physics and Astronomy
Phone: 410-516-5190            Baltimore, MD 21218
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20051124/398aa187/attachment.html>