October 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] roundTo: strange behavior

by Martin McClure

On 10/27/2016 04:12 AM, test wrote: > i would prefer if #round: will not be deprecated in Floats. in some > cases Float>>#round: can be useful, eg optimization problems where one > searched value describes the size of a screw, that exists only in > certain sizes. #roundTo: can be used for this (and is specified by ANSI Smalltalk, for those who care). If the screws only come in 16th inch increments, for instance, then "roundTo: 0.0625" will give you an exact result, since 16ths *are* exactly representable as floats. OTOH, #round: (not in ANSI) appears to promise something that cannot be delivered for Floats, so is misleading, and it spreads the kind of confusion that resulted in this thread. That's why I favor deprecating #round: for Floats. Regards, -Martin

Oct. 27, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Martin McClure

On 10/27/2016 01:34 AM, Nicolas Cellier wrote: > Nonetheless, if user asked to round a Float, we must give him back a > Float. > We ain't gonna answer a ScaledDecimal because we think that it's > better for him: we don't know what is better for him. Right, the result of #round: should always be the same kind of number as the receiver. Regards, -Martin

Oct. 27, 2016

Re: [Pharo-dev] GitHub code analytics tools

by Guillermo Polito

I would like to have a good code review tool, before having to do one ad-hoc... On Thu, Oct 27, 2016 at 1:50 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > With future transition to github I ask myself what tools we will have out > of the box. > I google a bit and found these nice service http://ghv.artzub.com. > Try to search guillep and then pharo-core. It looks really nice. > > What other online services you know to analyse github projects? >

Oct. 27, 2016

GitHub code analytics tools

by Denis Kudriashov

Hi. With future transition to github I ask myself what tools we will have out of the box. I google a bit and found these nice service http://ghv.artzub.com. Try to search guillep and then pharo-core. It looks really nice. What other online services you know to analyse github projects?

Oct. 27, 2016

Re: [Pharo-dev] roundTo: strange behavior

by stepharo

Thanks ***A LOT*** nicolas. > I've put a single slice in the inbox for the 3 issues because they all > are related. > See slice comment: > > For Float, implement guard to prevent overflow (15471), and use exact > representation for intermediate results (asFraction) so as to avoid > double rounding problems (15473) > > For Fraction (15472), choose an exact representation for result rather > than Float. This is because such method is particularly usefull for > financial/monetary applications. > > 2016-10-26 17:28 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > > > Le 26/10/16 Ã 14:52, Nicolas Cellier a Ã©crit : >> Sorry for being slow minded, >> yes of course financial apps is exactly the case where round: >> would be usefull and NEEDS to be exact. > > so what is the solution? > I'm lost again. > >> 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. 27, 2016

Re: [Pharo-dev] roundTo: strange behavior

by test

Hi Guille, On 10/27/2016 11:15 AM, Guille Polito wrote: > > I am also for what Martin says . > i would prefer if #round: will not be deprecated in Floats. in some cases Float>>#round: can be useful, eg optimization problems where one searched value describes the size of a screw, that exists only in certain sizes. > > And also: I'd argue that you NEVER EVER want to use simple Floats for > financial applications. In financial applications you really need > precision, and Floats have hardware limitations that do not provide > precision. i'd be careful with such a bold statement. for example think of calculating future values of an asset, based on probabilities. probabilities are inexact anyway. werner

Oct. 27, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Guille Polito

