octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Removing broadcasting from Octave


From: Juan Pablo Carbajal
Subject: Re: Removing broadcasting from Octave
Date: Wed, 14 Dec 2011 21:55:07 +0100

2011/12/14 John W. Eaton <address@hidden>:
> On 14-Dec-2011, Jordi Gutiérrez Hermoso wrote:
>
> | > But then, what is expected for ...
> | >
> | >        rand (4,4) * (1:4)
> | >
> | >        rand (4,4) .* (1:4)
> | >
> | >        rand (4,4) / (1:4)
> | >
> | >        rand (4,4) ./ (1:4)
> | >
> | > I was thinking that ".<op>" would imply a repmat(), while "op" would
> | > stick to standard matrix operations.
> |
> | Right, if we keep broadcasting and decide to distinguish + and .+, I
> | agree that the latter should broadcast, for consistency with * and .*
> |
> | Actually, I am very much in favour of this, and I suspect it would fix
> | a good deal of broken expectations. From the code I've read, most
> | people do not do .+ except when cargo-culting .* and ./ with the
> | mistaken belief that "all elementwise operations need a dot in front
> | of them". Thus, +, -, *, and / would all consistently perform matrix
> | operations without broadcasting.
>
> And all .+, .-, etc., operations would be overloaded to do either
> element-wise or broadcasting ops?
>
> I don't remember what I suggested earlier, but looking at it now, this
> is the opposite of what I thought we were doing.  So, +1 for the
> confusion factor.c
>
> jwe

I am puzzled also... somehow it comes to my mind "One man's rigor is
another man's mortis" :D

The idea of having an easily deactivated warning when about bsx is
perform is not a bad idea...of course standard code gets  verbose
output :(

On the other hand, is true that one is not forced to use a particular
syntax, but it is clear that in this case when I do .* or * I would
not be able to choose, since the feature will be automatic. IF I
wanted to do a bsxfun I could make it explicit, but if I did not want
to do it...then I cannot avoid doing it and I still see a source of
error there. Moreover, lets say the code is working for me in Octave,
(here comes the "sharing" argument) it may not work in ML. Now, that
is not bad intrinsically, especially if a person or program (without
my supervision) can do the translation (or download Octave). A person
could now Octave as well, but a program will necessarily need to run
the code and check for sizes on the variables to do the translation...
I see that really as a clash. Also I understand that we do not want to
force people to use Octave, since they should be free to use the
language they want to use...

On the other hand we should not hinder development...

I do not know...still puzzled.




-- 
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]