September 2020 - Pharo-users

Re: [Pharo-users] CV/OCR Library

by Tudor Girba

Hi, Indeed, we have an integration for OpenCV here: https://github.com/feenkcom/gt4opencv Cheers, Doru > On Aug 31, 2020, at 4:14 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > I know that there is an openCV binding by https://twitter.com/DmitryMatveev > You have a binding in GT too. > > >> On 31 Aug 2020, at 14:40, Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> >> Hi, >> >> Does anybody know if there is an OCR or some CV library available for Pharo? >> >> I would like to make an experiment with recognizing the content of >> some fixed size form, and of course I prefer to do it with Smalltalk >> whenever possible. >> >> Regards! >> >> Esteban A. Maringolo >> > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > -- feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."

Sept. 1, 2020

Re: mentoring contined I hope

by Roelof Wobben

Sept. 1, 2020

Re: mentoring contined I hope

by Roelof Wobben

Op 1-9-2020 om 21:11 schreef Richard Sargent: > You will discover an error when you write your tests, but that's fine. > It's why you write tests. :-) > > #validateTime:minute: is a poor name choice for a few reasons. > - there is no validation going on. Validation would report an error > for invalid data. > - there is nothing to suggest what the first argument is, the > counterpart to "minute:". > - it doesn't suggest there will be a new Time ("Clock") created. > - it's a "verb phrase" saying it will *do* something rather than > answer something (I'm being vague here. Sorry.) > > I suggest #normalizedForHour:minute:. > It explains that it will normalize the values and that it will answer > a normalized result (it still isn't great, as it doesn't explain what). > Perhaps better would be #newNormalizedForHour:minute:. > > Thanks, I think I found the error and solved it hour: anInteger minute: anInteger2 Â Â Â ^ self new Â Â Â Â Â Â hour: (anInteger2 // 60 + anInteger) % 24; Â Â Â Â Â Â minute: anInteger2 % 60; Â Â Â Â Â Â yourself instance side : printOn: aStream Â Â Â ^ aStream Â Â Â Â Â Â nextPutAll: self hour asTwoCharacterString; Â Â Â Â Â Â nextPut: $:; Â Â Â Â Â Â nextPutAll: self minute asTwoCharacterString and the tests are green now time to sleep and tomorrow time to figure out how to add and substract minutes. As I remember it right you gave already the answer to me somewhere in our conversation Roelof I

Sept. 1, 2020

Re: [Pharo-users] mentoring contined I hope

by Richard Sargent

"self is a Clock" is an imprecise statement. Did you mean that it is *an instance of* the Clock class or that it is *the *Clock class itself? On Tue, Sep 1, 2020 at 10:33 AM Roelof Wobben <r.wobben(a)home.nl> wrote: > Op 1-9-2020 om 19:21 schreef Richard Sargent: > > What is the value of *self* when the error occurred? The debugger should > show you this. > > > > self is a Clock > >

Sept. 1, 2020

Re: mentoring contined I hope

by Roelof Wobben

Sept. 1, 2020

Re: [Pharo-users] mentoring contined I hope

by Richard Sargent

What is the value of *self* when the error occurred? The debugger should show you this. Another way to determine this is to look at the code and think about where the sending method is implemented and where the invoked method is implemented (assuming that there really is one). On Tue, Sep 1, 2020 at 10:11 AM Roelof Wobben <r.wobben(a)home.nl> wrote: > oke, then I would work with hour and minutes as the challenge wanted, > > So still on the class side make code that convert any given hour and >> minute to a valid one ? >> > > Yes. Such code would also be used when doing arithmetic with Times. e.g. > if you were to implement an instance method named #addMinutes:, its > implementation would be as simple as ^Time hours: self hours minutes: self > minutes + anInteger (assuming the argument has that name). The instance > creation method would normalize the new requested time, just like Time > hours: 0 minutes: 70 would do. > >> >> Roelof >> >> > > On some way I think or I do something wrong or I did misunderstood you. > > I did this in Pharo > > Object subclass: #Clock > instanceVariableNames: 'hour minute' > classVariableNames: '' > package: 'Exercise@Clock' > > I made a asscesors on the instance side. > > then I did this on the class side : > > hour: anInteger minute: anInteger2 > self hour: anInteger2 % 60 + anInteger; > self minute: anInteger2 / 60; > yourself. > > but I see a message that hour and minutes are not known. > > Roelof > >

Sept. 1, 2020

Re: mentoring contined I hope

by Roelof Wobben

Sept. 1, 2020

Re: [Pharo-users] Scaled decimals comparisons

by StÃ©phane Ducasse

