- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] roundTo: strange behavior

by test

Hi Nicolas, yes, i know. suppose you calc some financial thing and one intermediate result will be in $. you have to round this Fraction-result to 2 decimals. now you use this to further calc basepoints as the final result. you have to convert this to 3 decimals. looking at this final result with 2 decimals can be be irritating for a moment, if you debug the calcs. and <g> btw i never use scaledDecimals. werner On 10/26/2016 02:06 PM, Nicolas Cellier wrote: > > > 2016-10-26 13:11 GMT+02:00 test <wkassens(a)libello.com > <mailto:wkassens@libello.com>>: > > Hi Nicolas, > regarding rounding Fractions: > i use fractions if i want to get an exact result (eg for comparing > the result with Float calculations). if #round: returns a Float > all further calcs (with Fractions) will get contaminated, since > the rest will become Floats too. Hence the "asScaledDecimal: > numberOfWishedDecimal" seems better to me, but i wonder why these > transformations at the end are necessary at all? just for the > looks? i'd suppose every person, who knows how to use Fractions, > also knows how to append a #asScaledDecimal: to a result by > himself, should he want that. > > taking as an example financial calcs that first use 2 decimals. > occasionaly the final result will be basepoints, often small ones > like 0.003. with scaledDecimals the result would be (ok, look > like) 0 since scaledDecimals also contaminate the calc. of course > one could correct this simply with an #asScaledDecimal:3 at the > end. nevertheless a first look at the zero result would surprise > me for a tenth of a second. > werner > > > Hi Werner, > I don't know the purpose of round: at all. > Most often this kind of message was used before printing probably > because lack of versatile formatted print messages. > In Squeak I replaced most usages of roundTo: by > printShowing(Max)DecimalPlaces:. > Now if it has been added in Pharo and other languages, there must be > some use cases I presume. > Maybe the analysis could be carried on these use cases? > > Beware, converting a Fraction asScaledDecimal will NOT round. > Only the printString is rounded, but the number keeps its whole precision. > Example (1/3 asScaledDecimal: 1)*3 = 1.0s, not 0.9s. > > ScaledDecimals as they are now are just Fraction with a different > printString... > Not very much added value. > > Nicolas > > On 10/26/2016 09:58 AM, Nicolas Cellier wrote: >> >> >> 2016-10-26 9:14 GMT+02:00 stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>>: >> >> Hi nicolas >> >> So what is the solution? We can integrate fast a solution. >> I would really like to see them fix in Pharo 60. >> I'm writing a book for newbie and this is the third time I >> change one chapter >> so may be I should stop and throw away this chapter. >> >> >> 1) for Fraction: >> >> round: numberOfWishedDecimal >> v := 10 raisedTo: numberOfWishedDecimal. >> ^ ((self * v) rounded / v) asFloat >> >> or just replace asFloat if you wish to remain exact: >> >> round: numberOfWishedDecimal >> v := 10 raisedTo: numberOfWishedDecimal. >> ^ ((self * v) rounded / v) asScaledDecimal: numberOfWishedDecimal >> >> 2) for Float, it is in 15471: >> >> round: numberOfWishedDecimal >> | v maxNumberOfDecimals | >> maxNumberOfDecimals := self class precision - 1 - (self >> exponent max: self class emin). >> maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self]. >> v := 10 raisedTo: numberOfWishedDecimal. >> ^ ((self asFraction * v) rounded / v) asFloat >> >> or if Fraction already answers a Float: >> >> round: numberOfWishedDecimal >> | maxNumberOfDecimals | >> maxNumberOfDecimals := self class precision - 1 - (self >> exponent max: self class emin). >> maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self]. >> ^ self asFraction round: numberOfWishedDecimal >> >> It's slower than current implementation, but will round exactly >> to the nearest Float. >> It's possible to have faster implementation up to 22 decimals if >> you provide a fused-multiply-accumulate primitive... > >

Oct. 26, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Nicolas Cellier

