Re: class dominance/precedence [was -> [foo{:}] - feature or bug ? (octave-3.4.2)]

[Ben Abbott]

On Aug 7, 2011, at 2:31 PM, Ben Abbott wrote:

> On Aug 7, 2011, at 1:22 PM, Sergei Steshenko wrote:
> 
>> --- On Sat, 8/6/11, James Sherman Jr. <address@hidden> wrote:
>> 
>>>> I do _not_ see any trace of "[1 2 3 4]" vector ?
>>> 
>>> You do see a trace in the fact that there is emptiness there (not simply 
>>> out of bounds).  The problem is that octave matrices (AFAIK) can only hold 
>>> one type of element.  So, when you concatenate a char matrix with a double 
>>> matrix, I believe octave defaults to a char matrix.  I'm using 3.2.4 still, 
>>> but this is what I get for concatenation:
>>> 
>>> octave-3.2.4.exe:20> a = "a"
>>> a = a
>>> octave-3.2.4.exe:21> b = [1 2 3 4]
>>> b =
>>>   1   2   3   4
>>> octave-3.2.4.exe:22> c = [a b]
>>> c = a☺☻♥♦
>>> 
>>> So the b variable is interpreted in funny characters (presumably 
>>> corresponding to 1 2 3 4 in whatever encoding octave is using).You can see 
>>> this in the whos:
>>> octave-3.2.4.exe:26> whos
>>> 
>>> Variables in the current scope:
>>>  Attr Name        Size                          Bytes  Class
>>>  ==== ====        ====                     =====  =====
>>>       a                   1x1                          1        char
>>>       b                   1x4                         32       double
>>>       c                   1x5                          5        char
>>> 
>>> So the reason you're seeing emptiness is probably because whatever in 
>>> coding your using for characters, the corresponding characters for the 
>>> numbers 1, 2, 3 and 4 are blank or maybe unprintable.
>>> 
>>> Hope this helps.
>> 
>> Why did 'octave' in my example choose to convert to 'char' and not to
>> 'double' ?
>> 
>> In case of mixed data types like in my case which part of 'octave'
>> documentation describes choosing of destination data type ?
>> 
>> Thanks,
>> Sergei.
> 
> I've been meaning to look up class dominance in Octave and Matlab.
> 
> Matlab's documentation includes this ...
> 
>       http://www.mathworks.com/help/techdoc/matlab_oop/brf5okb-1.html
> 
> <quote>
> MATLAB built-in classes are always inferior to user-defined classes and 
> should not be used in this list.
> 
> The built-in classes include: double, single, char, logical, int64, uint64, 
> int32, uint32, int16, uint16, int8, uint8, cell, struct, and function_handle.
> </quote>
> 
> I haven' t checked all combinations but for the ones I looked at, the order 
> appears to be in increasing dominance.
> 
> I don't see this info stated explicitly in in Octave's documentation. Section 
> 33.4.3 is titled "Precedence of Objects" and includes a description of 
> functions superiorto() and inferiorto() which provide the means to define 
> class precedence when constructing a class. Perhaps this information should 
> be added there, but we'll first need to determine the actual class precedence 
> implemented in Octave.
> 
> Does anyone know of a simple method to determine the precedence for all 
> classes?
> 
> Ben

I dd some more investigating, and have found incompatibilities in object 
precedence between Matlab and Octave. I'll report this to the developers 
mail-list. What I found is below.

I've identified seven groups of objects in ML. Objects within groups
have equal precedence.  Group (1/logical) has the lowest pecedence and
group (7/function_handle) has the highest precedence.

(1) logical
(2) double
(3) single
(4) uint8, uint16, uint32, uint64, int8, int16, int32, int64
(5) char
(6) struct, cell
(7) function_handle

Arrays of function handles are not allowed. Thus, they may be ignored 
with regards to precedence when concatenating objects.

If a cell is concatenated with other objects, of lower precedence, they are
each converted to cells. For example, the command below is valid ML syntax
and produces a cell array.

a = [{}, logical(1), double(1), single(1), uint32(1), 'a', struct('foo','bar')]

ML gives the indicated results for the concatentations below 

class ([true, double(1)]) = "double"
class ([double(1), single(1)]) = "single"
class ([single(1), uint32(1)]) = "uint32"
class ([uint32(1), 'a']) = "char"
class (['a', cell(1)]) = "cell"
class ([cell(1), struct('foo','bar')]) = "cell"

When concatenating objects of equal precedence, Octave and ML return an object 
whos class 
consistent with that of the fist object.

Octave is also consistent with ML when concatenating numeric and character 
classes.

Concatenating matrices with cell arrays gives an error in Octave. For example, 
using
a trival character scalar ...

a = 'a';
[a, cell(1)]
error: invalid concatenation of cell array with matrix

[cell(1), a]
error: concatenation operator not implemented for `cell' by `scalar' operations

Structures and cells have equal precedence, and the example below should 
produce a cell object.

[cell(1), struct('foo','bar')] 
error: concatenation operator not implemented for `cell' by `scalar struct' 
operations

But the one below should (and does) give an error.

>> [struct('foo','bar'), cell(1)] 
error: concatenation operator not implemented for `struct' by `cell' operations

Ben