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

[Ben Abbott]

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