2016-10-26 13:11 GMT+02:00 test <wkassens(a)libello.com>: > Hi Nicolas, > regarding rounding Fractions: > i use fractions if i want to get an exact result (eg for comparing the > result with Float calculations). if #round: returns a Float all further > calcs (with Fractions) will get contaminated, since the rest will become > Floats too. Hence the "asScaledDecimal: numberOfWishedDecimal" seems better > to me, but i wonder why these transformations at the end are necessary at > all? just for the looks? i'd suppose every person, who knows how to use > Fractions, also knows how to append a #asScaledDecimal: to a result by > himself, should he want that. > > taking as an example financial calcs that first use 2 decimals. > occasionaly the final result will be basepoints, often small ones like > 0.003. with scaledDecimals the result would be (ok, look like) 0 since > scaledDecimals also contaminate the calc. of course one could correct this > simply with an #asScaledDecimal:3 at the end. nevertheless a first look at > the zero result would surprise me for a tenth of a second. > werner > > > Hi Werner, I don't know the purpose of round: at all. Most often this kind of message was used before printing probably because lack of versatile formatted print messages. In Squeak I replaced most usages of roundTo: by printShowing(Max)DecimalPlaces:. Now if it has been added in Pharo and other languages, there must be some use cases I presume. Maybe the analysis could be carried on these use cases? Beware, converting a Fraction asScaledDecimal will NOT round. Only the printString is rounded, but the number keeps its whole precision. Example (1/3 asScaledDecimal: 1)*3 = 1.0s, not 0.9s. ScaledDecimals as they are now are just Fraction with a different printString... Not very much added value. Nicolas > On 10/26/2016 09:58 AM, Nicolas Cellier wrote: > > > > 2016-10-26 9:14 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> Hi nicolas >> >> So what is the solution? We can integrate fast a solution. >> I would really like to see them fix in Pharo 60. >> I'm writing a book for newbie and this is the third time I change one >> chapter >> so may be I should stop and throw away this chapter. >> >> > 1) for Fraction: > > round: numberOfWishedDecimal > v := 10 raisedTo: numberOfWishedDecimal. > ^ ((self * v) rounded / v) asFloat > > or just replace asFloat if you wish to remain exact: > > round: numberOfWishedDecimal > v := 10 raisedTo: numberOfWishedDecimal. > ^ ((self * v) rounded / v) asScaledDecimal: numberOfWishedDecimal > > 2) for Float, it is in 15471: > > round: numberOfWishedDecimal > | v maxNumberOfDecimals | > maxNumberOfDecimals := self class precision - 1 - (self exponent max: > self class emin). > maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self]. > v := 10 raisedTo: numberOfWishedDecimal. > ^ ((self asFraction * v) rounded / v) asFloat > > or if Fraction already answers a Float: > > round: numberOfWishedDecimal > | maxNumberOfDecimals | > maxNumberOfDecimals := self class precision - 1 - (self exponent max: > self class emin). > maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self]. > ^ self asFraction round: numberOfWishedDecimal > > It's slower than current implementation, but will round exactly to the > nearest Float. > It's possible to have faster implementation up to 22 decimals if you > provide a fused-multiply-accumulate primitive... > > >

Oct. 26, 2016

Re: [Pharo-dev] How to try Bloc?

by Glenn CavarlÃ©

Denis Kudriashov wrote > And now how to activate Halo menu to place with elements on screen? There is no built-in Halo menu because Menu is based on widgets (aka Brick). But there is a basic kind of Halo with basic tools (move, resize, inspect) that can be use on any elements. You can find some uses of BlElementSelection in examples. Regard, Glenn. ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/How-to-try-Bloc-tp4920199p4920247.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 26, 2016

Re: [Pharo-dev] How to try Bloc?

by Glenn CavarlÃ©

Hi Denis, The new version of Brick has no public (ready to use) version right now and only some basic widgets are implemented. I will finally move it to its "official" SmalltalkHub repository (Pharo/Brick) at the end of the week. After, you will be able to play with it ;). Regards, Glenn. ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/How-to-try-Bloc-tp4920199p4920246.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 26, 2016

Re: [Pharo-dev] [Bloc] Hierarchy of BiEvent

by Glenn CavarlÃ©

Hi Denis and thanks for looking at this. Yes there is a duplication of the event hierarchy between Bloc and OSWindow. We discussed about the fusion of OSWindow and Bloc events one year ago at INRIA. We made the choice to keep Bloc independent from OSWindow because, among other things: - Bloc allows several windowing backends, for instance we had a morphic windowing backend (no longer maintained today) - OSEvents are too low level to be used directly in Bloc (nothing about source, target, propagation, consumption ...) - OSWindow has to stay low level and independent from high level preoccupations like the Bloc ones - Bloc has to provide an unified and consistent layer on top of underlying libraries The keyboard management is not yet finished in Bloc. numLock and capsLock seems to be missing, thanks for pointing this. Moreover, some keys are also merged like the left & right distinction between ctrl|alt|shift. If this distinction is really needed in the future maybe we will add it. Denis Kudriashov wrote > BlKeyModifiers encode smart boolean flags about keys back into integer > bits I decided to replace all booleans by one integer+masks because it seems to be more lightweight and this integer can be used directly for the hash key. It is just the internal representation and users don't have to care about this integer. If you think that leads to some issues, i'm not against booleans by nature ;). More generally, i think that, to stay consistent, Bloc should not reuse directly (and everywhere) some part of underlying libraries even if sometime these parts seems to match directly. We have to take care about dependencies between layers. The gain was obvious during the migration from Athens to Sparta. Regards, Glenn. ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/Bloc-Hierarchy-of-BiEvent-tp4920209p4920239.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 26, 2016

