help-octave
[Top][All Lists]
Advanced

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

Re: numel(foo{:}) - feature or bug ?


From: Sergei Steshenko
Subject: Re: numel(foo{:}) - feature or bug ?
Date: Fri, 5 Aug 2011 22:54:49 -0700 (PDT)


--- On Fri, 8/5/11, fork <address@hidden> wrote:

> From: fork <address@hidden>
> Subject: Re: numel(foo{:}) - feature or bug ?
> To: address@hidden
> Date: Friday, August 5, 2011, 10:11 AM
> Sergei Steshenko <sergstesh
> <at> yahoo.com> writes:
> 
> > And zero instead of three is _nonsense_ to me. Call me
> dumb.
> > 
> > ...
> > 
> > I think 'octave' should have a
> 'enable_stupid_matlab_bugs' flag.
> 
> The utility of the matlab compatible behavior is that one
> can loop over an N x M
> cell array that holds complex parameter sets (including
> structs and large
> matrices) as columns and feed each parameter set to a
> function.  Like so
> (admittedly trivial):
> 
> x = {1 2 ; 3 4 }
> f = @(x,y) x+y
> for p = x
>     f(p{:})
> endfor
> 
> As a general rule, I would give matlab syntax the benefit
> of the doubt and try
> to figure out why it was chosen, rather than file bug
> reports about how it
> should be changed.
> 
> This is not to say there wouldn't be utility in the
> approach you advocate, and
> perhaps it would be a useful extension.
> 
> 
> _______________________________________________
> Help-octave mailing list
> address@hidden
> https://mailman.cae.wisc.edu/listinfo/help-octave
> 

First of all, I do not really advocate at all allowing to have
numel(foo{:}).

The truth is that I got bitten by it. I.e. I had something that had
numel(foo) == 2, abd by mistkae I wrote a code conceptually equivalent to

for i = 1:numel(foo{:})
  ... foo{i} ...
endfor
.

'foo' was 1-d, and I got an index out of bounds violation - numel(foo{:})
returned 107 in my case.

I started digging, and after realizing that I actually needed numel(foo)
I solved the immediate problem.

But that all startled me - because for a regular column/row vector 'foo'
I wouldn't have had the problem in the first place regardless of
numel(foo) or numel(foo(:)).

So, if I'm advocating something, it is disallowing numel(foo{:}) - like it
used to be.

But I decided to publish my findings - at least the developers admit the
'numel' documentation is terse and they have included some changes
- this by itself justifies the time I spent on "playing" with the issue.

...

Secondly, your example in no way explains how/why for entity obviously
(to _my_ brain/eyes) having three defined and one undefined/null elements
'numel' returns 0 instead of 3 (or 4).

Thanks,
  Sergei.




reply via email to

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