- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [squeak-dev] Float hierarchy for 64-bit Spur

by David T. Lewis

On Thu, Nov 20, 2014 at 05:51:42PM -0800, Eliot Miranda wrote: > Hi All, > > 64-bit Spur can usefully provide an immediate float, a 61-bit subset of > the ieee double precision float. The scheme steals bits from the mantissa > to use for the immediate's 3-bit tag pattern. So values have the same > precision as ieee doubles, but can only represent the subset with exponents > between 10^-38 and 10^38, the single-precision range. The issue here is > how to organize the class hierarchy. > > The approach that looks best to me is to modify class Float to be an > abstract class, and add two subclasses, BoxedFloat and SmallFloat, such > that existing boxed instances of Float outside the SmallFloat range will > become instances of BoxedFloat and instances within that range will be > replaced by references to the relevant SmallFloat. > > With this approach ... > > - Float pi etc can still be used, even though they will answer instances of > SmallFloat. But tests such as "self assert: result class == Float." will > need to be rewritten to e.g. "self assert: result isFloat". > > - BoxedFloat and SmallFloat will not be mentioned much at all since floats > print themselves literally, and so the fact that the classes have changed > won't be obvious. > > - the boxed Float primitives (receiver is a boxed float) live in BoxedFloat > and the immediate ones live in SmallFloat. Making SmallFloat a subclass of > Float poses problems for all the primitives that do a super send to retry, > since the boxed Float prims will be above the unboxed ones and so the boxed > ones would have to test for an immediate receiver. > > > An alternative, that VW took (because it has both Float and Double) is to > add a superclass, e.g. LimitedPrecisionReal, move most of the methods into > it, and keep Float as Float, and add SmallFloat as a subclass of > LimitedPrecisionReal. Then while class-side methods such as pi would > likely be implemented in LimitedPrecisionReal class, sends to Float to > access them find them via inheritance. An automatic reorganization which > moves only primitives out of LimitedPrecisionReal is easy to write. > > Thoughts? I have always felt that the mapping of Float to 64-bit double and FloatArray to 32-bit float is awkward. It may be that 32-bit floats are becoming less relevant nowadays, but if short float values are still important, then it would be nice to be able to represent them directly. I like the idea of having a Float class and a Double class to represent the two most common representations. A class hierarchy that could potentially support this sounds like a good idea to me. I have no experience with VW, but a LimitedPrecisionReal hierachy sounds like a reasonable approach. Dave

Nov. 21, 2014

[Fwd: Re: Float hierarchy for 64-bit Spur]

by Ben Coman

