Re: varargout{:} = func() ?

[Jaroslav Hajek]

On Wed, Feb 24, 2010 at 4:21 PM, Ben Abbott <address@hidden> wrote:
> On Wednesday, February 24, 2010, at 08:58AM, "Jaroslav Hajek" 
> <address@hidden> wrote:
>>On Wed, Feb 24, 2010 at 2:42 PM, Ben Abbott <address@hidden> wrote:
>>> On Feb 24, 2010, at 12:03 AM, Jaroslav Hajek wrote:
>>>
>>>> On Wed, Feb 24, 2010 at 3:03 AM, Ben Abbott <address@hidden> wrote:
>>>>> On Feb 23, 2010, at 8:11 PM, John W. Eaton wrote:
>>>>>
>>>>>> On 23-Feb-2010, Ben Abbott wrote:
>>>>>>
>>>>>> | On Feb 23, 2010, at 7:43 PM, WS wrote:
>>>>>> |
>>>>>> | > Has this notation been implemented in octave yet?
>>>>>> | >
>>>>>> | > Tx
>>>>>> |
>>>>>> | hmmm ... if you mean something like what is below, then yes.
>>>>>> |
>>>>>> | function varargout = foobar ( )
>>>>>> |   for n = 1:numel(nargout)
>>>>>> |     varargout{n} = n;
>>>>>> |   end
>>>>>> | end
>>>>>> |
>>>>>> | In this instance "varargout" has a special meaning.
>>>>>> |
>>>>>> | If you mean, something like what is below, then that doesn't work with 
>>>>>> 3.2.x, but does with Matlab.
>>>>>> |
>>>>>> |     v{:} = {rand(1,2), rand(1,3)}
>>>>>> |     error: invalid dimension inquiry of a non-existent value
>>>>>> |
>>>>>> | or
>>>>>> |
>>>>>> |     v{:} = rand(1,2)
>>>>>> |     error: invalid dimension inquiry of a non-existent value
>>>>>> |
>>>>>> | Jarsolav, is this something that should be added to Octave?
>>>>>>
>>>>>> You need to write
>>>>>>
>>>>>> v = cell (expected_nargout, 1);
>>>>>>
>>>>>> [v{:}] = func (...);
>>>>>>
>>>>>> Does
>>>>>>
>>>>>> v = cell (expected_nargout, 1);
>>>>>> v{:} = func (...);
>>>>>>
>>>>>> work in Matlab?  If so, I think that's a relatively new addition and
>>>>>> in my opinion doesn't really fit with the rest of the language.
>>>>>
>>>>>>> v = cell (3, 1)
>>>>> v =
>>>>>    []
>>>>>    []
>>>>>    []
>>>>>
>>>>>>> v{:} = rand(1,2)
>>>>> v =    [1x2 double]
>>>>>
>>>>> My impression is that this isn't very new, but as I've always found some 
>>>>> of how Matlab handles cells to be counter intuitive (if not misleading), 
>>>>> so I'm not in the habit of using this notation.
>>>>>
>>>>> Ben
>>>>>
>>>>>
>>>>
>>>> I'd even say this is a bug in Matlab. The LHS expression is obviously
>>>> a cs-list with 3 elements, and it is outside multiple assignment, so
>>>> it should give an error, like in Octave. This should only work if v is
>>>> 1-by-1 (it does in Octave). What version of Matlab did you try?
>>>
>>> I tried R007b and R2009a. After some more experiments, it appears that 
>>> Matlab assumes nargout = 1. Thus for ...
>>>
>>>        v{:} = func (...)
>>>
>>> The resulting cell is always 1x1.
>>>
>>> Ben
>>>
>>
>>I think this is a Matlab bug and we should not reproduce it.
>>Can you try the following in Matlab?
>>
>>v = cell (3, 1);
>>v{1:3} = 1;
>>
>>s = struct ("x", {1, 2});
>>s.x = 1;
>
> I'm not taking a position on including this *feature*, but because of the 
> number of times Mathworks has delibrately implemented a inconsistent 
> *feature*, I'm skeptical that this is a bug :-(
>

Hey, but it may still be a bug, even though they call it feature :-)

>    v = cell (3, 1);
>    v{1:3} = 1
>    ??? The right hand side of this assignment has too few values to satisfy
>     the left hand side.
>

There we go. In the above case, v{:} should be equivalent to v{1:3}.

> The following works.
>
>    v(1:3) = {1}
>    v =   [1]    [1]    [1]
>
> For your second example,
>
>    s = struct ('x', {1, 2});
>    s.x = 1;
>    ??? Incorrect number of right hand side elements in dot name assignment.  
> Missing []
>    around left hand side is a likely cause.
>

But this is just another flavor of the situation.
I agree with John, this is just a special case that MathWorks didn't
bother to fix. Bug, definitely.

regards

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz