Create new MAXIMUM-OF and MINIMUM-OF functions that do what they say

[rebolbot]

Submitted by: BrianH

As mentioned in #1971, MAXIMUM-OF and MINIMUM-OF don't actually return the maximum or minimum of a series, they return the series at the position of the maximum or minimum. We need functions that actually return the maximum or minimum values, or when /skip is used, a shallow copy of the maximum or minimum records.

The existing functions would be renamed (see #1971). See also #428 for issues related to combining /skip and /compare refinements, which would likely apply to these functions as well.

^{CC - Data [ Version: r3 master Type: Wish Platform: All Category: Mezzanine Reproduce: Always Fixed-in:none ]}

[rebolbot]

Submitted by: BrianH

(From Bo in SO chat):

I'd be more inclined to have refinements of 'find-max and 'find-min. Which is the expected behavior? If it is to return the position, then maybe have 'find-max for the position and 'find-max/value for the value. If it is to return the value, then have 'find-max for the value and 'find-max/pos for the position.

I think it is better to keep the name-space less cluttered by using refinements to expound on mezzanines of like functionality.

[rebolbot]

Submitted by: BrianH

Firstly, the purpose of FIND-MAX and FIND-MIN (#1971) would be to return the position, and of this proposal to return the value. So the alternative would be to make these functions a /value option for FIND-MAX and FIND-MIN.

As for "like functionality", I was thinking that these functions would actually call FIND-MAX and FIND-MIN to find the position of their results, then call FIRST or COPY/part on the results, depending on whether the /skip option was used.

The main reason that you would want to make MAXIMUM-OF and MINIMUM-OF functions for this would be to prevent developers from writing code like this in the spirit of R2-compatibility:

    maximum-of: :find-max
    minimum-of: :find-min

Those names are bad for those functions (see #1818), and we want them to not be used for those functions going forward. Having them be used for different functions would help solve that problem. Leave the old names in a backwards-compatibility module.

As a benefit though, if these functions remain mezzanine then having wrapper functions might be faster at runtime. If you use wrapper functions or different functions then the choice of which behavior to do is made at development time. If we make it a function option then the overhead of choosing which behavior to do is done at runtime, and for mezzanines that overhead can be relatively expensive. A mezzanine function has to do a lot to make it worth adding a lot of options. Composition of simple functions can be faster.

This is not as much the case with native functions because options processing is less expensive. If FIND-MAX and FIND-MIN are made native, adding a /value option instead would make a lot of sense. Perhaps even enough sense to give up on preempting the use of the MAXIMUM-OF and MINIMUM-OF names.

[rebolbot]

Submitted by: Gregg

First, is there a reason not to use "max" instead of "maximum", whatever the final name formation turns out to be?

A *-MAX convention will make things easy to find, but may need thought if we want to do more with them. My wrappers to do collection and filtering are just separate funcs today, where refinements may be a better way to go.

<pre>
pick-max: func [series [series!]] [pick maximum-of series 1]
pick-min: func [series [series!]] [pick minimum-of series 1]
take-max: func [series [series!]] [take maximum-of series]
take-min: func [series [series!]] [take minimum-of series]
</pre>

[rebolbot]

Submitted by: BrianH

Actually, the only benefit of using the names MAXIMUM-OF and MINIMUM-OF at all is to make sure we displace their old meanings. Otherwise, it makes more sense to make these into /value options of FIND-MAX and FIND-MIN, and likely reject this ticket.

[rebolbot]

Submitted by: Gregg

Do any other funcs use /value that way? It seems confusing to me at first glance.

[rebolbot]

Submitted by: adrians

I would really not like maximum-of/value for something that really should really be max (this is one of those functions where short is sweet and clear). IMO, limiting the arity of a function like max to 2 doesn't make sense.

[rebolbot]

Submitted by: BrianH

So instead you suggest that MAX have an arity of 1, and have that 1 be the result of a REDUCE for it to be used as it is now, with all of that extra overhead? So what would you suggest be the low-level maximum that MAX is now? Remember, Rebol isn't Clojure, we only have fixed-arity functions, and faking variable-arity functions using a block parameter takes overhead if the parameters are meant to be expressions. MAX is a low-level function, like ADD, and gets its speed from being low-overhead. This is the same reason that ADD doesn't take a block parameter.

[rebolbot]

Submitted by: adrians

Let me try to restate what I really meant. Getting the maximum of a number of items greater than 2 is a very useful function. I'd wager it could be more useful and frequently used when using a functional style than the 2-arity one in practice, and so, for convenience and brevity, the name should be the pretty much the same length as the binary function, max.

[rebolbot]

Submitted by: BrianH

Weirdly enough, we've found that while getting the maximum of 2 values (the existing MAX) is used pretty often in Rebol, getting the maximum of a more than 2 values in a block is actually not commonly done. The main reason is that the more-than-2-values collection has to come from somewhere, and in Rebol that usually means a prebuilt block or an intermediate block. Needing to find the maximum value of a prebuilt block is pretty rare. Wanting to generate the intermediate block in order to find the maximum of more than 2 expressions is even more rare, because it is more efficient to chain calls to the 2-values MAX without generating intermediate blocks.

If these functions were commonly used, we wouldn't be as free to change them.