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

[Serge Steer]

Le 01/10/2015 18:37, François Granade a écrit :
> 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.
I my opinion it should be better to keep the current behavior. When an
algorithm produces an inf or a Nan  it is very often due to an algorithm
defaut and it is convenient to be informed as soon as possible.
If one really want to produce nan or inf it is safer to toggle the ieee
mode locally.
One improvement should be to make the ieee mode change only for the
active function and the called ones instead of changing the global behavior.
>
> 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 []
for i and ii may be it should be better to throw an error.
 
without the stacksize limit  1:1e-30:2 will create a huge array , it
should be  useful to add a limit

iii and iv is the current behavior nothing has to be changed

> v) normal computation otherwise
>
>
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/dev
>