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 _______________________________________________ dev mailing list [email protected] http://lists.scilab.org/mailman/listinfo/dev
