[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: class dominance/precedence [was -> [foo{:}] - feature or bug ? (octa
From: |
Ben Abbott |
Subject: |
Re: class dominance/precedence [was -> [foo{:}] - feature or bug ? (octave-3.4.2)] |
Date: |
Sun, 07 Aug 2011 17:41:12 -0400 |
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