I am also for what Martin says :). And also: I'd argue that you NEVER EVER want to use simple Floats for financial applications. In financial applications you really need precision, and Floats have hardware limitations that do not provide precision. I thought ScaledDecimal (which I never used in Pharo) was meant to provide high-precision decimal numbers to the expense of using an internal representation that is not tied to the hardware limitations. -------- Original Message -------- > > > > > > On 10/27/2016 10:34 AM, Nicolas Cellier > wrote: > > >> >> >> >> >> >> 2016-10-27 9:51 GMT+02:00 Denis >> Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: >> >> >> >> >> >> 2016-10-27 8:31 GMT+02:00 >> Martin McClure <martin(a)hand2mouse.com >> <mailto:martin@hand2mouse.com>>: >> >> >> I think roundTo: is OK. #round: is not, and >> should be deprecated (at least for Floats). >> For Floats, the idea of rounding to a specific >> number of decimal digits is a fantasy. Here's >> why: Floats cannot exactly represent most >> common decimal fractions. For example: >> >> >> 0.1 -- not representable >> >> >> 0.2 -- not representable >> >> >> 0.3 -- not representable >> >> >> 0.4 -- not representable >> >> >> 0.5 -- hey, representable! >> >> >> 0.6 -- not representable >> >> >> 0.7 -- not representable >> >> >> 0.8 -- not representable >> >> >> 0.9 -- not representable >> >> >> 1.0 -- representable. >> >> >> *Printing* a Float to a specific rounded >> decimal format is a sensible idea, and should >> be encouraged. But trying for a "rounded >> Float" *number* just can't be done exactly >> (except by converting to a Fraction). >> >> >> Fractions can be rounded to exact decimal >> fractions, so something like "myFraction >> roundTo: 1/100" makes sense. But the current >> implementation of round: on Fraction that >> converts to a Float just gets you the misery >> detailed above. >> >> >> >> >> >> >> On >> 10/26/2016 01:00 PM, Nicolas Cellier wrote: >> >> >>> >>> >>> I've put a single slice in the inbox >>> for the 3 issues because they all are >>> related. >>> >>> >>> See slice comment: >>> >>> >>> >>> For Float, implement guard to prevent >>> overflow (15471), and use exact >>> representation for intermediate results >>> (asFraction) so as to avoid double >>> rounding problems (15473) >>> >>> >>> >> >> >> >> The double rounding problem is not the >> fundamental problem, the fundamental problem is >> that what is desired does not exist, because >> Floats cannot exactly represent most decimal >> fractions. So this can't really fix it. >> >> >> >> >> >> Exactly. Thank's for good explanation >> >> >> >> >> >> >> >> Nonetheless, if user asked to round a >> Float, we must give him back a Float. >> >> We ain't gonna answer a ScaledDecimal because we think that >> it's better for him: we don't know what is better for him. >> >> And we MUST do our best to round correctly to the NEAREST >> Float that is 0.1e0, 0.2e0, ... 1.0e0 >> >> >> >> >> If user asked to round a Fraction or >> ScaledDecimal, then it's different. >> >> We'd better keep the exactness and use ScaledDecimal rather >> than convert to a Float. >> >> >> >> >> That's exactly these two things that the SLICE posted in inbox >> is doing. >> >> >> > > i completely agree (well, i would have preferred a pure Fraction > result in the pure Fraction case instead of a ScaledDecimal, but > so what) > > > werner > > > p.s. a pure Fraction result in the pure Fraction case would also > insure that the rest of Number is more or less independent of the > not very useful ScaledDecimal > > > > > > >

Oct. 27, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Nicolas Cellier

