Re: Class related regressions in GNU Octave 4.0

[Oliver Heimlich]

On 13.04.2015 22:27, Oliver Heimlich wrote:
> On 13.04.2015 07:34, Oliver Heimlich wrote:
> > On 13.04.2015 00:14, Michael Godfrey wrote:
> > > Matlab R2015a Said (after fixing quotes, etc.):
> > [SNIP]
> >
> > Michael, thanks for checking.
> >
> > This classifies all three bugs as MATLAB incompatibilities. I am going
> > to prepare patches.
> >
> > Oliver
>
> I have looked into the code. I see the following dependencies:
>
> size calls dims () if not overridden.
> isscalar calls numel (), which uses dims () if not overridden.
> isvector as well as isrow and iscolumn call dims ().
> isequal calls octave_base_value::size, which uses dims ().
>
> So, all functions in question end up using the function dims () by
> default, which currently can't be overridden by the class with m-files.
>
> To get a consistent behaviour I would have to change octave_class::dims
> and evaluate the overridden size function if it exists. This sounds like
> it could work, but is quite a big change with possible dependencies—so I
> am not sure. What do you think?

I have tried to produce a patch, but gave up for now. The octave_class 
data type would require a serious makeover to become matlab compatible 
and respect an overridden size method for the results of 
octave_class::dims and others.

Currently I have not enough knowledge of Octave's internal data types to 
do this thorougly.

However, I have posted a clean patch for bug #44334, which should fix at 
least the isequal regression in Octave 4.0.

> On the way through the sources I have learned that octave_class::dims
> assumes that the object is represented by a structure array [1], a
> datatype which I have never used before. The structure array data type
> is perfect for what I want to store in my class instances, and, if I use
> it, I don't even have to override the size or numel methods in the first
> place and everything just works (in 3.8.2 and in 4.0).
>
> [1]
> https://www.gnu.org/software/octave/doc/interpreter/Structure-Arrays.html

The structure array looks great in theory, but is hard to handle in 
practice and produces rather big impacts on memory consumption as well 
as performance when compared to a scalar structure that holds matrices 
of equal size.

Therefore I have decided that I will not use the structure array. The 
downside is that I have to override all of the following methods (in 
addition to size): ndims, numel, ismatrix, isvector, isscalar, issquare, 
isrow, iscolumn.

Bug #42422 has been fixed already, so the overridden ismatrix is not 
required in octave 4.0 anymore.

The other overridden methods might become redundant one day when the 
octave_class has been changed.

More downsides of not using a structure array is that I have to 
reimplement methods like cat, resize, reshape, prepad, postpad. However, 
these do not depend on size alone.

Oliver