- Pharo-users - lists.pharo.org

Re: Updating lists.pharo.org: New server, Mailman3 and more

by Offray Vladimir Luna CÃ¡rdenas

+100^100. As Susan Leigh Star said, infrastructure is invisible until it fails. So all the work behind the invisible to keep it running, lean and smooth is really important. Offray On 15/09/20 3:06 a.Â m., Sven Van Caekenberghe wrote: > >> On 14 Sep 2020, at 17:46, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Marcus Denker-4 wrote >>> We are updating the mailinglists (everything https://lists.pharo.org/ >>> <https://lists.pharo.org/>) >> Thanks, Marcus - all this logistical stuff gets no glory but is so important >> :) > +100 > > Indeed, thank you, Marcus ! > >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 15, 2020

Re: how can I improve this

by Roelof Wobben

Sept. 15, 2020

Re: how can I improve this

by Roelof Wobben

Sept. 15, 2020

Re: how can I improve this

by Richard O'Keefe

SequenceableCollection has with:do:. Add with: other count: testBlock |r| r := 0. self with: other do: [:x :y | (testBlock value: x value: y) ifTrue: [r := r + 1]]. ^r I have this in my library anyway. Now distanceStrand1: a strand2: b ^a with: b count: [:x :y | x ~= y] #with:do: already checks that the sequences have the same size; it's too confusing if the error reported in this case is different from the error for #with:do:. On Tue, 15 Sep 2020 at 16:59, Roelof Wobben via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Op 14-9-2020 om 22:19 schreef HernÃ¡n Morales Durand: > > ^ (1 to: self size) count: [ : i | (self at: i) ~= (aString at: i) ] > > > > With that code I get a few problems but this is working > > distanceStrand1: aString strand2: aString2 > aString size == aString2 size > ifFalse: [ DomainError signal: (self messageFor: aString strand2: > aString2) ]. > ^ (1 to: aString size) > count: [ :i | (aString2 at: i) ~= (aString at: i) ] > > Roelof > > >

Sept. 15, 2020

Re: Rounding in Floats

by Richard O'Keefe

If you are going to use floating point numbers in any programming language, Pharo included, you need to understand something about them. Things like - the relevant precision is *fixed*; a Float in Pharo is *always* a 64-bit IEEE floating-point number, which amongst other things means (to a first approximation) 54 binary digits of precision. It doesn't make the slightest amount of difference how many decimal digits you use when writing the number, the precision is *always* 54 binary digits. So you *did* get the precision out of rounding that you put in, it's just that the precision you put in was not what you thought it was. - almost all modern architectures offer BINARY arithmetic, not decimal. (The main exceptions are IBM z/series and IBM POWER, which offer binary *and* decimal.) Rounding a number to n decimals is ALWAYS problematic using binary floats. This has little or nothing to do with Smalltalk: it's the hardware. (This is why you are advised to keep money in cents, not dollars.) - Again, this is NOT a language issue, it is a hardware issue. IF you understand how binary floating point arithmetic works, then the arithmetic you get in C or R or Smalltalk or Matlab does not surprise you at all. If you DON'T understand how binary floating point arithmetic works, the hardware will *get* you sooner or later. - ScaledDecimal in Pharo didn't have to violate the principle of least surprise, but it does, big time. - It would be really nice if Pharo offered true decimal arithmetic as an option. There may already be a package for this. On Tue, 8 Sep 2020 at 15:46, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > On Tue, Sep 8, 2020 at 12:16 AM Richard O'Keefe <raoknz(a)gmail.com> wrote: > > > > "7.1 roundTo: 0.1 should return 7.1" > > You're still not getting it. > > I was until Konrad explained it. > > > Binary floating point CANNOT represent either of those numbers. > > You seem to be assuming that Pharo is making some mistake. > > It isn't. All it is doing is refusing to lie to you. > <snip> > > The systems that print 7.1 are LYING to you, > > and Pharo is not. > > I'm not assuming a mistake from Pharo, I had a wrong expectation what > to get if I round to that precision. > I don't know whether other systems lie or simply fulfill user > expectations, if you send the #roundTo: to a float, I did expect to > get a number with the same precision. > That is my expectation as a user. As in the other thread I expected > two scaled decimals that are printed equal to also be compared as > equal (which they don't). > > Whether there is a good reason for those behaviors is beyond my > current comprehension, but it certainly doesn't follow the "principle > of least surprise". > > In any case, the method proposed by Tomohiro solved my issues. > > Regards, > > Esteban A. Maringolo > >

Sept. 15, 2020

Re: How can I make this more OOP

by Richard O'Keefe

I take Sean's point. However, while I agree that practising using polymorphism instead of 'if' is a good idea, I don't think that *this* exercise is a good one for getting such practice. Roelof is going through the Pharo track of Exercism. This particular one is called 'flatten-array'. The one concession to "hey, this is Pharo!" in the description of the exercise is a veiled warning against using Pharo's #flattened/#flattenOn:, which (a) does not add anything to Object or UndefinedObject (just Collection>>flattened and Collection>>flattenOn:) (b) does not make a special case of nil (c) DOES make a special case of strings, treating them as atomic. Possibly the most challenging part for me in this exercise was trying to figure out "what does <list> mean for Smalltalk here?" In Pharo's existing #flattened, why does a String count as atomic but a Semphore is just another collection? This is a Lisp programming exercise from the early 1960s. It had unpleasant ambiguities back then and it has not got better since. If this were rewritten as "Make a Composite implementation of binary search trees with a class for empty trees, a class for non-empty ones, and perhaps a class for singleton ones. Implement #do:, traversing the elements in increasing order. Use this to implement #asOrderedCollection." then that *would* be a good exercise for using polymorphism instead of conditionals. BST () asOrderedCollection ^OrderedCollection new in: [:coll | self do: [:each | coll addLast: each]. coll] EmptyBST () do: aBlock "Nothing to do." NonemptyBST (less key greater) do: aBlock less do: aBlock. aBlock value: key. greater do: aBlock. On Tue, 15 Sep 2020 at 18:33, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Richard O'Keefe wrote > > Whatever else it is, OOP is a means to an end, not an end in itself. > > It's not a religion. > > Richard makes an important point here. > > As I mentioned on Discord (slightly edited to fit this thread), itâs a > judgment call with trade-offs, but for the purposes of an OOP exercise, I > would say absolutely put the methods in object and wherever else you may > need them - if only to get practice with that particular idiom. I needed to > do a lot of that sort of thing - probably way *too* much, just to break my > procedural thinking habits. Once I got it "in my bones" I became more > pragmatic. While in theory, this may always be the âmostâ OOP way, in > practice it can be confusing due to the limitations of our system > organization and the fact that people will have to scroll through more > methods on kernel objects (not to mention the extra dependencies Richard > noted). That is the dogma, and I think is a fine answer for an OOP > exercise, > but IMHO in practice there are justifiable exceptions. The two major axes > are understandability and adaptability. If in your domain there are only > two > choices and there can not logically be more, it may be easier to understand > one method with a conditional that documents that domain fact, than it > would > be to dive down a polymorphism rabbit hole spread across the system. Of > course, tooling is a big factor in understandability. In GT it may be > trivial because you can open implementors in a plane right next to the code > browser. Different toolsets themselves mean different trade offs. There are > no one size fits all answers for all time. There are principles that have > to > be negotiated with your current environment, use case, experience level, > team size... > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Sept. 15, 2020

Re: Updating lists.pharo.org: New server, Mailman3 and more

by Sven Van Caekenberghe

> On 14 Sep 2020, at 17:46, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Marcus Denker-4 wrote >> We are updating the mailinglists (everything https://lists.pharo.org/ >> <https://lists.pharo.org/>) > > Thanks, Marcus - all this logistical stuff gets no glory but is so important > :) +100 Indeed, thank you, Marcus ! > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 15, 2020

Re: Updating lists.pharo.org: New server, Mailman3 and more

by Serge Stinckwich

Marcus, big ð On Tue, 15 Sep 2020 at 14:33, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Marcus Denker-4 wrote > > We are updating the mailinglists (everything https://lists.pharo.org/ > > <https://lists.pharo.org/>) > > Thanks, Marcus - all this logistical stuff gets no glory but is so > important > :) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > -- Serge Stinckwic âhâ https://twitter.com/SergeStinckwich â

Sept. 15, 2020

Re: how can I improve this

by Roelof Wobben

Sept. 15, 2020

Re: how can I improve this

by Roelof Wobben

Sept. 14, 2020