Hi john you can propose for inclusion in pharo. - Add a nice comment (with executablecomments would be a plus). - Possibly some tests - Send a PR. > On 1 Sep 2020, at 09:32, John Aspinall <john.aspinall(a)gmail.com> wrote: > > Dolphin shows the same behaviour. I added the following method to ScaledDecimal to help: > > roundedByScale > > | scaleFactor | > > scaleFactor := 10 ** scale. > > ^(ScaledDecimal newFromNumber: (fraction * scaleFactor) rounded scale: scale) / scaleFactor > > > Translating slightly for Pharo: > > roundedByScale > > | scaleFactor | > > scaleFactor := 10 ** scale. > > ^(ScaledDecimal newFromNumber: (self * scaleFactor) rounded scale: scale) / scaleFactor > > > You can then do: > > (82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1) roundedByScale = 9.5s1 "true" > > > HTH. > > John > > > > > > > >> On 1 Sep 2020, at 05:17, Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> >> As a follow up to this, adding a roundTo: before converting into a >> ScaledDecimal does not work. >> >> (((91 - (2 * 35.9) - (0 / 2) * (113/121)) roundTo: 0.1) >> asScaledDecimal: 1) = 17.9s1 >> >> So how do you compare two ScaledDecimals that _should_ be the same? >> >> Regards! >> >> Esteban A. Maringolo >> >> On Tue, Sep 1, 2020 at 1:07 AM Esteban Maringolo <emaringolo(a)gmail.com> wrote: >>> >>> Hi, >>> >>> I was doing some basic calculations based on a formula, and I wanted >>> to convert the result to a scaled decimal in order to avoid having >>> these "loose" decimals in 10th position or something similar. >>> >>> So I did the following: >>> 82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1 -> 9.5s1 >>> >>> But When I do this in a test: >>> (82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1) = 9.5s1 >>> >>> It fails because the comparison returns false. >>> >>> I guess this is the proper behavior, but I'd expected that the >>> conversion from a Float to a scaled decimal would have eliminated the >>> extra precision from the formula. >>> >>> I can do a roundTo: 0.1 before converting, but I'd like to know what >>> would be the proper way of dealing with this. >>> >>> Thanks! >>> >>> Esteban A. Maringolo >> > > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Sept. 1, 2020

Re: [Pharo-users] Scaled decimals comparisons

by Esteban Maringolo

Hi John, I was doing a similar rounding in the test assertion, I think your method is better and broadly usable (and maybe convenient for an #equals: implementation). Thanks! Esteban A. Maringolo On Tue, Sep 1, 2020 at 4:33 AM John Aspinall <john.aspinall(a)gmail.com> wrote: > > Dolphin shows the same behaviour. I added the following method to ScaledDecimal to help: > > roundedByScale > > | scaleFactor | > > scaleFactor := 10 ** scale. > > ^(ScaledDecimal newFromNumber: (fraction * scaleFactor) rounded scale: scale) / scaleFactor > > > Translating slightly for Pharo: > > roundedByScale > > | scaleFactor | > > scaleFactor := 10 ** scale. > > ^(ScaledDecimal newFromNumber: (self * scaleFactor) rounded scale: scale) / scaleFactor > > > You can then do: > > (82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1) roundedByScale = 9.5s1 "true" > > > HTH. > > John > > > > > > > > > On 1 Sep 2020, at 05:17, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > > > As a follow up to this, adding a roundTo: before converting into a > > ScaledDecimal does not work. > > > > (((91 - (2 * 35.9) - (0 / 2) * (113/121)) roundTo: 0.1) > > asScaledDecimal: 1) = 17.9s1 > > > > So how do you compare two ScaledDecimals that _should_ be the same? > > > > Regards! > > > > Esteban A. Maringolo > > > > On Tue, Sep 1, 2020 at 1:07 AM Esteban Maringolo <emaringolo(a)gmail.com> wrote: > >> > >> Hi, > >> > >> I was doing some basic calculations based on a formula, and I wanted > >> to convert the result to a scaled decimal in order to avoid having > >> these "loose" decimals in 10th position or something similar. > >> > >> So I did the following: > >> 82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1 -> 9.5s1 > >> > >> But When I do this in a test: > >> (82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1) = 9.5s1 > >> > >> It fails because the comparison returns false. > >> > >> I guess this is the proper behavior, but I'd expected that the > >> conversion from a Float to a scaled decimal would have eliminated the > >> extra precision from the formula. > >> > >> I can do a roundTo: 0.1 before converting, but I'd like to know what > >> would be the proper way of dealing with this. > >> > >> Thanks! > >> > >> Esteban A. Maringolo > > > >

Sept. 1, 2020

Re: [Pharo-users] Scaled decimals comparisons

by Esteban Maringolo

It evaluates to false in VW too. I guess it is a matter of internal representation, since ScaledDecimals/FixedPoints are a Fraction after all. What is weird, and I'd say wrong (at least from the UX perspective) is that in Pharo (and Dolphin): ((91 - (2 * 35.9) - (0 / 2) * (113/121)) roundTo: 0.1) -> 17.900000000000002 While in VW and VAST they round the float properly: ((91 - (2 * 35.9) - (0 / 2) * (113/121)) roundTo: 0.1) -> 17.9 Regards! Esteban A. Maringolo On Tue, Sep 1, 2020 at 1:24 AM jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: > > Interesting. Your expression evaluates to true in VA Smalltalk. > > > Am 01.09.20 um 06:17 schrieb Esteban Maringolo: > > As a follow up to this, adding a roundTo: before converting into a > > ScaledDecimal does not work. > > > > (((91 - (2 * 35.9) - (0 / 2) * (113/121)) roundTo: 0.1) > > asScaledDecimal: 1) = 17.9s1 > > > > So how do you compare two ScaledDecimals that _should_ be the same? > > > > Regards! > > > > Esteban A. Maringolo > > > > On Tue, Sep 1, 2020 at 1:07 AM Esteban Maringolo <emaringolo(a)gmail.com> wrote: > >> Hi, > >> > >> I was doing some basic calculations based on a formula, and I wanted > >> to convert the result to a scaled decimal in order to avoid having > >> these "loose" decimals in 10th position or something similar. > >> > >> So I did the following: > >> 82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1 -> 9.5s1 > >> > >> But When I do this in a test: > >> (82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1) = 9.5s1 > >> > >> It fails because the comparison returns false. > >> > >> I guess this is the proper behavior, but I'd expected that the > >> conversion from a Float to a scaled decimal would have eliminated the > >> extra precision from the formula. > >> > >> I can do a roundTo: 0.1 before converting, but I'd like to know what > >> would be the proper way of dealing with this. > >> > >> Thanks! > >> > >> Esteban A. Maringolo > > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > >

Sept. 1, 2020