(sorry, I didn't notice the cross-post) Eliot Miranda wrote: > Hi All, > > 64-bit Spur can usefully provide an immediate float, a 61-bit subset > of the ieee double precision float. I wonder if class SmallDouble would be more intention revealing? In practice 61 bits will be "more than enough"(tm) for anyone. But I can envisage in a business environment environment software needing to comply with (sometimes irrelevant) feature checklists, with one of those likely being full 64 bit compliant IEEE Doubles. Can we have such a class, to which 61 bit floats are auto-promoted as required? > The scheme steals bits from the > mantissa to use for the immediate's 3-bit tag pattern. So values have > the same precision as ieee doubles, but can only represent the subset > with exponents between 10^-38 and 10^38, the single-precision range. > The issue here is how to organize the class hierarchy. > > The approach that looks best to me is to modify class Float to be an > abstract class, and add two subclasses, BoxedFloat and SmallFloat, such > that existing boxed instances of Float outside the SmallFloat range will > become instances of BoxedFloat and instances within that range will be > replaced by references to the relevant SmallFloat. > My first few pages of search results lead to a few references in conversation, but nothing that described what a boxed float is. Can someone explain? btw, http://www.ctan.org/pkg/float also mentioned boxed float, ruled float and plainÂtop float Anyone familiar with those? > With this approach ... > > - Float pi etc can still be used, even though they will answer instances > of SmallFloat. But tests such as "self assert: result class == Float." > will need to be rewritten to e.g. "self assert: result isFloat". This is probably a good change anyway. > > - BoxedFloat and SmallFloat will not be mentioned much at all since > floats print themselves literally, and so the fact that the classes have > changed won't be obvious. > > - the boxed Float primitives (receiver is a boxed float) live in > BoxedFloat and the immediate ones live in SmallFloat. Making SmallFloat > a subclass of Float** poses problems for all the primitives that do a > super send to retry, since the boxed Float prims will be above the > unboxed ones and so the boxed ones would have to test for an immediate > receiver. ** do you mean the current Float, or after Float become abstract? > > > An alternative, that VW took (because it has both Float and Double) is > to add a superclass, e.g. LimitedPrecisionReal, move most of the methods > into it, and keep Float as Float, and add SmallFloat as a subclass of > LimitedPrecisionReal. Then while class-side methods such as pi would > likely be implemented in LimitedPrecisionReal class, sends to Float to > access them find them via inheritance. An automatic reorganization > which moves only primitives out of LimitedPrecisionReal is easy to write. > A Float is defined as a limited precision real [1] having several types of precision, so I like the first option. [1] http://en.wikipedia.org/wiki/Floating_point cheers -ben

Nov. 21, 2014

Re: [Pharo-dev] Float hierarchy for 64-bit Spur

by Ben Coman

Eliot Miranda wrote: > Hi All, > > 64-bit Spur can usefully provide an immediate float, a 61-bit subset > of the ieee double precision float. I wonder if class SmallDouble would be more intention revealing? In practice 61 bits will be "more than enough"(tm) for anyone. But I can envisage in a business environment environment software needing to comply with (sometimes irrelevant) feature checklists, with one of those likely being full 64 bit compliant IEEE Doubles. Can Pharo aim to have such a class, to which 61 bit floats are auto-promoted as required? > The scheme steals bits from the > mantissa to use for the immediate's 3-bit tag pattern. So values have > the same precision as ieee doubles, but can only represent the subset > with exponents between 10^-38 and 10^38, the single-precision range. > The issue here is how to organize the class hierarchy. > > The approach that looks best to me is to modify class Float to be an > abstract class, and add two subclasses, BoxedFloat and SmallFloat, such > that existing boxed instances of Float outside the SmallFloat range will > become instances of BoxedFloat and instances within that range will be > replaced by references to the relevant SmallFloat. > My first few pages of search results lead to a few references in conversation, but nothing that described what a boxed float is. Can someone explain? btw, http://www.ctan.org/pkg/float also mentioned boxed float, ruled float and plainÂtop float Anyone familiar with those? > With this approach ... > > - Float pi etc can still be used, even though they will answer instances > of SmallFloat. But tests such as "self assert: result class == Float." > will need to be rewritten to e.g. "self assert: result isFloat". > > - BoxedFloat and SmallFloat will not be mentioned much at all since > floats print themselves literally, and so the fact that the classes have > changed won't be obvious. > > - the boxed Float primitives (receiver is a boxed float) live in > BoxedFloat and the immediate ones live in SmallFloat. Making SmallFloat > a subclass of Float poses problems for all the primitives that do a > super send to retry, since the boxed Float prims will be above the > unboxed ones and so the boxed ones would have to test for an immediate > receiver. > > > An alternative, that VW took (because it has both Float and Double) is > to add a superclass, e.g. LimitedPrecisionReal, move most of the methods > into it, and keep Float as Float, and add SmallFloat as a subclass of > LimitedPrecisionReal. Then while class-side methods such as pi would > likely be implemented in LimitedPrecisionReal class, sends to Float to > access them find them via inheritance. An automatic reorganization > which moves only primitives out of LimitedPrecisionReal is easy to write. > A Float is defined as a limited precision real [1] having several types of precision, so I like the first option. [1] http://en.wikipedia.org/wiki/Floating_point cheers -ben

Nov. 21, 2014

Float hierarchy for 64-bit Spur

by Eliot Miranda

Hi All, 64-bit Spur can usefully provide an immediate float, a 61-bit subset of the ieee double precision float. The scheme steals bits from the mantissa to use for the immediate's 3-bit tag pattern. So values have the same precision as ieee doubles, but can only represent the subset with exponents between 10^-38 and 10^38, the single-precision range. The issue here is how to organize the class hierarchy. The approach that looks best to me is to modify class Float to be an abstract class, and add two subclasses, BoxedFloat and SmallFloat, such that existing boxed instances of Float outside the SmallFloat range will become instances of BoxedFloat and instances within that range will be replaced by references to the relevant SmallFloat. With this approach ... - Float pi etc can still be used, even though they will answer instances of SmallFloat. But tests such as "self assert: result class == Float." will need to be rewritten to e.g. "self assert: result isFloat". - BoxedFloat and SmallFloat will not be mentioned much at all since floats print themselves literally, and so the fact that the classes have changed won't be obvious. - the boxed Float primitives (receiver is a boxed float) live in BoxedFloat and the immediate ones live in SmallFloat. Making SmallFloat a subclass of Float poses problems for all the primitives that do a super send to retry, since the boxed Float prims will be above the unboxed ones and so the boxed ones would have to test for an immediate receiver. An alternative, that VW took (because it has both Float and Double) is to add a superclass, e.g. LimitedPrecisionReal, move most of the methods into it, and keep Float as Float, and add SmallFloat as a subclass of LimitedPrecisionReal. Then while class-side methods such as pi would likely be implemented in LimitedPrecisionReal class, sends to Float to access them find them via inheritance. An automatic reorganization which moves only primitives out of LimitedPrecisionReal is easy to write. Thoughts? -- best, Eliot

Nov. 21, 2014

Re: [Pharo-dev] About the Playground cache

by Ben Coman

Tudor Girba wrote: > > How about creating just one cache file, and only add used/evaluated > expressions > to the cache? > > > Why? What don't you want remembered? > > Cheers, > Doru > > ZnEasy get: 'https://www.google.com.au/webhp?search=sex+worker+jobs' ;) ??

Nov. 21, 2014

Re: [Pharo-dev] [Pharo4] down to 3 failing tests!

by Ben Coman

Marcus Denker wrote: > We are down to 3 failing tests! > > AJx64AssemblerTests>>#testStringOps64Mnemonics > ObsoleteTest>>#testFixObsoleteSharedPools > ReleaseTest>>#testObsoleteClasses > > https://pharo.fogbugz.com/f/search/?sSearchFor=outline%3A14445 > > Nice to hear. This will be good to achieve.

Nov. 21, 2014

Re: [Pharo-dev] About the Playground cache

by Tudor Girba

Hi, On Thu, Nov 20, 2014 at 11:56 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-11-20 22:14 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi Nicolai, >> >> On Thu, Nov 20, 2014 at 10:04 PM, Nicolai Hess <nicolaihess(a)web.de> >> wrote: >> >>> >>> I thought the Playground cache holds all evaluated/used expressions. >>> >> >> > Hi Doru > > >> It used to only remember the expressions after you pressed Go. But, then >> we noticed that this is not enough as sometimes you just do it. So, rather >> than duplicating the logic for all possible actions, we asked ourselves: >> Why would I ever want to forget anything? After all, I am not deleting my >> mails anymore, and the package-cache already accumulated some 14k mcz files. >> >> Hence, the playground never forgets. >> > > Sure it does, you just have to delete all the current text, after that it > is gone you can not get it back. > > Maybe my practice is different, I don't open many different playgrounds > for every code I type in. > I am used to work with one or two workspaces and use only one of them as a > "playground" for the code. > I see. > >> >>> But it just caches the current text and if you remove the current text, >>> the cache >>> file is deleted. >>> >> >> Indeed. You get a file per Playground. This is why the title of the >> playground can be relevant. >> > >> >>> And it does not use just one file, but one for every opened playground >>> with text. >>> And if you close the playground, without deleting the current text, you >>> ' ll end >>> up with many (many many) cache files. (and it takes some time opening the >>> first playground after image start up). >>> >> >> Interesting. I have used this quite a lot and did not stumble across the >> opening delay problem. How many files do you have? >> > > 0, just deleted :) > But, does it still take long for you? > >> >>> Pressing the little "..." icon shows an unscrollable large list with all >>> the cache entries. >>> (even duplicate entries). >>> >> >> This will be replaced with a fancy search. >> >> How about creating just one cache file, and only add used/evaluated >>> expressions >>> to the cache? >>> >> >> Why? What don't you want remembered? >> > > all the same text from different cache files. > Ok. So, you mean if I have exactly the same text, we should not cache it. That makes sense. Would that be enough for you? If so, could you open an issue for this? > btw, the cache isn't truncated if you don't delete the whole text. That > means, if you select some > text and replace it with a shorter one, the play-cache files replaces only > the beginning of the file. > Therefore, some of the text isn't even valid code anymore. > Oops. This is a bug. Can you open an issue? Cheers, Doru > > >> >> Cheers, >> Doru >> >> >>> >>> >>> nicolai >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 20, 2014

