Le lundi 05 mai 2014 à 11:00 -0400, Stefan Karpinski a écrit :
> Since any way you might express the dimensions argument could also be
> a collection to reduce over, I don't think there's any way to squeeze
> all this functionality into a single function unambiguously without
> using keyword arguments. But with a keyword argument, you certainly
> can do it. We could even leave the maximum and minimum versions in
> place as the unambiguously "reducer" versions and have min and max
> server both roles depending on how they're called. The main concern is
> avoiding potential performance problems caused by using keyword
> arguments.
In R, the element-wise/parallel version is called pmax(), while the
reducing version if called max(). Could be an alternative to keyword
arguments.

Or it could be useful to have a general syntax to apply element-wise
operations, as a short-hand for manual iteration over all the dimensions
of one or several arrays.


Regards

> On Mon, May 5, 2014 at 10:22 AM, Tomas Lycken <[email protected]>
> wrote:
>         After thinking another few moments about it, I think the
>         confusion might be lifted slightly with some clever use of
>         dispatch. Consider if we'd do something like this:
>         
>         max(itr) # returns the largest element in the collection
>         max(a,b,c...) = max([a,b,c...])
>         
>         max{N}(A,dims::NTuple{N}) # compute maximum element along
>         dimensions
>         max(A,dim::Integer) = max(A, (dim,))
>         max(a::Number, b::Integer) = max([a,b]) # there's probably a
>         more efficient way to do this, to avoid the array allocation
>         
>         
>         Since the last one is more specific than the second to last,
>         there is no longer a conflict between max(A,2) to calculate
>         the maximum of each row of a matrix, and max(a,2) to get the
>         largest value out of a and the integer 2. There might of
>         course be use cases I've forgotten about, but to me this seems
>         to cover most of the use cases and still avoid having to
>         remember two different function names. (I tried to take a look
>         at methods(max) to see if I could find a reason for this not
>         already being the way things were, but I ran into trouble...)
>         
>         
>         // T
>         
>         
>         
>         
>         
>         On Monday, May 5, 2014 3:55:42 PM UTC+2, Stefan Karpinski
>         wrote:
>                 Honestly, I've always been dissatisfied with this
>                 solution and would have preferred the keyword-argument
>                 solution that I proposed back when we were discussing
>                 this. Having lived with the maximum thing for a while
>                 and seen others encounter it, I'm no less
>                 dissatisfied. I still type max when I need maximum
>                 almost every time. 
>                 
>                 
>                 > On May 5, 2014, at 9:36 AM, Billou Bielour
>                 <[email protected]> wrote: 
>                 > 
>                 > I'm not saying that the help is not clear, or that
>                 the behavior is surprising, but only that there no
>                 information in the words "max" and "maximum" that
>                 allows you to guess or remember their behaviors. I
>                 mean one is just the abbreviation of the other. 
>                 > For example if I tell you I have two functions,
>                 "ceil" and "ceiling", can you guess what is the
>                 difference between the two ? 
>                 
> 
> 

Reply via email to