Pros And Cons Of Scilab
After many years of use, a program's advantages and disadvantages become more and more obvious. We have collected a Pros-and-Cons list; some of the points where we think Scilab shines and where we think it sucks.
- Seamless windowing
Many Open Source numerical programs are only available in a text console version. Scilab too offers a text-only console, it it is called with -nw, otherwise it starts in a specifically adapted xterm-window, which is shown in the following screen shot.
The principal functionality of both, the pure text and the X-based console is identical with the X-based console offering enhanced access to the apropos feature, the demos and the graphics windows.
- Integrated graphics
Scilab is one of the very few packages that have their graphics capabilities integrated in the main program. Octave and Tela, e.g. rely on separate graphics programs (Gnuplot and PlotMTV, respectively). Integrated in this context means that you have full control over the graphics output and input, e.g. pass the point a user clicked on the graph back to your script.
- Huge library
The standard library is huge, and under normal circumstances it is not necessary to pre-load additional packages or toolboxes. To give just one example, here is the answer to apropos distribution:
||cumulative distribution function beta distribution
||cumulative distribution function binomial distribution
||cumulative distribution function chi-square distribution
||cumulative distribution function non-central chi-square distribution
||cumulative distribution function f distribution
||cumulative distribution function non-central f-distribution
||cumulative distribution function gamma distribution
||cumulative distribution function negative binomial distribution
||cumulative distribution function normal distribution
||cumulative distribution function poisson distribution
||cumulative distribution function student's t distribution
||pseudo affine wigner distribution
- Rich set of datatypes
Some numerics environments only feature one data type namely double precision reals (double in C, double precision, or real*8 in Fortran-77 according to the IEEE754 standard.) In contrary to these packages Scilab has a rich set of atomic data types and a large set of container types, too.
Atomic data types:
- PVM integration
The Parallel Virtual Machine, PVM is almost seamlessly integrated with Scilab. Through PVM Scilab can be run on multiple machines (multiple times) in a heterogeneous network.
- Online function definition
Some packages only allow for functions definitions via an associated file, like
function y = exp2(x)
// series( exp(x), x = 0, 3 );
y = 1.0 x 0.5*x.*x
whereas in Scilab functions can be defined online as well. These online-defined functions are completely equivalent to function defined via a file.
The online definition of our previous example, exp2, has the following form:
deff('y = exp2(x)', 'y = 1.0 x 0.5*x.*x')
- Nested function definitions
Function definitions can be nested, restricting the visibility of nested functions to the enclosing function.
function z = foo(x, y, n)
deff('y = sincN(x, n)', 'y = sin(x * n) / (x * n)')
deff('z = gauss(x, y)', 'z = exp(-(x^2 y^2))')
y = gauss(x, y) * sincN(x, n)
- Multiple function definitions per file
One file can carry more than one function definition. Rewriting the above example of a nested function definition we wind up with
function z = foo(x, y, n)
y = gauss(x, y) * sincN(x, n)
function y = sincN(x, n)
y = sin(x * n) / (x * n)
function z = gauss(x, y)
z = exp(-(x^2 y^2))
in a single file, which can be sourced with getf("filename").
- Operator overloading
Operators (e.g. , *, .*) which take user defined data types - and only these - can be overloaded with user defined functions. The types of the operands, neglecting the result type, determine which function is called. This is similar to C .
- Function Profiler
From version 2.6 on Scilab features a function profiler, which provides line-by-line information of the following three parameters: (1) number of executions, (2) total cpu time, and (3) interpeter effort for a single execution.
Given a function like
function n = catch22(x0)
// The famous catch-22 function: it is impossible to calculate that
// it will stop for a specific input.
n = 0;
x = x0;
while x ~= 1
if x - floor(x/2)*2 == 0
x = x / 2;
x = 3*x 1;
n = n 1;
and 1000 calls to catch22, we get the following profile:
calls time comp- code
===== ===== ======
1000 0 0 function n = catch22(x0)
1000 0 0 // The famous catch-22 function: it is impossible to calculate that
1000 0 0 // it will stop for a specific input.
1000 0 0
1000 0 2 n = 0;
1000 0.01 2 x = x0;
59542 0.29 0 while x ~= 1
39889 0.6 0 if x - floor(x/2)*2 == 0
39889 0.4 4 x = x / 2;
19653 0.44 0 else
19653 0.23 6 x = 3*x 1;
59542 0.09 0 end
59542 0.05 0 //disp(x);
59542 0.42 4 n = n 1;
1000 0.01 0 end
- Matlab® to Scilab translator
An automatic Matlab® to Scilab translator is under development.
- Missing unicode support
Unicode support is missing completely. Neither the GUI, any string, nor the (Scilab-) scripts can contain any kind of unicode character. This is a major limitation in all countries, where the ASCII character set is not enough.
- Missing MathML support
What is true for the lacking unicode support holds as well for the non-existent MathML support. The MathML-2.0 specification being underway, having no MathML at hand is not a severe drawback yet. It will become a limitation as soon as more mathematical and scientific software will use MathML as a program and platform independent way to exchange mathematical expressions.
It is particularly interesting that Stéphane Dalmas, a member of the W3 Math Working Group, is mainly affiliated with the SAFIR Research Group, which we all know, belongs to INRIA.
- No dynamically linked version
Scilab can only be build with static libraries even on systems that support dynamic libraries (also known as shared objects). This increases the startup time, and more importantly the memory footprint.
A dynamically linked version would allow for more Scilab processes to be concurrently runnable on the same machine.
- No full featured GNU readline
Only a shrunken version (e.g. reverse-i-search does not exist) of a readline library is built into Scilab. It is no match for the real GNU readline library ( FTP ), available in Octave , or Tela .
Furthermore, Scilab has no completion feature, like the TAB-filename completion of the shell, at all.
- Missing API for front-end programming
Scilab lacks an API that allows for writing different front-ends like the two existing ones: terminal and windowing.
The procedure suggested in SCI/examples/callsci, linking a complete Scilab on top of the user application, is incredibly inefficient and inflexible.
The Communication Toolbox badly documented and hard to use. Furthermore it goes the detour of message passing that is unnecessary (and slow) for local applications.
- Only three variable scopes
The are only the interpreter-level, the function-level and the global scope (global scope support is broken in version 2.5). Three scopes are inadequate for larger projects and a severe restriction for writing maintainable packages.
- Poor mass I/O features
The only supported I/O routines relate directly to Fortran and C library functions. Both groups of functions are complicated to use, and lack the power a user demands of a high-level language like Scilab.
Sophisticated input parsing, like e.g. regular expressions is impossible. Portable binary formats like XDR / [RFC1014] (XDR is available via PVM , but not as separately usable functions at the interpreter level) and HDF are not implemented.
- Ignorance of optimized BLAS libraries
The existence of optimized BLAS libraries, like e.g. ATLAS has been ignored. Instead Scilab either relies on the extremely slow reference implementation of BLAS or even worse implements its own (and sometimes much slower than even the reference BLAS) low-level routines.
- Lack of internals and back-end API documentation
The documentation of the internals in Internals is ridiculously incomplete. The back-end API functions are undocumented.
- Complicated plotting functions
The naming of Scilab's plot functions is non-intuitive to the user (Do I need plot, plot2d, plot2d1, plot2d2, plot2d3, or plot2d4?) The syntax of these functions is ancient, akin to the interfaces of 1970s Fortran libraries. It is too complicated, and much to inflexible.
- Incomplete hypermatrix support
The hypermatrix container does not support all scalar types equally well, e.g. it is lacking complete support for boolean hypermatrices.
- Inconsistent function handling
Functions are treated differently depending on where they are from. For example, functions which are defined online or read from a function file can be used as arguments in other functions, whereas builtin functions or functions loaded via interf cannot.
- Occasional waste of memory (stack space)
Scilab sometimes wastes a lot of stack space, treating in memory for simplicity of the (Scilab internal) code. E.g., ranges are always computed immediately (no lazy evaluation) and completely (no range type as in Octave).
-->numrange3 = 1:1000;
-->numrange4 = 1:10000;
-->numrange5 = 1:100000;
-->whos -name numrange
Name Type Size Bytes
numrange3 constant 1 by 1000 8016
numrange4 constant 1 by 10000 80016
numrange5 constant 1 by 100000 800016
Further notes: (1) Ranges of integers (e.g. int16(1):int16(10000)) are not implemented as of version 2.5.1. (2) The memory hog stikes even in for-loops:
for i = 1:1000000