Re: [Pharo-dev] About the Playground cache

by Nicolai Hess

2014-11-20 22:14 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi Nicolai, > > On Thu, Nov 20, 2014 at 10:04 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> I thought the Playground cache holds all evaluated/used expressions. >> > > Hi Doru > It used to only remember the expressions after you pressed Go. But, then > we noticed that this is not enough as sometimes you just do it. So, rather > than duplicating the logic for all possible actions, we asked ourselves: > Why would I ever want to forget anything? After all, I am not deleting my > mails anymore, and the package-cache already accumulated some 14k mcz files. > > Hence, the playground never forgets. > Sure it does, you just have to delete all the current text, after that it is gone you can not get it back. Maybe my practice is different, I don't open many different playgrounds for every code I type in. I am used to work with one or two workspaces and use only one of them as a "playground" for the code. > > >> But it just caches the current text and if you remove the current text, >> the cache >> file is deleted. >> > > Indeed. You get a file per Playground. This is why the title of the > playground can be relevant. > > >> And it does not use just one file, but one for every opened playground >> with text. >> And if you close the playground, without deleting the current text, you ' >> ll end >> up with many (many many) cache files. (and it takes some time opening the >> first playground after image start up). >> > > Interesting. I have used this quite a lot and did not stumble across the > opening delay problem. How many files do you have? > 0, just deleted :) > > >> Pressing the little "..." icon shows an unscrollable large list with all >> the cache entries. >> (even duplicate entries). >> > > This will be replaced with a fancy search. > > How about creating just one cache file, and only add used/evaluated >> expressions >> to the cache? >> > > Why? What don't you want remembered? > all the same text from different cache files. btw, the cache isn't truncated if you don't delete the whole text. That means, if you select some text and replace it with a shorter one, the play-cache files replaces only the beginning of the file. Therefore, some of the text isn't even valid code anymore. > > Cheers, > Doru > > >> >> >> nicolai >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Nov. 20, 2014

