Sorry for the badly unretitled previous message. May i end it with a
suggestion:
Le 09/03/2016 01:18, Samuel Gougeon a écrit :
Hello,
Le 18/02/2016 20:41, Eric Dubois a écrit :
Hello
I am inclined to share Samuel point of view: this is a compliocation
than could be avoided.
But I cannot resist noting that the annoucement is 6 years older than
the announcement of the weapon of mass destruction that consist in
changing the behaviour of the addition of a matrix with a null matrix.
Sorry for insisting, but I will again call for the removal from the
final Scilab 6.0 release of this planned change.
First, I am not convinced at all by the argument put forward that it
will make Scilab more consistent with other language such as Matlab,
Octave, Julia.. : after all, every language has its indiosycrasies; a
Matlab user will yet have to adapt herslef to this change, bu along
many other ones; and I,do not think that changing this behavour will
convice any Matlab user to switch to Scilab nor prevent anyone
thinking about switching to give up because of this beahviour.
Second The argument that it enhances Scilab internal consistency is a
little bit more compelling, but not much: after all, addition and
subtraction are different operations from multiplication and
division, such one can justify different behaviour. And there are
cases when it make tho code more compact.
Adnd lastly both arguments are anyway swept away by the simple fact
that the change should make all previous code unreliable: you cannot
be sure in advance that the working of your program has not been
affected by the change (and the warning that is designed to alert to
the user is not sufficient: a warning can easily be missed,
especially for second hand users not so famaliar with Scilab and if
it is hidden among many other warnings).
I have the same feeling, and i agree mostly with your last remark. We
could stress on some "pitfalls" set by the oldEmptyBehaviour flag or
by the "warning stop" behavior:
* oldEmptyBehaviour flag:We may guess that this flag is a /global/
one. Isn't it? So, if we set it at the beginning of a script or of
a macro, then it applies to the whole Scilab session (i haven't
checked that), even after leaving the script or the macro. If so,
then if in a session we process some recent up-to-date scripts or
macros, and some other ones that are not up-to-date, what will
occur, whatever is the flag's value? This is not really clear.
* warning("stop"): i agree that, in order to update all contents and
to be sure that results are reliable and not polluted by
unpredictable "[]+-" side effects, this warning mode will have to
be always activated for a very long period, may be up to Scilab 7.
Then, the problem is that this stopping mode does not resolve the
cause: if an up-to-date package intentionally uses warnings for
anything else than []+, it will be stopped as well.
This warning mode should accept an additional parameter
identifying the type of event (or a series/vector of events) for
which stopping must occur. Shouln't it?
For both of these reasons, introducing this oldEmptyBehaviour flag in
Scilab 6 is questionable. It might be preferable to only improve the
warning("stop", event) mode, and to leave Scilab 5.5.2 available on the
download page for a long time. It will then always be possible to run
old packages with Scilab 5.
SG
_______________________________________________
dev mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/dev
