[Scilab-users] About some changes in Scilab 6

[Samuel Gougeon]

Hello Pierre,

That's right. The changes about the library generation was emphasized on 
the forum on 2015 summer (please see here 
<http://mailinglists.scilab.org/lib-unavailable-on-YaSp-tp4032576p4032578.html> 
for instance).
By the way, even before these changes, the example shown in the lib page 
is awful. The only proper way to build a library is using genlib(). This 
example is clearly outdated.

> I would like to avoid using 'genlib' as it does not recursively goes 
> through subdirectories

So, it is time to try using tbx_make() with proper flags.

> --> a = mlist(['myType']);
>
> --> function %myType_e(varargin)
>   >    error('My error msg')
>   > endfunction
>
> --> a(1)
> at line     2 of function %myType_e
>
> Function not defined for given argument type(s),
>   check arguments or define function %l_e for overloading.

This is because the prototype of a extraction overload for A(i1,i2,..,iN) is
function R = %typeOfA_e(i1,i2,...,iN,A)
The last input argument is the object from which you want to extract 
some component.
If you specify varargin, varargin is a list(), and so you get the given 
error message.



Le 16/02/2017 à 18:37, Pierre Vuillemin a écrit :
>
>     - I'm not sure that this is specific to Scilab 6, but I've noticed
>     a large difference in performance for solving linear systems A*x =
>     b in comparison to Octave and Matlab. For instance,
>
>         n = 100;
>         N = 1000;
>         T = 0;
>         for i = 1:n
>            A = rand(N,N);
>            b = rand(N,1);
>            tic();
>            x = A\b;
>            T = T + toc();
>         end
>         disp(T/n)
>
>
>     is (significantly) slower with Scilab (binaries for linux 64bits)
>     than with Octave. Is it due to the way the underlying lapack
>     library is compiled?
>

Did you benchmark and compare Scilab 5.5.2 an Scilab 6.0.0 performance 
for this example?

>
>
>     - In Scilab 5, given a variable 'x', the expression
>
>         x = clear('x')
>
>
>     was allowed and would clean the variable 'x'. Used together with
>     'resume' in a function, that allowed to clean variables from the
>     above environment. While it might not be a very safe coding
>     practice, is there a way to reproduce this behaviour in Scilab 6 ?
>

Actually, it was formerly possible to delete a variable by assigning a 
null variable to it.
And primitives without output arguments -- like clear -- returned such 
an object of type==0.
But the definition and the management of objects of type==0 have 
actually changed. In my opinion, the new management is not yet mature. I 
am updating the type() help page 
<https://codereview.scilab.org/#/c/19105/>, and i think that discussions 
are not over about this question :)

AFAIK, in Scilab 6, a null object can only be an undefined component of 
a list:
L = list("abc", , %z);
type(L(2))
x = L(2) // should do the same than x = clear("x") (that actually looks 
like a hack :/)


Regards
Samuel

PS : one single topic per thread is always better for mailing lists archives

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20170216/73cc3d95/attachment.htm>