min:max:
Locked
 
|
Hi,
Out of curiosity. I always found the #min:max: confusing and lost in its expressiveness. One should write: 10 min: 48 max: 12 to expect 12. but logically one (at least me) may want to express it as: 10 min: 12 max: 48 Then when reading its source code, it is even more confusing: min: aMin max: aMax ^ (self min: aMin) max: aMax Are not the argument names inversed in their meaning, if any? Hilaire -- Dr. Geo http://drgeo.eu |
|
A name like this would be clearer (although much more annoying): returnAtLeast: minValue butNoMoreThan: maxValue 10 returnAtLeast: 12 butNoMoreThan: 48 Thanks, cbc On Fri, Apr 20, 2018 at 12:51 PM, Hilaire <[hidden email]> wrote: Hi, |
|
|
On April 21, 2018 12:12:10 AM GMT+02:00, Chris Cunningham <[hidden email]> wrote: >A name like this would be clearer (although much more annoying): > >returnAtLeast: minValue butNoMoreThan: maxValue > 10 returnAtLeast: 12 butNoMoreThan: 48 #beBetween:and: or #boundedBetween:and: >Thanks, >cbc > >On Fri, Apr 20, 2018 at 12:51 PM, Hilaire <[hidden email]> wrote: > >> Hi, >> >> Out of curiosity. >> >> I always found the #min:max: confusing and lost in its >expressiveness. >> >> One should write: >> >> 10 min: 48 max: 12 >> >> to expect 12. >> >> but logically one (at least me) may want to express it as: >> >> 10 min: 12 max: 48 >> >> Then when reading its source code, it is even more confusing: >> >> min: aMin max: aMax >> ^ (self min: aMin) max: aMax >> >> Are not the argument names inversed in their meaning, if any? >> >> Hilaire >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> >> |
|
|
In reply to this post by HilaireFernandes
Looking at senders of #min:max:, I found in BitBlt>>roundNumbers the following: destX := destX asInteger min: maxVal max: minVal. Which seems to summarize the illogicality very well. However, note that PetitParser, PetitParser2 and Magritte all implement #min:max: as a method to set upper and lower limits, and there the meaning is the logical one. It all looks a mess. Peter Kenny From: Pharo-users <[hidden email]> On Behalf Of Ben Coman On 21 April 2018 at 03:51, Hilaire <[hidden email]> wrote:
I would agree. I see most use by Color like... Color>>adjustBrightness: brightness "Adjust the relative brightness of this color. (lowest value is 0.005 so that hue information is not lost)" ^ self class h: self hue s: self saturation v: (self brightness + brightness min: 1.0 max: 0.005) alpha: self alpha Trying to read that twists my brain. I can understand the intent from the implementation min: aMin max: aMax ^ (self min: aMin) max: aMax but that message might more properly be #min:thenMax: However something like (self brightness + brightness boundedBy: 0.005 and: 1.0) (self brightness + brightness boundedMin: 0.005 max: 1.0) seems more intention revealing. Altering #min:max semantics would make awful portability, but perhaps it should forward to a new method to make it clear the other is preferred. Would the Squeak community be amenable to a similar change? I'd be happy to contribute the changes to the Squeak Inbox. cheers -ben |
|
|
#beBetween:and: +1. Goes nicely with `(x beBetween: y and: z) between: y and: z` being always true. Peter On Sat, Apr 21, 2018 at 11:56 AM, PBKResearch <[hidden email]> wrote:
|
|
|
In reply to this post by HilaireFernandes
I looked hard at #min:max: some years ago and decided it was way too confusing to ever use. My own library has Magnitude>> median: lower and: upper "I considered adding a method clampedBetween: lower and: upper ^self < lower ifTrue: [lower] ifFalse: [ upper < self ifTrue: [upper] ifFalse: [self]] This sends #< once or twice. The only snag is that it doesn't make much sense unless lower <= upper, and it doesn't check that. Squeak has a method min: min max: max ^(self min: min) max: max which could be simplified to min: min max: max |t| t := min < self ifTrue: [min] ifFalse: [self]. ^max < t ifTrue: [max] ifFalse: [t] The name here is a little confusing. min: x max: y is pretty much the same as clampedBetween: y and: x. This version always does two comparisons, but still makes little or no sense unless min >= max, which it does not check. It would be easy enough for me to add the Squeak method, but I find it far too confusing to use. I wanted a method which gave the same result as clampedBetween:and: whenever that made sense, and which took no more than two comparisons whenever clampedBetween:and: or min:max: would have made sense, but which always makes sense as long as all the arguments are comparable. The answer is simple: the median. Actually, it isn't quite the answer. If the receiver lies between lower and upper, it takes two comparisons. If not, it takes a third comparison to decide which of the two end-points to return, which seems fair enough, because if we don't _assume_ the relative order of the end-points, we have to _find out_." ^self < lower ifTrue: [ "self < lower" self < upper ifFalse: [ "upper <= self < lower" self] ifTrue: [ "self < lower, self < upper" upper < lower ifTrue: ["self < upper < lower" upper] ifFalse: ["self < lower <= upper" lower]]] ifFalse: [ "lower <= self" upper < self ifFalse: [ "lower <= self <= upper" self] ifTrue: [ "lower <= self, upper <= self" upper < lower ifTrue: ["upper < lower <= self" lower] ifFalse: ["lower <= upper <= self" upper]]] That is, (x median: y and: z) returns the middle value, whatever order x y and z are in. On 21 April 2018 at 23:41, Ben Coman <[hidden email]> wrote:
|
|
|
In reply to this post by HilaireFernandes
On Fri, Apr 20, 2018 at 9:51 PM, Hilaire <[hidden email]> wrote:
> Hi, > > Out of curiosity. > > I always found the #min:max: confusing and lost in its expressiveness. > > One should write: > > 10 min: 48 max: 12 I do not understand the result :) To me this method is illnamed. > > to expect 12. > > but logically one (at least me) may want to express it as: > > 10 min: 12 max: 48 > > Then when reading its source code, it is even more confusing: > > min: aMin max: aMax > ^ (self min: aMin) max: aMax > > Are not the argument names inversed in their meaning, if any? > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > > |
|
|
In reply to this post by cbc
Oh yes!!!!
On Sat, Apr 21, 2018 at 12:12 AM, Chris Cunningham <[hidden email]> wrote: > A name like this would be clearer (although much more annoying): > > returnAtLeast: minValue butNoMoreThan: maxValue > 10 returnAtLeast: 12 butNoMoreThan: 48 > > Thanks, > cbc > > On Fri, Apr 20, 2018 at 12:51 PM, Hilaire <[hidden email]> wrote: >> >> Hi, >> >> Out of curiosity. >> >> I always found the #min:max: confusing and lost in its expressiveness. >> >> One should write: >> >> 10 min: 48 max: 12 >> >> to expect 12. >> >> but logically one (at least me) may want to express it as: >> >> 10 min: 12 max: 48 >> >> Then when reading its source code, it is even more confusing: >> >> min: aMin max: aMax >> ^ (self min: aMin) max: aMax >> >> Are not the argument names inversed in their meaning, if any? >> >> Hilaire >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> > |
|
|
> On 21 Apr 2018, at 15:35, Stephane Ducasse <[hidden email]> wrote: > > Oh yes!!!! > > On Sat, Apr 21, 2018 at 12:12 AM, Chris Cunningham > <[hidden email]> wrote: >> A name like this would be clearer (although much more annoying): >> >> returnAtLeast: minValue butNoMoreThan: maxValue >> 10 returnAtLeast: 12 butNoMoreThan: 48 why 'return' ? most methods return something. 10 atLeast: 12 butNoMoreThan: 48 >> Thanks, >> cbc >> >> On Fri, Apr 20, 2018 at 12:51 PM, Hilaire <[hidden email]> wrote: >>> >>> Hi, >>> >>> Out of curiosity. >>> >>> I always found the #min:max: confusing and lost in its expressiveness. >>> >>> One should write: >>> >>> 10 min: 48 max: 12 >>> >>> to expect 12. >>> >>> but logically one (at least me) may want to express it as: >>> >>> 10 min: 12 max: 48 >>> >>> Then when reading its source code, it is even more confusing: >>> >>> min: aMin max: aMax >>> ^ (self min: aMin) max: aMax >>> >>> Are not the argument names inversed in their meaning, if any? >>> >>> Hilaire >>> >>> -- >>> Dr. Geo >>> http://drgeo.eu >>> >>> >>> >> > |
|
|
Yes :)
On Sat, Apr 21, 2018 at 4:21 PM, Sven Van Caekenberghe <[hidden email]> wrote: > > >> On 21 Apr 2018, at 15:35, Stephane Ducasse <[hidden email]> wrote: >> >> Oh yes!!!! >> >> On Sat, Apr 21, 2018 at 12:12 AM, Chris Cunningham >> <[hidden email]> wrote: >>> A name like this would be clearer (although much more annoying): >>> >>> returnAtLeast: minValue butNoMoreThan: maxValue >>> 10 returnAtLeast: 12 butNoMoreThan: 48 > > why 'return' ? most methods return something. > > 10 atLeast: 12 butNoMoreThan: 48 > >>> Thanks, >>> cbc >>> >>> On Fri, Apr 20, 2018 at 12:51 PM, Hilaire <[hidden email]> wrote: >>>> >>>> Hi, >>>> >>>> Out of curiosity. >>>> >>>> I always found the #min:max: confusing and lost in its expressiveness. >>>> >>>> One should write: >>>> >>>> 10 min: 48 max: 12 >>>> >>>> to expect 12. >>>> >>>> but logically one (at least me) may want to express it as: >>>> >>>> 10 min: 12 max: 48 >>>> >>>> Then when reading its source code, it is even more confusing: >>>> >>>> min: aMin max: aMax >>>> ^ (self min: aMin) max: aMax >>>> >>>> Are not the argument names inversed in their meaning, if any? >>>> >>>> Hilaire >>>> >>>> -- >>>> Dr. Geo >>>> http://drgeo.eu >>>> >>>> >>>> >>> >> > > |
|
|
In reply to this post by Richard O'Keefe
But these two does not return the same result.
I don't think the message #min:max: in its self is confusing but more on the its arguments meaning. If implemented as: min: min max: max ^ (self min: max) max: min One could have meaningful message with arguments: 33 min: 12 max: 48. "33" 113 min: 12 max: 48. "48" 1 min: 12 max: 48. "12" For me it will be just fine. There are not so many users of this message. Oh by the way, in P7 there is TComparable traits with this message but Magnitude class is not a user. Hilaire Le 21/04/2018 à 13:55, Richard O'Keefe a écrit : > Squeak has a method > > min: min max: max > ^(self min: min) max: max > > which could be simplified to > > min: min max: max > |t| > t := min < self ifTrue: [min] ifFalse: [self]. > ^max < t ifTrue: [max] ifFalse: [t] -- Dr. Geo http://drgeo.eu |
|
|
In reply to this post by cbc
The #min:max: message is present in the Squeak/Pharo/Cuis familly but
not in GNU Smalltalk for example. No idea about the other ones. Le 21/04/2018 à 00:12, Chris Cunningham a écrit : > A name like this would be clearer (although much more annoying): > > returnAtLeast: minValue butNoMoreThan: maxValue > 10 returnAtLeast: 12 butNoMoreThan: 48 > -- Dr. Geo http://drgeo.eu |
|
|
I can find no reference to #min:max: in Dolphin X6.1.
Peter Kenny -----Original Message----- From: Pharo-users <[hidden email]> On Behalf Of Hilaire Sent: 21 April 2018 17:36 To: [hidden email] Subject: Re: [Pharo-users] min:max: The #min:max: message is present in the Squeak/Pharo/Cuis familly but not in GNU Smalltalk for example. No idea about the other ones. Le 21/04/2018 à 00:12, Chris Cunningham a écrit : > A name like this would be clearer (although much more annoying): > > returnAtLeast: minValue butNoMoreThan: maxValue > 10 returnAtLeast: 12 butNoMoreThan: 48 > -- Dr. Geo http://drgeo.eu |
|
|
On 22 April 2018 at 05:59, PBKResearch <[hidden email]> wrote: I can find no reference to #min:max: in Dolphin X6.1. |
|
|
In reply to this post by HilaireFernandes
Smalltalk/X has both #min:max: and #clampBetween:and: in its Magnitude.st. Dolphin 7 has neither. The definition of #clampBetween:and: in ST/X is clampBetween: min and: max max < self ifTrue: [^max]. self < min ifTrue: [^min]. ^self I've deleted the comment because it doesn't help with the question "what is the CONTRACT for this method?" In particular, you would naturally expect from the name that (x clampBetween: y and: z) between: y and: z Example: 3 clampBetween: 2 and: 1 ==> 1 1 between: 2 and: 1 ==> false On 22 April 2018 at 04:35, Hilaire <[hidden email]> wrote: The #min:max: message is present in the Squeak/Pharo/Cuis familly but not in GNU Smalltalk for example. No idea about the other ones. |
| Free forum by Nabble | Edit this page |