|Version||r3 master||Category||Unspecified||Submitted by||Ladislav|
|Summary||Incompatibility between maximum-searching and sorting|
#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 [1 1/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/case reduce [new-test old-test]
|Assigned to||n/a||Fixed in||-||Last Update||8-Mar-2013 11:35|
|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.|
|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)|
|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.|
|7-Mar-2013 20:24||BrianH||Comment : 0003593||Modified||-|
|7-Mar-2013 19:00||BrianH||Comment : 0003593||Modified||-|
|7-Mar-2013 18:56||BrianH||Comment : 0003593||Added||-|
|7-Mar-2013 18:26||Ladislav||Comment : 0003592||Modified||-|
|7-Mar-2013 18:24||Ladislav||Comment : 0003592||Added||-|
|7-Mar-2013 17:55||BrianH||Comment : 0003589||Added||-|