[Scilab-users] About some changes in Scilab 6

[Pierre Vuillemin]

Hello Samuel,

Thank you for your answers.

- *Building toolboxes*: I did not know that tbx_make() was functional, 
it seems the way to go in the future indeed. At the moment, it seems to 
be a bit unstable though and produced a segfault in my case,

terminate called after throwing an instance of 
'GiwsException::JniCallMethodException'
   what():  Exception when calling Java method :
Segmentation fault (core dumped)

- *Using 'error()' in overloading functions*: I'm not sure to understand 
what you mean?

To overload the extraction for both 1 and multiple indexes (as 
matrices), e.g. a(1), a(1,2), I used,

    function out = %myType_e(varargin)

    // the object is always varargin($),

    // the indexes are varargin(1:$-1)

    endfunction

to cover all the cases in one function. This actually works, but using 
error(' ') within this function does no longer display the error 
message, instead, it says that the overloading is not defined.

- *Performances for solving A*x = b*: On Scilab 5, the code

    n = 100; A = rand(n,n);b = rand(n,1);x = A\b;

leads to a segfault for n >= 18 (maybe a problem with the package in 
ubuntu?). Hence I did not really test the performances.


- *Equivalent to x = clear('x') in Scilab 6*: I see., I 'll stick with 
empty variables for the moment.


Best regards,

Pierre

PS: I understand. I just did not want to spam the list with multiple 
questions.


Le 16/02/2017 à 22:20, Samuel Gougeon a écrit :
> 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
>
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20170217/8f25ba6c/attachment.htm>