[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