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

[Nicolas Fezans]

On Thu, Oct 1, 2015 at 7:05 PM, Serge Steer <Serge.Steer at inria.fr> wrote:
> 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.
>>


Well, here I think that returning NaN is not a bad default behavior in
that case because if you do a bunch of batch computations on Monte
Carlo simulations you often huge series of independent computations
and having one crashing for some numerical reason (let say for
instance that in that area of the parameter space, the system you
considered is unstable), you don't want the whole program that has
been running for days to hang up causing possibly to loose a lot of
valid results. Taking care of those failed cases in the
post-processing is often a better user experience I think.

This actually makes me have a second thought about my previous answer
for number 3) and to go there also for more tolerance in the default
behavior (so basically what Serge proposed)

In that case I would however propose to have the possibility to change
the behavior for a strict(er) one, e.g. as would be the activation of
ieee(0) then. Such that if things go wrong while developing/testing a
program, you do not need to trace back the chain of %inf and %nan back
to the source but can have Scilab directly tell you where the possibly
questionnable numerical operations began.This would introduce some
kind of "debug" functionality for which it might be helpful to not
directly throw an error by to prompt the user whether this operation -
that would have not generated an error otherwise - should be tolerated
this time or not. So you can look for what happens next, and next...
in many cases you would be able to find the problem very quickly but
without even having to set any breakpoints manually.


Regards
Nicolas