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

[Serge Steer]

Le 02/10/2015 09:30, Nicolas FEZANS a écrit :
> Hi,
>
> first on point 2)
>
> A) [1 2 3] + 1 (as a scalar) makes mathematically no sense but can be
> seen as some syntax sugar to avoid having users constantly writing
> things like: "A+scalar*ones(size(A))"
>
> B) [1 2 3] + [4 5] makes no sense and there is no clear way of
> understanding what the user wanted to do and actually in most cases
> this means that something went wrong earlier and that the matrices
> being added do not have the dimension that the user thought that would
> have at that stage. An error is certainly the right thing to do to
> prevent the code from throwing an error much later and forcing the
> user to search backwards.
>
> C) [] + 1 = [] makes sense to me as an extension of rule A)
It depends on how this operation is interpreted:
- if it is considered as adding 1 to an array  then the answer should be
[] according to A):( the scalar is added to all elements of the array)
- if it is considered as adding [] to an array then the answer should be
an error according to B)  or D) (dimensions do not agree)

in Matlab the answer is []
>
> D) [2 1 -3] + [] is to my mind as wrong than B) and should not be allowed
>
In Scilab552 the answer is [2 1 -3] according to the rule A+[] =A
whatever A is. In Matlab the answer is an error.
I think it should be better to change the Scilab behavior in case A is
not a scalar nor ans empty array
> then on point 3)
>
> I agree with Serge: the sooner you get a feedback about an error the
> better. 

> This even brings me to ask why not throwing a real error
> instead of falling back to %nan?
Sometimes a programmer may really want to produce Inf and Nans
> I think the first thing to consider is that the sign of the step
> always need to match the sign of the difference end-start. 
I do not agree with that
0:-1:1 should be an empty array. It is also the Matlab answer
> If not that
> is clearly an error. %inf and %nan are also errors when talking about
> such ranges.
>
> Bringing answer like %nan or [] is such cases usually only make the
> program blow up some time later and that is not helpful. If someone
> really wants to make something very special, then he should be forced
> to specify it in his code, but the default behavior should (to my
> mind) be as safe, straightforward, and self-explaining as possible.
>
> I would however expect [1:0:1] to be [1] since this makes sense and
> could easily happen when computing bounds like this:
> "start:stepSize:start+NBsteps*stepSize" when NBsteps is set to 0 (I
> agree that this is not very elegant but it is very readable for a
> human being)
I agree with this point, but   in Matlab the answer is an empty array as
in Scilab5.5.2
> If we would decide that [1:0:1] = [1] is OK, that would open the
> question of making a similar exception for %inf:0:%inf and for
> -%inf:0:-%inf . My opinion is however that with %inf or -%inf that
> would still be an error.
according to the : definition a:0:a must return a so in my opinion 
%inf:0:%inf should return %inf (similarily for -%inf) .
 It is still unclear for me what should be the answer of %nan:0:%nan as
%nan is not equal to itself (in Matlab the answer is NaN)

Serge