<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hello,<br>
<br>
Le 18/02/2016 20:41, Eric Dubois a écrit :<br>
</div>
<blockquote
cite="mid:CAGgDjFTioCjbgVMnMTUvVEEu+sGDHW1E=aPArDgwiS7qtWgm8w@mail.gmail.com"
type="cite">
<div dir="ltr">Hello
<div><br>
</div>
<div>I am inclined to share Samuel point of view: this is a
compliocation than could be avoided.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Sorry for insisting, but I will again call for the removal
from the final Scilab 6.0 release of this planned change.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
</div>
</blockquote>
<br>
I have the same feeling, and i agree mostly with your last remark.
We could stress on some "pitfalls" set by the <tt>oldEmptyBehaviour
flag or by the "warning stop"</tt> behavior:<tt><br>
</tt>
<ul>
<li><tt>oldEmptyBehaviour</tt> flag:<tt> </tt>We may guess that
this flag is a <i>global</i> 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.<br>
<br>
</li>
<li><tt>warning("stop")</tt>: 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. <br>
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?</li>
</ul>
<p>BR<br>
Samuel<br>
<br>
</p>
</body>
</html>