- Pharo-dev - lists.pharo.org

Re: [Pharo-project] SIXX problem for ScaledDecimal

by Dario Trussardi

But: > >>> From: Chris Cunningham <cunningham.cb(a)gmail.com> >>> Subject: Re: [Pharo-project] SIXX problem for ScaledDecimal >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Message-ID: <BANLkTinP7E_oh2Fi2=axmra6JsoXVJYWkg(a)mail.gmail.com> >>> Content-Type: text/plain; charset=ISO-8859-1 >> >>> For ScaledDecimal, SIXX should definite store it as the underlying >>> fraction. Storing it in the printed fashion does change the value of >>> the ScaledDecimal. >> >>> (1/3) asScaledDecimal: 2 gives 0.33s2 >>> and >>> (33/100) asScaledDecimal: 2 gives 0.33s2 >>> yet >>> 0.33s2 ~= ( (1/3) asScaledDecimal: 2 ) >>> and >>> ( (1/3) asScaledDecimal: 2 ) ~= ( (33/100) asScaledDecimal: 2 ) >> >>> In other words, the ScaledDecimal is about the precise internal number >>> and the scale to display it - which is NOT the scale that it is stored >>> as. >> >>> -Chris >> >> I don't agree. ScaledDecimal would be used where consistency is often >> more important than accuracy, e.g. in Financial calculations where being off by >> a few pennies doesn't matter but always getting the same answer matters a LOT. >> Once a number is converted to a ScaledDecimal computations must always >> produce the same result assuming enough digits. To ensure this asScaledDecimal >> must produce a scaled decimal for use in computations and, as such, storing >> a fraction internally is unacceptable. >> From a financial point of view 1/3 * 3 is not 1! >> From a programmers point of view asScaledDecimal changes the value >> in much the same way asInteger does for a float. >> >> Having said all of this allow me to contradict myself. It seems to me that >> a scaled decimal should in general store more digits than are displayed. >> For example money might be stored with a large (possibly arbitrary) number >> of digits after the decimal point but only display two digits beyond the decimal >> point. >> I don't know how ScaledDecimal is implemented but I would be inclined to >> use arbitrary or large size integers and store the location of the decimal point >> internally recomputing the position of the decimal point after each calculation. >> This is an expensive way of doing computations but I expect users of >> ScaledDecimal can live with that. When converting non decimal results to >> ScaledDecimal then how many digits of precision to maintain must be specified >> somehow. >> Dealing with ScaledDecimal is a complicated matter and I have probably failed >> to appreciate many of the complications but whoever is implementing >> ScaledDecimal >> (and Smalltalk needs ScaledDecimal) needs to appreciate those complications. >> Anybody here a financial expert? >> >> Ralph Boland >> > > I think ScaledDecimal for financial data. > > Where rounded is do only for the last of the operations. ( the total of the document for example or when i command it ) > > I do : > > ( ((1/3 asScaledDecimal:5 ) + (1/3 asScaledDecimal:5 )) * (6 asScaledDecimal:5) ) > > > The result 4 is not right . > > > 2/3 * 6 when management 5 decimal are : > > 0,66666 * 6,00000 = 3,99996 > > and not fraction 2/3 * 6/1 -> 12 / 3 - > 4 > > BUT : (( 0.33333 asScaledDecimal: 5 )+ (0.33333 asScaledDecimal: 5 ) ) *6 3.99996s5 is right. Dario

May 20, 2011

Re: [Pharo-project] Can't load OSProcess in last Pharo Core 1.3

by Mariano Martinez Peck

On Fri, May 20, 2011 at 5:07 PM, Adrien BARREAU <abarreau.dev(a)live.fr>wrote: > Hi all, > > I just tried to load OSProcess in the last PharoCore 1.3 (I took it from > hudson). It fails when it tries to add ThisOSProcess to the startup list > with: > Smalltalk addToStartUpList: ThisOSProcess after: ImageSegment. > I think that is incorrect. Why would OSProcess requires to be before ImageSegment? OSProcess should be before what it really needs. And if it doesn't need anything then just use #addToStartupList: > in ThisOSProcess class>>initialize. > > > It seems that ImageSegment is not in the StartUpList anymore. > Is that normal? > > Adrien. > -- Mariano http://marianopeck.wordpress.com

May 20, 2011

Re: [Pharo-project] SIXX problem for ScaledDecimal