Re: [Pharo-dev] Link between PetitParser and Roassal and Glamour

by Tudor Girba

No problem :) Cheers, Doru On Thu, Nov 20, 2014 at 10:10 PM, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > I see. thanks :-) > On 20 Nov 2014, at 16:15, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > It's not strange. You only get this dependency if you load the gui of > petit parser. If you do not need the gui, you can load the core group. > > > > Doru > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > >> On 20 Nov 2014, at 15:57, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > >> > >> Load PetitParser (dev version) => Roassal and Glamour loaded. > >> > >> Isnât it strange? I believe there should be less dependency. > >> > >> Noury > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 20, 2014

Re: [Pharo-dev] About the Playground cache

by Tudor Girba

Hi Nicolai, On Thu, Nov 20, 2014 at 10:04 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > I thought the Playground cache holds all evaluated/used expressions. > It used to only remember the expressions after you pressed Go. But, then we noticed that this is not enough as sometimes you just do it. So, rather than duplicating the logic for all possible actions, we asked ourselves: Why would I ever want to forget anything? After all, I am not deleting my mails anymore, and the package-cache already accumulated some 14k mcz files. Hence, the playground never forgets. > But it just caches the current text and if you remove the current text, > the cache > file is deleted. > Indeed. You get a file per Playground. This is why the title of the playground can be relevant. > And it does not use just one file, but one for every opened playground > with text. > And if you close the playground, without deleting the current text, you ' > ll end > up with many (many many) cache files. (and it takes some time opening the > first playground after image start up). > Interesting. I have used this quite a lot and did not stumble across the opening delay problem. How many files do you have? > Pressing the little "..." icon shows an unscrollable large list with all > the cache entries. > (even duplicate entries). > This will be replaced with a fancy search. How about creating just one cache file, and only add used/evaluated > expressions > to the cache? > Why? What don't you want remembered? Cheers, Doru > > > nicolai > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 20, 2014