Re: [Pharo-dev] roundTo: strange behavior

by test

Hi Nicolas, regarding rounding Fractions: i use fractions if i want to get an exact result (eg for comparing the result with Float calculations). if #round: returns a Float all further calcs (with Fractions) will get contaminated, since the rest will become Floats too. Hence the "asScaledDecimal: numberOfWishedDecimal" seems better to me, but i wonder why these transformations at the end are necessary at all? just for the looks? i'd suppose every person, who knows how to use Fractions, also knows how to append a #asScaledDecimal: to a result by himself, should he want that. taking as an example financial calcs that first use 2 decimals. occasionaly the final result will be basepoints, often small ones like 0.003. with scaledDecimals the result would be (ok, look like) 0 since scaledDecimals also contaminate the calc. of course one could correct this simply with an #asScaledDecimal:3 at the end. nevertheless a first look at the zero result would surprise me for a tenth of a second. werner On 10/26/2016 09:58 AM, Nicolas Cellier wrote: > > > 2016-10-26 9:14 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Hi nicolas > > So what is the solution? We can integrate fast a solution. > I would really like to see them fix in Pharo 60. > I'm writing a book for newbie and this is the third time I change > one chapter > so may be I should stop and throw away this chapter. > > > 1) for Fraction: > > round: numberOfWishedDecimal > v := 10 raisedTo: numberOfWishedDecimal. > ^ ((self * v) rounded / v) asFloat > > or just replace asFloat if you wish to remain exact: > > round: numberOfWishedDecimal > v := 10 raisedTo: numberOfWishedDecimal. > ^ ((self * v) rounded / v) asScaledDecimal: numberOfWishedDecimal > > 2) for Float, it is in 15471: > > round: numberOfWishedDecimal > | v maxNumberOfDecimals | > maxNumberOfDecimals := self class precision - 1 - (self exponent > max: self class emin). > maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self]. > v := 10 raisedTo: numberOfWishedDecimal. > ^ ((self asFraction * v) rounded / v) asFloat > > or if Fraction already answers a Float: > > round: numberOfWishedDecimal > | maxNumberOfDecimals | > maxNumberOfDecimals := self class precision - 1 - (self exponent > max: self class emin). > maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self]. > ^ self asFraction round: numberOfWishedDecimal > > It's slower than current implementation, but will round exactly to the > nearest Float. > It's possible to have faster implementation up to 22 decimals if you > provide a fused-multiply-accumulate primitive...

Oct. 26, 2016

Re: [Pharo-dev] How to try Bloc?

by Dimitris Chloupis

it looks like it did not like my custom build image , in a clean on install fines apart from a warning that taskit overwrites its own files, examples work fine. Bloc is really nice, well done people On Wed, Oct 26, 2016 at 12:20 PM Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-10-26 11:05 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > > No idea how you managed to install it, it gives me a missing ' error > > same setup, macos sierra, pharo 6 latest > ConfigurationOfBloc (Pharo/Bloc repo) loadDevelopment > > > I use this script: > > Gofer it > smalltalkhubUser: 'Pharo' project: 'Bloc'; > configuration; > loadDevelopment > > And examples are working now. > So question is how to open Bloc world? >

Oct. 26, 2016

Re: [Pharo-dev] How to try Bloc?

by Denis Kudriashov

2016-10-26 11:26 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-10-26 11:21 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> You do not have to switch to a Bloc world anymore. The current solution >> opens a new SDL window every time you what to open something in Bloc from a >> Morphic window. >> > > Ok. > And now how to activate Halo menu to place with elements on screen? > And where to load Brick? (if it exists for latest Bloc?)

Oct. 26, 2016

Re: [Pharo-dev] How to try Bloc?

by Denis Kudriashov

2016-10-26 11:21 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > You do not have to switch to a Bloc world anymore. The current solution > opens a new SDL window every time you what to open something in Bloc from a > Morphic window. > Ok. And now how to activate Halo menu to place with elements on screen?

Oct. 26, 2016

Re: [Pharo-dev] How to try Bloc?

by Tudor Girba

Hi, You do not have to switch to a Bloc world anymore. The current solution opens a new SDL window every time you what to open something in Bloc from a Morphic window. Cheers, Doru > On Oct 26, 2016, at 11:19 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-10-26 11:05 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > No idea how you managed to install it, it gives me a missing ' error > > same setup, macos sierra, pharo 6 latest > ConfigurationOfBloc (Pharo/Bloc repo) loadDevelopment > > I use this script: > > Gofer it > smalltalkhubUser: 'Pharo' project: 'Bloc'; > configuration; > loadDevelopment > > And examples are working now. > So question is how to open Bloc world? -- www.tudorgirba.com www.feenk.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

Oct. 26, 2016