[Scilab-users] Slight inconsistency and suggested mprovement in max / min / mean etc.

[Samuel Gougeon]

Le 17/01/2020 à 06:28, Federico Miyara a écrit :
>
> Dear all,
>
> I've seen that functions like max, min, sum, prod, cumsum, cumprod, 
> mean, median, stdev are similar in that they act on several data 
> returning a scalar result. If "r" or "c" are includedas an additional 
> argument, they operate along rows or columns.
>
> Except for max and min, they all accept 1 and 2 instead of "r" and 
> "c". By the way, in several help pages this possibility is presented 
> as a side note.
>
> I understand this slight difference is to allow the comparison of a 
> whole array with a scalar, so that max(x,1), for instance, is an array 
> whose components are the maximum between the original components and 1.
>
> This prevents using the general syntax max(x,1) which would be more 
> consistent, allowing its genaralization as max(x,n) where n is the 
> dimension along which the requested operation would be performed.
>
> Currently n may be only 1 and 2, but there is no reason why it 
> couldn't be any other dimension. For instance, calling the third 
> dimension"layer", max(x,3) would mean getting the maximum of a row and 
> column along different layers. This could be used, for instance, to 
> get the most brilliant version of a pixel along successive frames in a 
> movie.
>
> To keep the comparison-with-a-scalar feature, it would be enough to 
> place the scalar first: max(1,x). The only caution needed in this kind 
> of comparisons is that if there is at least one non-scalar array in 
> the comparison list, the last item should be non-scalar.


This issue is reported at http://bugzilla.scilab.org/14639.
It is proposed to exceptionnaly specify the dim as a literal number, as in

max(A,"3")

Regards

Samuel

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