[Scilab-Dev] Input requested on a few behaviors for Scilab 6...

François Granade francois.granade at scilab-enterprises.com
Thu Oct 1 18:37:10 CEST 2015


Hi all,

We're working on Scilab 6, as you may know :); part of the goal is to correct some weird behaviors of Scilab. We're thinking of changing a few inconvenient/inconsistent behaviors. And before we implement, and release them, we'd like to make sure that:
a) the new solution is better (we're quite sure, but not 100%), and
b) the change will not cause too many hassle for existing users. 

So your feedback is really welcome on the following three points...

Thank you in advance,

For the Scilab team,
François Granade


1. set ieee(2) by default instead of ieee(0)
-----------

This would raise neither a warning, nor an error, when running invalid numerical operation (eg. divide by zero), but instead use NaN as often as possible. This would be consistent with matlab and other platforms; but it could break existing scripts that rely on this behavior

This would only change the *default* behavior: it would still be possible to override is by simply adding "ieee(0)" at a beginning of a script, or in "ini" file for the user.


2. Make operations with the empty matrix more consistent
-----------

In particular, change:

1 + []

to return [] in 6.0, instead of 1 in 5.5.2; and same for 1 - []. This would be more consistent with other operations ( 1*[], 1.^[] ...).

More generally:

A + [] 

would return [] for A of any Scilab basic type; same for other binary numerical operators.

It would avoid weird behaviors with using find() to replace values, for example in this snippet:
A = ones(1, 5);
idx = find( A > 3 );
A(idx + 1) = 2;
currently change A(1) to 2 (in 5.5.2), which is very strange. It even creates a bug (kudos to Alain Lamy for finding it):
idx  = find(B > 0)
B(idx + 1) = B(idx)
will remove B(1) iff B is all negative in 5.5.2. 


3. Clarify "a:b:c" ranges when one of a, b or c is infinite (%inf) or Not a Number (%nan); or when b is 0.
--------------

Currently there are many inconsistencies in some cases, for example:

-%inf:1:%inf // returns %nan
2:0:5 // return []
// but:
%nan:1:5 // returns %nan

In 6.0, we're thinking of fixing things according to the following rules:

i) if start or step or end is %inf or %nan => return [] 
ii) step == 0 => return [] 
iii) start < end && step < 0 => return []
iv) start > end && step > 0 => return []
v) normal computation otherwise





More information about the dev mailing list