by Dario Trussardi

>> From: Chris Cunningham <cunningham.cb(a)gmail.com> >> Subject: Re: [Pharo-project] SIXX problem for ScaledDecimal >> To: Pharo-project(a)lists.gforge.inria.fr >> Message-ID: <BANLkTinP7E_oh2Fi2=axmra6JsoXVJYWkg(a)mail.gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 > >> For ScaledDecimal, SIXX should definite store it as the underlying >> fraction. Storing it in the printed fashion does change the value of >> the ScaledDecimal. > >> (1/3) asScaledDecimal: 2 gives 0.33s2 >> and >> (33/100) asScaledDecimal: 2 gives 0.33s2 >> yet >> 0.33s2 ~= ( (1/3) asScaledDecimal: 2 ) >> and >> ( (1/3) asScaledDecimal: 2 ) ~= ( (33/100) asScaledDecimal: 2 ) > >> In other words, the ScaledDecimal is about the precise internal number >> and the scale to display it - which is NOT the scale that it is stored >> as. > >> -Chris > > I don't agree. ScaledDecimal would be used where consistency is often > more important than accuracy, e.g. in Financial calculations where being off by > a few pennies doesn't matter but always getting the same answer matters a LOT. > Once a number is converted to a ScaledDecimal computations must always > produce the same result assuming enough digits. To ensure this asScaledDecimal > must produce a scaled decimal for use in computations and, as such, storing > a fraction internally is unacceptable. > From a financial point of view 1/3 * 3 is not 1! > From a programmers point of view asScaledDecimal changes the value > in much the same way asInteger does for a float. > > Having said all of this allow me to contradict myself. It seems to me that > a scaled decimal should in general store more digits than are displayed. > For example money might be stored with a large (possibly arbitrary) number > of digits after the decimal point but only display two digits beyond the decimal > point. > I don't know how ScaledDecimal is implemented but I would be inclined to > use arbitrary or large size integers and store the location of the decimal point > internally recomputing the position of the decimal point after each calculation. > This is an expensive way of doing computations but I expect users of > ScaledDecimal can live with that. When converting non decimal results to > ScaledDecimal then how many digits of precision to maintain must be specified > somehow. > Dealing with ScaledDecimal is a complicated matter and I have probably failed > to appreciate many of the complications but whoever is implementing > ScaledDecimal > (and Smalltalk needs ScaledDecimal) needs to appreciate those complications. > Anybody here a financial expert? > > Ralph Boland > I think ScaledDecimal for financial data. Where rounded is do only for the last of the operations. ( the total of the document for example or when i command it ) I do : ( ((1/3 asScaledDecimal:5 ) + (1/3 asScaledDecimal:5 )) * (6 asScaledDecimal:5) ) The result 4 is not right . 2/3 * 6 when management 5 decimal are : 0,66666 * 6,00000 = 3,99996 and not fraction 2/3 * 6/1 -> 12 / 3 - > 4 I'm surprised about it. Any idea ? Dario

May 20, 2011

Re: [Pharo-project] SIXX problem for ScaledDecimal

by Dario Trussardi