2016-10-27 11:04 GMT+02:00 test <wkassens(a)libello.com>: > On 10/27/2016 10:34 AM, Nicolas Cellier wrote: > > > > 2016-10-27 9:51 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> 2016-10-27 8:31 GMT+02:00 Martin McClure <martin(a)hand2mouse.com>: >> >>> I think roundTo: is OK. #round: is not, and should be deprecated (at >>> least for Floats). For Floats, the idea of rounding to a specific number of >>> decimal digits is a fantasy. Here's why: Floats cannot exactly represent >>> most common decimal fractions. For example: >>> >>> 0.1 -- not representable >>> >>> 0.2 -- not representable >>> >>> 0.3 -- not representable >>> >>> 0.4 -- not representable >>> >>> 0.5 -- hey, representable! >>> >>> 0.6 -- not representable >>> >>> 0.7 -- not representable >>> >>> 0.8 -- not representable >>> >>> 0.9 -- not representable >>> >>> 1.0 -- representable. >>> >>> *Printing* a Float to a specific rounded decimal format is a sensible >>> idea, and should be encouraged. But trying for a "rounded Float" *number* >>> just can't be done exactly (except by converting to a Fraction). >>> >>> Fractions can be rounded to exact decimal fractions, so something like >>> "myFraction roundTo: 1/100" makes sense. But the current implementation of >>> round: on Fraction that converts to a Float just gets you the misery >>> detailed above. >>> >>> >>> On 10/26/2016 01:00 PM, Nicolas Cellier wrote: >>> >>> I've put a single slice in the inbox for the 3 issues because they all >>> are related. >>> See slice comment: >>> >>> For Float, implement guard to prevent overflow (15471), and use exact >>> representation for intermediate results (asFraction) so as to avoid double >>> rounding problems (15473) >>> >>> >>> The double rounding problem is not the fundamental problem, the >>> fundamental problem is that what is desired does not exist, because Floats >>> cannot exactly represent most decimal fractions. So this can't really fix >>> it. >> >> >> Exactly. Thank's for good explanation >> > > Nonetheless, if user asked to round a Float, we must give him back a Float. > We ain't gonna answer a ScaledDecimal because we think that it's better > for him: we don't know what is better for him. > And we MUST do our best to round correctly to the NEAREST Float that is > 0.1e0, 0.2e0, ... 1.0e0 > > If user asked to round a Fraction or ScaledDecimal, then it's different. > We'd better keep the exactness and use ScaledDecimal rather than convert > to a Float. > > That's exactly these two things that the SLICE posted in inbox is doing. > > i completely agree (well, i would have preferred a pure Fraction result in > the pure Fraction case instead of a ScaledDecimal, but so what) > > werner > > p.s. a pure Fraction result in the pure Fraction case would also insure > that the rest of Number is more or less independent of the not very useful > ScaledDecimal > +1 feel free to improve the slice.

Oct. 27, 2016

Re: [Pharo-dev] roundTo: strange behavior

by test

On 10/27/2016 10:34 AM, Nicolas Cellier wrote: > > > 2016-10-27 9:51 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com > <mailto:dionisiydk@gmail.com>>: > > > 2016-10-27 8:31 GMT+02:00 Martin McClure <martin(a)hand2mouse.com > <mailto:martin@hand2mouse.com>>: > > I think roundTo: is OK. #round: is not, and should be > deprecated (at least for Floats). For Floats, the idea of > rounding to a specific number of decimal digits is a fantasy. > Here's why: Floats cannot exactly represent most common > decimal fractions. For example: > > 0.1 -- not representable > > 0.2 -- not representable > > 0.3 -- not representable > > 0.4 -- not representable > > 0.5 -- hey, representable! > > 0.6 -- not representable > > 0.7 -- not representable > > 0.8 -- not representable > > 0.9 -- not representable > > 1.0 -- representable. > > *Printing* a Float to a specific rounded decimal format is a > sensible idea, and should be encouraged. But trying for a > "rounded Float" *number* just can't be done exactly (except by > converting to a Fraction). > > Fractions can be rounded to exact decimal fractions, so > something like "myFraction roundTo: 1/100" makes sense. But > the current implementation of round: on Fraction that converts > to a Float just gets you the misery detailed above. > > > On 10/26/2016 01:00 PM, Nicolas Cellier wrote: >> I've put a single slice in the inbox for the 3 issues because >> they all are related. >> See slice comment: >> >> For Float, implement guard to prevent overflow (15471), and >> use exact representation for intermediate results >> (asFraction) so as to avoid double rounding problems (15473) > > The double rounding problem is not the fundamental problem, > the fundamental problem is that what is desired does not > exist, because Floats cannot exactly represent most decimal > fractions. So this can't really fix it. > > > Exactly. Thank's for good explanation > > > Nonetheless, if user asked to round a Float, we must give him back a > Float. > We ain't gonna answer a ScaledDecimal because we think that it's > better for him: we don't know what is better for him. > And we MUST do our best to round correctly to the NEAREST Float that > is 0.1e0, 0.2e0, ... 1.0e0 > > If user asked to round a Fraction or ScaledDecimal, then it's different. > We'd better keep the exactness and use ScaledDecimal rather than > convert to a Float. > > That's exactly these two things that the SLICE posted in inbox is doing. i completely agree (well, i would have preferred a pure Fraction result in the pure Fraction case instead of a ScaledDecimal, but so what) werner p.s. a pure Fraction result in the pure Fraction case would also insure that the rest of Number is more or less independent of the not very useful ScaledDecimal

