[Scilab-users] type/typeof bug ?

sgougeon at free.fr sgougeon at free.fr
Tue Jun 7 10:52:35 CEST 2016


Hello Philippe,

>I work with matrix of polynomials, but some coefficients could be scalar. 

?
Each coefficient _is_ a scalar.

>I though that I could differentiate real and polynomial coefficients
>comparing their type, surprisingly  type(A(i,j))=2
>whatever the nature of A(i,j)  (see example below). Is this a bug ? 

No, it's not a bug

>For my applications i have a "work around "  comparing their degree .

Yes, it is the proper way to proceed


>-->L=[X 0 1]     // a matrix
> L  =
>    x     0    1

When you concatenate polynomials and numbers, numbers are automatically converted into polynomials of degree 0.
This is the same as when you concatenate 
 * booleans and decimal numbers (result as decimal)
 * real and complex numbers: reals are converted into complex numbers with imag==0.
 * polynomials and rationals (result as rational)
The output type is the richest one.

However, this general rule does not apply to encoded integers: Each inttype may be concatenated only with itself.
These rules are presented in the "help brackets" page in review
https://codereview.scilab.org/#/c/17924/13/scilab/modules/core/help/en_US/1_keywords/brackets.xml

HTH
Samuel

PS: I don't know why all integer types are considered as exceptions requiring undefined overloads:
-->[1 int8(1)]
           !--error 144 
Undefined operation for the given operands.
check or define function %s_c_i for overloading.

There are 8 inttypes, so there should be 8x7x2 = many combinations of 2 inttypes, plus combinations with non integer types, and as many overloads.
Unless a "generic" overload is defined and used as soon as one integer is involved.



More information about the users mailing list