Il giorno 20/mag/2011, alle ore 16.57, Ralph Boland ha scritto: >> From: Chris Cunningham <cunningham.cb(a)gmail.com> >> Subject: Re: [Pharo-project] SIXX problem for ScaledDecimal >> To: Pharo-project(a)lists.gforge.inria.fr >> Message-ID: <BANLkTinP7E_oh2Fi2=axmra6JsoXVJYWkg(a)mail.gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 > >> For ScaledDecimal, SIXX should definite store it as the underlying >> fraction. Storing it in the printed fashion does change the value of >> the ScaledDecimal. > >> (1/3) asScaledDecimal: 2 gives 0.33s2 >> and >> (33/100) asScaledDecimal: 2 gives 0.33s2 >> yet >> 0.33s2 ~= ( (1/3) asScaledDecimal: 2 ) >> and >> ( (1/3) asScaledDecimal: 2 ) ~= ( (33/100) asScaledDecimal: 2 ) > >> In other words, the ScaledDecimal is about the precise internal number >> and the scale to display it - which is NOT the scale that it is stored >> as. > >> -Chris > > I don't agree. ScaledDecimal would be used where consistency is often > more important than accuracy, e.g. in Financial calculations where being off by > a few pennies doesn't matter but always getting the same answer matters a LOT. > Once a number is converted to a ScaledDecimal computations must always > produce the same result assuming enough digits. To ensure this asScaledDecimal > must produce a scaled decimal for use in computations and, as such, storing > a fraction internally is unacceptable. > From a financial point of view 1/3 * 3 is not 1! > From a programmers point of view asScaledDecimal changes the value > in much the same way asInteger does for a float. > > Having said all of this allow me to contradict myself. It seems to me that > a scaled decimal should in general store more digits than are displayed. > For example money might be stored with a large (possibly arbitrary) number > of digits after the decimal point but only display two digits beyond the decimal > point. > I don't know how ScaledDecimal is implemented but I would be inclined to > use arbitrary or large size integers and store the location of the decimal point > internally recomputing the position of the decimal point after each calculation. > This is an expensive way of doing computations but I expect users of > ScaledDecimal can live with that. When converting non decimal results to > ScaledDecimal then how many digits of precision to maintain must be specified > somehow. > Dealing with ScaledDecimal is a complicated matter and I have probably failed > to appreciate many of the complications but whoever is implementing > ScaledDecimal > (and Smalltalk needs ScaledDecimal) needs to appreciate those complications. > Anybody here a financial expert? > > Ralph Boland > I think ScaledDecimal for financial data. Where rounded is do only for the last of the operations. ( the total of the document for example or when i command it ) I do : ( ((1/3 asScaledDecimal:5 ) + (1/3 asScaledDecimal:5 )) * (6 asScaledDecimal:5) ) The result 4 is not right . 2/3 * 6 when management 5 decimal are : 0,66666 * 6,00000 = 3,99996 and not fraction 2/3 * 6/1 -> 12 / 3 - > 4 I'm surprised about it. Any idea ? Dario

May 20, 2011

Re: [Pharo-project] Can't load OSProcess in last Pharo Core 1.3

by Miguel CobÃ¡

Yes that is a workaround but not a final fix, because it depends on a specific class in the system. In squeak, IIRC, it was a discussion about changing ordering of startup items using numbers instead of names of classes in the image, something similiar to the Linux startup infrastructure. But for now it is ok to change it as you said. Cheers El vie, 20-05-2011 a las 17:29 +0200, Adrien BARREAU escribiÃ³: > I just saw that update 13205 removed ImageSegment from the > StartUpList. > > Replacing > Smalltalk addToStartUpList: ThisOSProcess after: ImageSegment. > by > Smalltalk addToStartUpList: ThisOSProcess before: UUIDGenerator. > in ThisOSProcess>>initialize would be ok I think (and would have the > same result). > > Adrien. > > > > ______________________________________________________________________ > From: abarreau.dev(a)live.fr > To: pharo-project(a)lists.gforge.inria.fr > Date: Fri, 20 May 2011 17:07:04 +0200 > Subject: [Pharo-project] Can't load OSProcess in last Pharo Core 1.3 > > Hi all, > > I just tried to load OSProcess in the last PharoCore 1.3 (I took it > from hudson). It fails when it tries to add ThisOSProcess to the > startup list with: > Smalltalk addToStartUpList: ThisOSProcess after: ImageSegment. > in ThisOSProcess class>>initialize. > > > It seems that ImageSegment is not in the StartUpList anymore. > Is that normal? > > Adrien. -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

May 20, 2011

Re: [Pharo-project] Can't load OSProcess in last Pharo Core 1.3

by Marcus Denker

On May 20, 2011, at 5:30 PM, Adrien BARREAU wrote: > I just saw that update 13205 removed ImageSegment from the StartUpList. > > Replacing > Smalltalk addToStartUpList: ThisOSProcess after: ImageSegment. > by > Smalltalk addToStartUpList: ThisOSProcess before: UUIDGenerator. > in ThisOSProcess>>initialize would be ok I think (and would have the same result). > > The problem is that there was no #addToStartUpList:before: So if you wanted to add yourself before something (because that thing depends on you), you had to add after something completely unrelated, leading to strange dependencies (like OSProcess depending on ImageSegment in the startup list..) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 20, 2011

Re: [Pharo-project] Can't load OSProcess in last Pharo Core 1.3

by Adrien BARREAU

