- Pharo-dev - lists.pharo.org

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

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

by Glenn CavarlÃ©

Denis Kudriashov wrote > 2016-10-26 18:21 GMT+02:00 Denis Kudriashov < > dionisiydk@ > >: > >> No. You are not right here. Conversion code for OSEvent=>BlEvent and >> SDLEvent=>OSEvent is almost same. All events have similar interface to >> retrieve event data. > > > I mean conversion code in both cases is just stupid creation of new event > classes on top of state of original events. No logic behind. > (all logic to parse raw bytes are hidden inside sdl-events) 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. Regards, Glenn. ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/Bloc-Hierarchy-of-BiEvent-tp4920209p4920298.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 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 18:21 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > No. You are not right here. Conversion code for OSEvent=>BlEvent and > SDLEvent=>OSEvent is almost same. All events have similar interface to > retrieve event data. I mean conversion code in both cases is just stupid creation of new event classes on top of state of original events. No logic behind. (all logic to parse raw bytes are hidden inside sdl-events)

Oct. 26, 2016

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

by Denis Kudriashov

2016-10-26 16:58 GMT+02:00 Glenn CavarlÃ© <glenn.cavarle(a)gmail.com>: > > It is interesting only if performances are substantially improved. > Because it is also duplication, you duplicates in Bloc the OSWindow > conversion code without any added value. > No. You are not right here. Conversion code for OSEvent=>BlEvent and SDLEvent=>OSEvent is almost same. All events have similar interface to retrieve event data. So it will be quite easy to use SDL directly. And for Bloc it will be improvement because of direct access to real OS state and also performance. > Moreover, this does not prevent the duplication of Event hierarchy. > If you mean SDLEvents vs BlEvent then I would said it is not real duplication. Because SDLEvents are just "transfer objects" - structures from external interface. We just need them to extract raw information from sdl-library. But BlEvents or OSEvents are about modelling such events inside our system. And here we don't need two models. > OSWindow is already used in other projects and these users will not be > happy > if we remove OSEvents ;). I doubt that there is anyone accept Morphic. And Morphic also perform stupid conversion to own MorphicEvent's which could be also implemented directly on SDL events without OSEvent's.

Oct. 26, 2016

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

by Denis Kudriashov

2016-10-26 17:20 GMT+02:00 stepharo <stepharo(a)free.fr>: > So then it means that OSWindowEvents are not useful. > Glenn said that OSEvent's has no specific state which needed for Bloc logic. And Bloc events define it: - OSEvents are too low level to be used directly in Bloc (nothing about > source, target, propagation, consumption ...) Look at keyboard event to compare: OSKeyboardEvent: #(#window #suppressDefaultAction #scanCode #symbol #character #modifiers #position #repeat) BlKeyboardEvent: #(#source #target #currentTarget #timestamp #canBePropagated #consumed #position #screenPosition #modifiers #button #keyValue #charCode #scanCode) Bloc extends it a lot. Glenn has reasons why he not evolved OSWindow classes. But his work is done. And these reasons are not important anymore. We could think about BlEvent as OSEvent version 2.0. So at the end we will just remove "old version".

Oct. 26, 2016