[Scilab-users] implicit polynomial / implicitlist

classic Classic list List threaded Threaded
2 messages Options
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

[Scilab-users] implicit polynomial / implicitlist

Dear ESI devs,

In Scilab < 6, typeof(1:$) was "size implicit"

In Scilab 6.0, typeof(1:$) has become "implicitlist"

Why not.
The issue is that the overloading code is still "ip" standing for "implicit polynomial", not "il".
And in practical, this object is actually made of polynomial(s)

So, in one hand, for the same object, we refer to lists. On the other one, we refer to polynomials.
I don't know what was the motivation in renaming "size implicit" into "implicitlist".
If it was to remove an inconsistency somewhere, it apparently adds another one elsewhere.

So: why not typeof(1:$,"overlaod")=="il" ?

It may still be the time to make the change consistent...

Regards
Samuel



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: implicit polynomial / implicitlist

Le 12/02/2018 à 21:30, Samuel Gougeon a écrit :

Dear ESI devs,

In Scilab < 6, typeof(1:$) was "size implicit"

In Scilab 6.0, typeof(1:$) has become "implicitlist"

Why not.
The issue is that the overloading code is still "ip" standing for "implicit polynomial", not "il".
And in practical, this object is actually made of polynomial(s)

So, in one hand, for the same object, we refer to lists. On the other one, we refer to polynomials.
I don't know what was the motivation in renaming "size implicit" into "implicitlist".
If it was to remove an inconsistency somewhere, it apparently adds another one elsewhere.

So: why not typeof(1:$,"overlaod")=="il" ?

Actually, i think that "implicitlist" is right.
"Size implicit" emphasized one usage (among other possible ones) : indexation.
"implicit polynomial" points to the components of the object, more than the object itself.

So this renaming is rather welcome and relevant. But now it would be even better to get a consistent overloading code.

Samuel


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users