octave 3.2.0 parser

[Alexander Barth]

On Thu, Jun 11, 2009 at 7:59 PM, Jaroslav Hajek<highegg at gmail.com> wrote:
> On Thu, Jun 11, 2009 at 11:14 AM, Jaroslav Hajek<highegg at gmail.com> wrote:
>> On Tue, Jun 9, 2009 at 3:06 PM, Jaroslav Hajek<highegg at gmail.com> wrote:
>>> On Tue, Jun 9, 2009 at 12:38 PM, Alexander
>>> Barth<barth.alexander at gmail.com> wrote:
>>>> On Tue, Jun 9, 2009 at 12:18 AM, John W. Eaton<jwe at octave.org> wrote:
>>>>> On  8-Jun-2009, Alexander Barth wrote:
>>>>>
>>>>> | On Mon, Jun 8, 2009 at 8:24 PM, John W. Eaton<jwe at octave.org> wrote:
>>>>> | > On  8-Jun-2009, Alexander Barth wrote:
>>>>> | >
>>>>> | > | The matlab netcdf toolbox in octave uses expressions like these:
>>>>> | > |
>>>>> | > |  f{'myVariable', 1}(i, j, ...) = myVariableData
>>>>> | > | (see http://ecco2.jpl.nasa.gov/data1/matlab/netcdf_toolbox/netcdf/@netcdf/netcdf.m).
>>>>> | > |
>>>>> | > | With octcdf I implemented this functionality in octave. However since
>>>>> | > | octave 3.2.0, such expressions trigger an error:
>>>>> | > |
>>>>> | > | octave:1>  nc{'autoscale_var',1}(:) = var;
>>>>> | > | error: a cs-list cannot be further indexed
>>>>> | > | error: evaluating argument list element number 1
>>>>> | > |
>>>>> | > | It worked previously in octave 3.0.5.
>>>>> | >
>>>>> | > What are the values of the variables NC and VAR?
>>>>> | >
>>>>> | > jwe
>>>>> | >
>>>>> |
>>>>> | nc is ncfile. This object is created in octcdf
>>>>> | (http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/main/octcdf/src/ov-ncfile.h?revision=4812&view=markup)
>>>>> | and var is just a matrix. A complete example (which requires octcdf)
>>>>> | would be:
>>>>> |
>>>>> | nc = netcdf('test.nc','c'); % creates a netcdf file test.nc
>>>>> |
>>>>> | nc('time') = 5;  % defines dimension time
>>>>> | nc('space') = 3; % defines dimension space
>>>>> |
>>>>> | var = rand(5,3);
>>>>> |
>>>>> | nc{'autoscale_var'} =  ncdouble('time','space');  % defines a variable
>>>>> | depending on time and space
>>>>> | nc{'autoscale_var'}.add_offset = 1; % variable will be stored with an
>>>>> | offset of 1
>>>>> | nc{'autoscale_var'}.scale_factor = .1; % and scaled by a factor of .1
>>>>> | nc{'autoscale_var',1}(:) = var; % write variable to netcdf file with
>>>>> | autoscaling enabled
>>>>> |
>>>>> | close(nc) % close netcdf file
>>>>> |
>>>>> | I have this problem with octave 3.2.0 compiled with --enable-64, but I
>>>>> | don't think that this option has something to do with this (or not?)
>>>>>
>>>>> I don't understand precisely what it is you are trying to do, but
>>>>> apparently in your expression
>>>>>
>>>>>  nc{'autoscale_var',1}(:) = var;
>>>>>
>>>>> the first part
>>>>>
>>>>>  nc{'autoscale_var',1}
>>>>>
>>>>> is creating a comma-separated list, and you can't index a
>>>>> comma-separated list now.  A comma-separated list is just a group of
>>>>> objects, not a single object.  So indexing it doesn't make sense.
>>>>>
>>>>> jwe
>>>>>
>>>>
>>>> I'm trying to be more clear what this expression is doing.
>>>> The first part "nc{'autoscale_var',1}" is creating a new object (a
>>>> netcdf variable) by calling the method subsagn of the netcdf file.
>>>> 'autoscale_var' and 1 are passed to subsagn by the parameter idx. The
>>>> resulting netcdf variable is then indexed with (:).
>>>>
>>>> I realize than those expressions seem to be quite "baroque", but I
>>>> needed to implement them in octcdf to be compatible with the matlab
>>>> netcdf toolbox (and those expressions are valid in matlab).
>>>>
>>>> If one separates the assignment in different steps, it actually works
>>>> in octave 3.2.0:
>>>> nv = nc{'autoscale_var',1};
>>>> nv(:) = var;
>>>>
>>>> Thanks and regards
>>>> Alex
>>>>
>>>
>>> It seems the relevant code tree_index_expression::lvalue() tries to be
>>> smart by estimating the number of elements without actually doing the
>>> indexing, and that backfires here, since with nc a cell array,
>>> nc{'autoscale_var',1} should produce a cs-list. Hmmm. Apparently the
>>> possibility of {} being overloaded in an inconsistent manner didn't
>>> occur to me. It is legitimate, though. I'll try to do something with
>>> this.
>>>
>>> regards
>>>
>>
>> after a bit of playing around and inspecting the Matlab docs (I have
>> no more access to Matlab), I ended up with the following change:
>> http://hg.savannah.gnu.org/hgweb/octave/rev/67fc970dad7d
>>
>
> To Alexander: I should have added, that your code still won't work
> with these changes, but now you can trivially fix it by overloading
> numel (const octave_value_list&) to return the appropriate value
> (probably always 1), similarly to what you would need to do in m-file
> code.
> I'm not yet sure whether this will go in 3.2.1.
> cheers
>

I tried this with a recent mercurial checkout and it worked!
Thank you very much,
Alex
Thank you very much