I just saw that update 13205 removed ImageSegment from the StartUpList. Replacing Smalltalk addToStartUpList: ThisOSProcess after: ImageSegment. by Smalltalk addToStartUpList: ThisOSProcess before: UUIDGenerator. in ThisOSProcess>>initialize would be ok I think (and would have the same result). Adrien. From: abarreau.dev(a)live.fr To: pharo-project(a)lists.gforge.inria.fr Date: Fri, 20 May 2011 17:07:04 +0200 Subject: [Pharo-project] Can't load OSProcess in last Pharo Core 1.3 Hi all, I just tried to load OSProcess in the last PharoCore 1.3 (I took it from hudson). It fails when it tries to add ThisOSProcess to the startup list with: Smalltalk addToStartUpList: ThisOSProcess after: ImageSegment. in ThisOSProcess class>>initialize. It seems that ImageSegment is not in the StartUpList anymore. Is that normal? Adrien.

May 20, 2011

Re: [Pharo-project] [Vm-dev] Re: out of memory - cog on windows

by Tudor Girba

Hi, I am not sure I understand where we are on this issue. I will say it again that I find it to be critical to be able to work with images that are not small :). Would it be possible to find some resolution on it? Cheers, Doru On 20 May 2011, at 17:08, Andreas Raab wrote: > On 5/20/2011 16:57, Igor Stasenko wrote: >> Here an excert from crash.dmp: >> >> Memory Information (upon launch): >> Physical Memory Size: 4194303 kbytes >> Physical Memory Free: 2507424 kbytes >> Page File Size: 4194303 kbytes >> Page File Free: 4194303 kbytes >> Virtual Memory Size: 2097024 kbytes >> Virtual Memory Free: 2030280 kbytes >> Memory Load: 59 percent >> >> this is strange. >> Of course, with sizes like above , it cannot fit into memory. > > Nothing strange about it. Standard 4GB Ram configuration with about 2GB available. > > Cheers, > - Andreas > > >> >>> Hi, >>> >>> On 18 May 2011, at 18:07, Levente Uzonyi wrote: >>> >>>> On Wed, 18 May 2011, Tudor Girba wrote: >>>> >>>> snip >>>> >>>>> I tried with several versions of Cog including the latest ones (on both platforms) and I got the same result. I did not try with an interpreter VM because I only have Cog images around (based on Pharo 1.2) and they are not compatible. >>>> You can use this interpreter vm to open cog images: http://leves.web.elte.hu/squeak/SqueakVM-Win32-4.4.9-2358-non-official-bin.… >>> I tried with this VM, but it crashes with the attached error. >>> >>> In any case, if someone wants to reproduce it, here is an image to play with: >>> http://dl.dropbox.com/u/18323746/Tmp/moose-case-study-windows-problem.zip >>> >>> Cheers, >>> Doru >>> >>> >>> >>> >>> >>>> Levente >>>> >>>> snip >>> -- >>> www.tudorgirba.com >>> >>> "Being happy is a matter of choice." >>> >>> >> >> -- www.tudorgirba.com "Every thing has its own flow."

May 20, 2011

Re: [Pharo-project] paragraph replacement?

by Tudor Girba

Hi, In NewParagraph>>clickAt: clickPoint for: model controller: editor there is a call to: ... att actOnClickFor: target in: self at: clickPoint editor: editor ... However, actOnClickFor:in:at:editor: does not exist. This method is also missing from Pharo 1.2. Anyone knows where to get it from? Cheers, Doru On 20 May 2011, at 14:02, Tudor Girba wrote: > Hi, > > > On 20 May 2011, at 13:28, Marcus Denker wrote: > >> >> On May 20, 2011, at 1:22 PM, Tudor Girba wrote: >> >>> Hi, >>> >>> Another class we used in EyeSee (besides Circle) is Paragraph. I see that this class is now deprecated and empty. What should we use instead of it? >>> >> >> NewParagraph >> >> It has a different API, though. And there is a subclass that is the one used by the system (MultiNewParaph)... this part of the system definitly needs more cleanup >> and simplification. > > Thanks. I kind of made it work :). Now, all EyeSee examples are green again :) > > Cheers, > Doru > > >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> > > -- > www.tudorgirba.com > > "Every successful trip needs a suitable vehicle." > > > > -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

May 20, 2011

[Pharo-project] [update 1.3] #13207

by Marcus Denker

13207 ----- Issue 4173: If sources file is not present, something bad happens -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 20, 2011