- Pharo-users - lists.pharo.org

Re: [Pharo-users] min:max:

by Sven Van Caekenberghe

> On 21 Apr 2018, at 15:35, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Oh yes!!!! > > On Sat, Apr 21, 2018 at 12:12 AM, Chris Cunningham > <cunningham.cb(a)gmail.com> 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 <hilaire(a)drgeo.eu> 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 >>> >>> >>> >> >

April 21, 2018

Re: [Pharo-users] min:max:

by Stephane Ducasse

Oh yes!!!! On Sat, Apr 21, 2018 at 12:12 AM, Chris Cunningham <cunningham.cb(a)gmail.com> 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 <hilaire(a)drgeo.eu> 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 >> >> >> >

April 21, 2018

Re: [Pharo-users] min:max:

by Stephane Ducasse

On Fri, Apr 20, 2018 at 9:51 PM, Hilaire <hilaire(a)drgeo.eu> 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 > > >

April 21, 2018

Re: [Pharo-users] #(foo bar baz) min

by Stephane Ducasse

Hi richard do you have some tests around? Stef On Sat, Apr 21, 2018 at 3:07 PM, Richard O'Keefe <raoknz(a)gmail.com> wrote: > #('a' 'b' 'c') min > also fails on the grounds that ByteStrings don't understand #min:. > What's worse is that ByteString and ByteSymbol *do* have #max:, > but it's something quite different (and arguably broken). > > max: aBlock > | max | > self ifEmpty: [ ^ nil ]. > max := aBlock value: self first. > self > allButFirstDo: > [ :each | > | value | > value := aBlock value: each. > max := max max: value ]. > ^ max > > It would be better if the TComparable #min: and #max: > were available and the current #max: renamed to something else. > I have this in an extension to GNU Smalltalk: > > Collection extend [ > collect: collectBlock thenFold: foldBlock [ > |started result| > started := result := nil. > self do: [:each | |v| > v := collectBlock value: each. > result := started ifNil: [started := self. v] > ifNotNil: [foldBlock value: result value: v]]. > ^started ifNil: [SystemExceptions.EmptyCollection signalOn: self] > ifNotNil: [result] > ] > > collectThenMin: collectBlock [ > ^self collect: collectBlock thenFold: [:acc :y | acc min: y] > ] > min [ > ^self collectThenMin: [:each | each] > ] > > collectThenMax: collectBlock [ > ^self collect: collectBlock thenFold: [:acc :y | acc max: y] > ] > max [ > ^self collectThenMax: [:each | each] > ] > ] > > CharacterArray extend [ > max: other [ > ^self < other ifTrue: [other] ifFalse: [self] > ] > > min: other [ > ^self < other ifTrue: [self] ifFalse: [other] > ] > ] >

April 21, 2018

Re: [Pharo-users] #(foo bar baz) min

by Richard O'Keefe

#('a' 'b' 'c') min also fails on the grounds that ByteStrings don't understand #min:. What's worse is that ByteString and ByteSymbol *do* have #max:, but it's something quite different (and arguably broken). max: aBlock | max | self ifEmpty: [ ^ nil ]. max := aBlock value: self first. self allButFirstDo: [ :each | | value | value := aBlock value: each. max := max max: value ]. ^ max It would be better if the TComparable #min: and #max: were available and the current #max: renamed to something else. I have this in an extension to GNU Smalltalk: Collection extend [ collect: collectBlock thenFold: foldBlock [ |started result| started := result := nil. self do: [:each | |v| v := collectBlock value: each. result := started ifNil: [started := self. v] ifNotNil: [foldBlock value: result value: v]]. ^started ifNil: [SystemExceptions.EmptyCollection signalOn: self] ifNotNil: [result] ] collectThenMin: collectBlock [ ^self collect: collectBlock thenFold: [:acc :y | acc min: y] ] min [ ^self collectThenMin: [:each | each] ] collectThenMax: collectBlock [ ^self collect: collectBlock thenFold: [:acc :y | acc max: y] ] max [ ^self collectThenMax: [:each | each] ] ] CharacterArray extend [ max: other [ ^self < other ifTrue: [other] ifFalse: [self] ] min: other [ ^self < other ifTrue: [self] ifFalse: [other] ] ]

April 21, 2018

Re: [Pharo-users] [squeak-dev] min:max:

by Richard O'Keefe

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 <btc(a)openinworld.com> wrote: > > > On Sat, 21 Apr 2018, Ben Coman wrote: >> >> On 21 April 2018 at 03:51, Hilaire <hilaire(a)drgeo.eu> 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? >>> >>> >>> 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. >>> >> > On 21 April 2018 at 17:56, Levente Uzonyi <leves(a)caesar.elte.hu> wrote: > >> Squeak has #clampLow:high: for this reason. >> >> > Thanks Levente. Thats a good one. > With similar usage clamping signals in electronics, this is worthwhile to > adopt. > > https://pharo.fogbugz.com/f/cases/21758/Replace-min-max-with-clampLow-High > > cheers -ben > >

April 21, 2018

Re: [Pharo-users] [squeak-dev] min:max:

by Ben Coman

On Sat, 21 Apr 2018, Ben Coman wrote: > > On 21 April 2018 at 03:51, Hilaire <hilaire(a)drgeo.eu> 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? >> >> >> 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. >> > On 21 April 2018 at 17:56, Levente Uzonyi <leves(a)caesar.elte.hu> wrote: > Squeak has #clampLow:high: for this reason. > > Thanks Levente. Thats a good one. With similar usage clamping signals in electronics, this is worthwhile to adopt. https://pharo.fogbugz.com/f/cases/21758/Replace-min-max-with-clampLow-High cheers -ben

April 21, 2018

Re: [Pharo-users] Proper way to file in code

by Sven Van Caekenberghe

> On 21 Apr 2018, at 13:18, Hilaire <hilaire(a)drgeo.eu> wrote: > > Not in my working P7 image. Is it a recent change? Yes, relatively recent, weeks I guess, maybe a month, at least since half March. FileSystem (part of the image for ages), File and new streams (most also long part of the image) are the replacements. BTW, I meant [Abstract]FileReference>>#fileIn which is a unary selector. > Hilaire > > > Le 21/04/2018 Ã 13:01, Sven Van Caekenberghe a Ã©crit : >> The whole of FileStream is deprecated in P7, use [Abstract]FileReference>>#fileIn: > > -- > Dr. Geo > http://drgeo.eu > > >

April 21, 2018

Re: [Pharo-users] Proper way to file in code

by Hilaire

Not in my working P7 image. Is it a recent change? Hilaire Le 21/04/2018 Ã 13:01, Sven Van Caekenberghe a Ã©critÂ : > The whole of FileStream is deprecated in P7, use [Abstract]FileReference>>#fileIn: -- Dr. Geo http://drgeo.eu

April 21, 2018

Re: [Pharo-users] Proper way to file in code

by Sven Van Caekenberghe

> On 21 Apr 2018, at 10:34, Hilaire <hilaire(a)drgeo.eu> wrote: > > Hi, > > To use Smalltalk sketch scripts for additional unit tests, I need to file in these script files. > > I found FileStream>>fileIn: does the job. Is it the proper way to do it? The whole of FileStream is deprecated in P7, use [Abstract]FileReference>>#fileIn: > Thanks > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > >

April 21, 2018