You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#1971 proposes to rename the maximum and minimum finding functions a bit. I am using the present (as of this writing) naming convention in this ticket.
One would expect that there are two equivalent ways how a maximal (or minimal) value of a series can be obtained. The first method uses the maximum (or minimum) finding functions and the second one uses the SORT function picking the last or the first element of the sorted series.
Unfortunately, these methods are not equivalent, these differences are observable:
/skip refinement is available only for SORT
/case refinement is available only for SORT
/compare refinement is available only for SORT
Also, SORT can actually handle any series, while MAXIMUM-OF or MINIMUM-OF functions choke on some series.
A similar problem is observable "under the hood" when checking the compatibility of functions like GREATER? with SORT, which forced me to circumvent the limitations using SORT (not elegant at all, as far as I am concerned).
>>maximum-of [11/1/1961]
** Script error: cannot compare date! with integer!
** Where: greater? forskip maximum-of
** Near: greater? first series first spot [spot: series]
; actual code from test-framework; circumventing the limitations of the LESSER? function:
strict-not-equal? old-test new-test
old-test == second sort/casereduce [new-test old-test]
So, your proposal is to add /skip, /case and /compare options to these functions, compatible with whatever we decide in #428? And make them also compatible with what SORT would do once #1152 is fixed? If so, I'm on board.
Rebolbot commented on Mar 7, 2013:
Submitted by:Ladislav
Yes, that is what I mean, but I would like to see some way how to get the convenient LESSER?, etc. variants as well (case-sensitive comparison with the ability to compare any values)
Rebolbot commented on Mar 7, 2013:
Submitted by:BrianH
Please look at #428, these functions are mentioned explicitly. As alluded to in #428, #1971 and #1972, these functions are so rarely used that they are clearly due for a revamp to make them useful. If they adopt the #428 model then all of your flexibility concerns will be handled, as they will for the set functions and SORT. Added ping-back comments for this ticket in #428.
The text was updated successfully, but these errors were encountered:
Submitted by: Ladislav
#1971 proposes to rename the maximum and minimum finding functions a bit. I am using the present (as of this writing) naming convention in this ticket.
One would expect that there are two equivalent ways how a maximal (or minimal) value of a series can be obtained. The first method uses the maximum (or minimum) finding functions and the second one uses the SORT function picking the last or the first element of the sorted series.
Unfortunately, these methods are not equivalent, these differences are observable:
/skip
refinement is available only for SORT/case
refinement is available only for SORT/compare
refinement is available only for SORTAlso, SORT can actually handle any series, while MAXIMUM-OF or MINIMUM-OF functions choke on some series.
A similar problem is observable "under the hood" when checking the compatibility of functions like GREATER? with SORT, which forced me to circumvent the limitations using SORT (not elegant at all, as far as I am concerned).
Imported from: CureCode [ Version: r3 master Type: Issue Platform: All Category: Unspecified Reproduce: Always Fixed-in:none ]
Imported from: metaeducation#1988
Comments:
Submitted by: BrianH
So, your proposal is to add /skip, /case and /compare options to these functions, compatible with whatever we decide in #428? And make them also compatible with what SORT would do once #1152 is fixed? If so, I'm on board.
Submitted by: Ladislav
Yes, that is what I mean, but I would like to see some way how to get the convenient LESSER?, etc. variants as well (case-sensitive comparison with the ability to compare any values)
Submitted by: BrianH
Please look at #428, these functions are mentioned explicitly. As alluded to in #428, #1971 and #1972, these functions are so rarely used that they are clearly due for a revamp to make them useful. If they adopt the #428 model then all of your flexibility concerns will be handled, as they will for the set functions and SORT. Added ping-back comments for this ticket in #428.
The text was updated successfully, but these errors were encountered: