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 suppose this should be written in big red letters somewhere, yet I'm too lazy to do it. -- RNDr. Jaroslav Hajek, PhD computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz ------------------------------------------------------------------------------ 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
