tor, 08 04 2010 kl. 12:06 +0200, skrev Jaroslav Hajek:
> On Thu, Apr 8, 2010 at 9:01 AM, Søren Hauberg <so...@hauberg.org> wrote:
> > tir, 06 04 2010 kl. 16:47 +0530, skrev n...@itimes.com:
> >> I think I have got the bug. :)
> >> In octcdf package in ov-ncvar.h instead of
> >>
> >> octave_idx_type numel(const octave_value_list&)
> >> {
> >> return dims().numel();
> >> };
> >>
> >> it should be
> >>
> >> octave_idx_type numel(const octave_value_list&)
> >> {
> >> return 1;
> >> };
> >
> > I don't claim to understand the 'octcdf' code, but the current code does
> > seem correct to me. What is the motivation behind your suggested change?
> >
> > Søren
> >
> >
>
> The numel (void) and numel (const octave_value_list&) do something
> completely different. The second one corresponds to the query that is
> made prior to subsasgn calls, to determine the cs-list length of lhs.
> Blame Matlab for this choice, because they say this is done through
> numel(). As a result, it is practically impossible to define a class
> in m-files that behaves like a regular array, yet allows dot indexing
> like a scalar structure. In C++, it is possible, but you need to let
> the two methods behave inconsistently
I'm tired (my neighbour likes to talk really loud late at night for some
reason), so I'm gonna ask the stupid question: does that mean the
suggested change was correct?
Søren
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
