[Scilab-users] News: Scilab 6 Beta, VISA Toolbox, Embedded World 2016

[Samuel Gougeon]

Le 16/02/2016 12:21, amonmayr at laas.fr a écrit :
> Le 02/16/2016 11:55 AM, Eric Dubois a écrit :
>> .../...
>>
>> More worrying still, not all additions or subtractions involving null 
>> matrices will generate errors when switching from Scilab 5 or older 
>> to Scilab 6: for example, z=size([a+1 y],1) applied to the null 
>> matrix a will simply add 1 in Scilab 6 to the result of Scilab 5, 
>> without generating errors.
>>
.
It does:
--> a=[]; y = 3; z=size([a+1 y],1)
operation +: Warning adding a matrix with the empty matrix will give an 
empty matrix result.
  z  =

    1.

>> The attentive user will be alerted by the warning message generated 
>> by Scilab 6, but the inattentive one may not notice it or fully 
>> understand its consequences.
>>
This is why, fortunately, unworkaroundly, a new warning("stop") synopsis 
has been implemented. Announcements and Releases notes failed announcing 
and stressing on it:

warningstopfunctiontest()a=[];y=3;z=size([a+1y],1)endfunctiontest() --> 
warning stop --> function test() > a=[]; y = 3; z=size([a+1 y],1) > 
endfunction --> test() operation +: Warning adding a matrix with the 
empty matrix will give an empty matrix result. at line 2 of function 
test *** Execution stopped after a warning. *** Set warning("on") to 
continue execution after a warning.


Again and again and again, more and more publicity MUST be done about 
how to translate Scilab 5 code and modules into SCilab 6 code and modules.
For the moment, S/E fails on that.


>> .../...
>>
>> Don’t other Scilab users share my concern?
>>
.
Sure i did. This is why i claimed for a warning, and for a way to get 
the where() trace.

> Le 16/02/2016 12:21, amonmayr at laas.fr a écrit :
>
> Well, I understand your concern.
> However, I buy the fact that this change will make the language more 
> consistent.
> Indeed, "ms=m+s" where m is a matrix and s a scalar gives a matrix ms 
> of same size than m in most cases (ie when m is not empty).
> It thus makes sense that adding a scalar to an empty matrix returns an 
> empty matrix.
> This is also the default behavior with other similar languages like 
> octave, matlab, julia, so it makes sense.
> I think the old behavior was kind of weird.
> But you are right that this is a major change that will introduce 
> subtle and hard to find bugs.
> We should keep in mind that it's a major change (5.x->6.x) 
.
This is why IMO all major changes should be done now, not postponed for 
Scilab 6.x. For my part, i will refuse reviewing all my codes several 
times after 6.0.
For instance : http://bugzilla.scilab.org/14287 should be fixed before 
the final 6.0 release, or tagged WONTFIX.


> and I think the last one (4.x->5.x) was even worse in terms of 
> backward compatibility!
.
I don't think so, by far. The new graphical system -- that was the main 
change -- was already implemented in 4.  As far as i remember, 5. mainly 
removed the old graphical system that was still supported in addition to 
the new one (by the way, there are still some traces of the oldies... 
For instance, xset() is still unremoved, in 95% duplicate of set() that 
was introduced (but still with some features unported to set()) ).

Regards
Samuel Gougeon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20160216/d474a9ec/attachment.htm>