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

Re: [Pharo-dev] roundTo: strange behavior

by Nicolas Cellier

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.

Oct. 27, 2016

[pharo-project/pharo-core] 06ed58: 60270

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 06ed586175a6de94862196fe5ad7365512641925 https://github.com/pharo-project/pharo-core/commit/06ed586175a6de94862196fe… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-10-27 (Thu, 27 Oct 2016) Changed paths: M Rubric.package/RubCharacterScanner.class/instance/scanning/plainTab.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60269.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60270.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60269.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60270.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Core.package/ImageModel.class/definition.st A Spec-Core.package/ImageModel.class/instance/api-valueHolder/autoScaleHolder.st A Spec-Core.package/ImageModel.class/instance/api/autoScale.st A Spec-Core.package/ImageModel.class/instance/api/switchAutoscale.st M Spec-Core.package/ImageModel.class/instance/initialization/initialize.st M Spec-MorphicAdapters.package/MorphicImageAdapter.class/instance/factory/buildWidget.st A Spec-MorphicAdapters.package/MorphicImageAdapter.class/instance/widget protocol/switchAutoscale.st A Spec-Tests.package/ImageModelTest.class/README.md A Spec-Tests.package/ImageModelTest.class/definition.st A Spec-Tests.package/ImageModelTest.class/instance/running/classToTest.st A Spec-Tests.package/ImageModelTest.class/instance/tests/testSwitchAutoScale.st Log Message: ----------- 60270 19231 Enable "Autoscale" in ImageModel https://pharo.fogbugz.com/f/cases/19231 17765 Rubric cannot indent text https://pharo.fogbugz.com/f/cases/17765 http://files.pharo.org/image/60/60270.zip

Oct. 27, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60270 Home: https://github.com/pharo-project/pharo-core

Oct. 27, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Denis Kudriashov

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

Oct. 27, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Sven Van Caekenberghe

> On 27 Oct 2016, at 08:31, Martin McClure <martin(a)hand2mouse.com> wrote: > > On 10/26/2016 08:27 AM, stepharo wrote: >> So what is the definition of printShowingMaxDecimalDigit:? >> I have the impression that there is a confusion between the rounding a number and the printing of his value in a given format. > > Yes, I see quite a bit of confusion in this thread about that. > >> we can deprecate roundTo: if necessary. > 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). YES ! Nice explanation. > 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. > >> >> For Fraction (15472), choose an exact representation for result rather than Float. This is because such method is particularly usefull for financial/monetary applications. >> > Yes. Fraction or ScaledDecimal. Not Floats, unless the developer understands the needs of the financial world and the limitations of Floats very well. > > > Regards, > > -Martin

Oct. 27, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Martin McClure

On 10/26/2016 08:27 AM, stepharo wrote: > So what is the definition of printShowingMaxDecimalDigit:? > I have the impression that there is a confusion between the rounding a > number and the printing of his value in a given format. Yes, I see quite a bit of confusion in this thread about that. > we can deprecate roundTo: if necessary. 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. > > For Fraction (15472), choose an exact representation for result rather > than Float. This is because such method is particularly usefull for > financial/monetary applications. > Yes. Fraction or ScaledDecimal. Not Floats, unless the developer understands the needs of the financial world and the limitations of Floats very well. Regards, -Martin

Oct. 27, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Nicolas Cellier

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>: > > > 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>: >> >>> 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] [Bloc] Hierarchy of BiEvent

by stepharo

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. 26, 2016

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

by stepharo

Hi Glenn Now I understand. So can you copy and paste this mail into the class comment of the BlEvent root. We should really document such design decision. Stef Le 26/10/16 Ã 19:25, Glenn CavarlÃ© a Ã©crit : > Hi Stef, > > > stepharo wrote >>> OSWindow cannot be the only one backend for Bloc so Bloc events cannot be >>> based on OSEvents. >> Why that? > Because it is OS"Window" and many devices don't have window and sometime > don't have SDL too. > If tomorrow, OSWindow become something like OSDirectMedia with support for > many kind of devices and backends, my answer will be completely different > and in this case you will be right. > So, right now OSWindow is used in Bloc for what it is, a nice windowing > library based on SDL/OpenGL. > > > stepharo wrote >> I do not get why on android we cannot map android event to OSWindowEvents >> And do not have duplication in Bloc. > Maybe it is possible, maybe not, maybe it is just inconsistent with the rest > of OSWindow in its current state. > Clearly, I don't know and you? In doubt, i prefer to keep the possibility to > use another backend. > > > stepharo wrote >> So then it means that OSWindowEvents are not useful. >> But to me this is bloc events that are not needed. > I don't understand what you mean. > The question is not what is the more useful event hierarchy. > The question is why we cannot use OSWindow events directly in Bloc right > now. > > The answer is: > > - because many events do not exist in SDL and are consequently not managed > by OSWindow. > - because OSWindow events are not design to be used in a scene graph > - because some information related to the scene graph are missing in the > OSWindow event hierarchy. > > If you want to improve OSWindow in this way, this mean that part of Bloc has > to be moved in OSWindow because: > - you need a dispatch/handling mechanism > - you need a scene graph > - you need to generate high-level events (click, drag, focus,...) depending > on nodes in the scene graph > > Personally, if something has to be done, I would prefer the opposite: to > move OSWindow in Bloc ;). > > > > stepharo wrote >>> OSWindow is already used in other projects and these users will not be >>> happy >>> if we remove OSEvents ;). >> who? > I know that Ronie uses OSWindow for Woden. > As i said, if everybody is ok, we can merge OSWindow in Bloc and we can just > keep the existing BlEvent hierarchy. > > As explained, it is not a stupid duplication, many things in Bloc events > would have no sense in OSWindow events. > I would like also to mention that we are discussing about a justified > duplication of a hierarchy which have to be changed maybe every 3 years if > magically new events are added in SDL... > It is known that it i not perfect to duplicate things but it is localized > and today i don't have alternative solution that does not includes to > redo/brake OSWindow. > > <joke> > But if you have a concrete solution to avoid that and that does not requires > 1000 times more developments than updating the "duplicated" hierarchy once > in 2 years, i'm on it ! ;) > </joke> > > Regards, > Glenn. > > > > > ----- > Glenn CavarlÃ© > -- > View this message in context: http://forum.world.st/Bloc-Hierarchy-of-BiEvent-tp4920209p4920294.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Oct. 26, 2016

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

by Denis Kudriashov

2016-10-26 19:45 GMT+02:00 Glenn CavarlÃ© <glenn.cavarle(a)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.

Oct. 26, 2016