Quantcast

[Scilab-users] About some changes in Scilab 6

classic Classic list List threaded Threaded
3 messages Options
Pierre Vuillemin Pierre Vuillemin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Scilab-users] About some changes in Scilab 6

Hi all,

Congratulations to Scilab team for the release, it looks very promising!


I have begun to test the compatibility of some of my tools with Scilab 6 and I have some questions:

- the way libraries are handled seems to have changed with Scilab 6, and the example provided in 'help lib' does not work anymore,

//define some functions
function z=myplus(x, y)
  z = x + y
endfunction

function z=yourplus(x, y)
  x = x - y
endfunction

//create the *.bin files in libdir
libdir = TMPDIR;
save(libdir + '/myplus.bin', 'myplus');
save(libdir + '/yourplus.bin', 'yourplus');

//create the name file
mputl(['myplus';'yourplus'],TMPDIR+'/names');

//build the library containing myplus and yourplus
mylibfoo = lib(libdir+'/');
The above code says that the path is not a path to a valid library.
Could someone explain what 'lib' is expecting? (I would like to avoid using 'genlib' as it does not recursively goes through subdirectories).


- when 'error' is called within a function that overload the behaviour for some object, then the error message is not displayed, e.g.

a = mlist(['myType']);
function %myType_e(varargin)
   error('My error msg')
endfunction
a(1)

only says that the operation is not defined for this type without displaying 'My error msg'.


- 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?


- 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 ?

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

Re: About some changes in Scilab 6

Hello Pierre,

That's right. The changes about the library generation was emphasized on the forum on 2015 summer (please see here 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, 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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Pierre Vuillemin Pierre Vuillemin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About some changes in Scilab 6

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 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, 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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


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