Oct. 27, 2016

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

by Guille Polito

Something itches me from this discussion. I somehow find myself with Glenn: - should Bloc work with other than SDL/OSWindow? - should SDL/OSWindow work with other than Bloc? Merging the event hierarchy may prevent these two scenarios. And these scenarios are not only really possible: this is what the current scenario is. On one hand SDL and OSWindow work today with Morphic besides Block. On the other hand Bloc is, after all, an external library loaded on top of Pharo. To explain better what I think: - First I have the feeling that BIEvent and OSEvent are not the same thing. They have the same *NAME*. But they model different concepts. What is an event in bloc does not make sense in OSWindow and vice-versa. Why? because OSWindow does not manage widgets nor interactions between them. - Second, I think that this idea of merging these hierarchies means merging layers also, what leads also to our monolithic system. I agree that this may impose some maintenance burden because there is the maintenance of the two layers plus their mapping (e.g., between the low-level events and the high-level events). But otherwise we are tampering the modularity. Now, I liked more the suggestion of making Bloc using SDLEvents directly. But then, wasn't it an idea behind OSWindow that users of OSWindow should be somehow abstracted from the backend behind. And SDL be just a backend? Something like Athens and Cairo. Is SDL meant to work alone or be just a backend for OSWindow? Because if the case is the later, then maybe it makes sense to do the inverse: SDL should generate directly OSEvents and we should not have SDLEvent. And going even further: Is OSWindow used in isolation? e.g., without morphic or bloc. Because then, it the problem is the runtime overhead OSWindow should maybe not reify its events but propose a low level event handler mechanism where we could have MorphicOSWindowEventHandler >> keyEvent: ... >> mouseEvent: ... BlocOSWindowEventHandler >> keyEvent: ... >> mouseEvent: ... And each framework generates its own events from low level SDL data. No event transformations, less duplications, and both Bloc and Morphic are plugged on top of OSWindow but not really strongly coupled to it. -------- Original Message -------- > > > > Le 26/10/16 Ã 20:40, Denis Kudriashov a Ã©crit : >> >> 2016-10-26 19:45 GMT+02:00 Glenn CavarlÃ© <glenn.cavarle(a)gmail.com >> <mailto:glenn.cavarle@gmail.com>>: >> >> >> Yes, your are right. >> What i mean is that it could be interesting if: >> [ SDLEvent => BlEvent ] is substantially faster than [ >> SDLEvent => >> OSEvent => BlEvent ]. >> If the difference is not significant, i think that does not >> justify to not >> benefit from OSWindow abstractions even if sometime they bring >> nothing more. >> >> >> If you already thought about Announcements performance and produce >> optimized alternative then I think it is critical to get events fast. >> Now we have 10 variables which are decoded from int by bit operations: >> >> leftShift rightShift leftAlt rightAlt leftCtrl rightCtrl leftCmd >> rightCmd capsLock numLock >> >> And then Bloc encodes them back to int. So for any event we have 20 >> operations and it is not just primitive calls. >> Also OSEvent creation produces own garbage for internal structures >> which also take time and memory. >> >> But for me most important is how maintain both hierarchies. You >> answer Stef that nothing will change over events during years (nobody >> invent new one or not often). >> But such argument could never be valid. Code is used, it could has >> bugs, it could be improved by itself. People will always need to work >> with this code, at least to read it. And it is difficult with two >> hierarchies which are managed by double dispatch. Try to follow how >> concrete BlEvent is produced. >> >> And there is already some problem. I investigated deeply what happens >> in sdl about modifiers and buttons. It is not easy. But I see that >> some information becomes lost. >> And Bloc also not provides full information from original objects >> (modifiers and buttons). >> So to fix these issues one needs to modify both hierarchies. First he >> needs to decide how decode modifiers from SDL and then how to encode >> them into Bloc bits. >> And I am sure new issues will be found again and again. It is normal >> process. > > So denis you suggest that Bloc uses directly SDLEvents. > This would make sense from your analysis. >> >> >

Oct. 27, 2016