REBOL3 tracker
  0.9.12 beta
Ticket #0001972 User: anonymous


TypeWish Statussubmitted Date27-Feb-2013 01:26
Versionr3 master CategoryMezzanine Submitted byBrianH
PlatformAll Severityminor Prioritynormal

Summary Create new MAXIMUM-OF and MINIMUM-OF functions that do what they say
Description 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.
Example code


Assigned ton/a Fixed in- Last Update17-Apr-2013 02:02

27-Feb-2013 01:50

(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.
27-Feb-2013 02:13

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.
13-Mar-2013 02:04

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.

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]
13-Mar-2013 02:37

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.
13-Mar-2013 02:49

Do any other funcs use /value that way? It seems confusing to me at first glance.
16-Apr-2013 23:16

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.
17-Apr-2013 00:52

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.
17-Apr-2013 01:39

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.
17-Apr-2013 02:02

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.

Date User Field Action Change
17-Apr-2013 02:44 BrianH Comment : 0003836 Modified -
17-Apr-2013 02:02 BrianH Comment : 0003836 Added -
17-Apr-2013 01:39 adrians Comment : 0003835 Added -
17-Apr-2013 00:52 BrianH Comment : 0003833 Added -
16-Apr-2013 23:16 adrians Comment : 0003830 Added -
13-Mar-2013 02:49 Gregg Comment : 0003624 Added -
13-Mar-2013 02:37 BrianH Comment : 0003621 Modified -
13-Mar-2013 02:37 BrianH Comment : 0003621 Added -
13-Mar-2013 02:04 Gregg Comment : 0003620 Added -
27-Feb-2013 02:20 BrianH Comment : 0003525 Modified -
27-Feb-2013 02:15 BrianH Comment : 0003525 Modified -
27-Feb-2013 02:14 BrianH Comment : 0003525 Modified -
27-Feb-2013 02:13 BrianH Comment : 0003525 Added -
27-Feb-2013 01:50 BrianH Comment : 0003524 Added -
27-Feb-2013 01:26 BrianH Ticket Added -