February 2015 - Pharo-users

Re: [Pharo-users] Small benchmark

by Andrea Ferretti

For me there is no problem in including kmeans, but I should warn you that this implementation is far from optimal, for various reasons. First, I have reused the class Point, while it would make more sense to do something that works in any dimension. Second, these examples are (intentionally) written in a particularly naive way. The main reason why is that I wanted to benchmark the speed of Pharo for interactive work. I assumed that during an interactive session, one would not bother to write an optimized implementation of an algorithm, but just use the collection's `groupBy:` method; also I did not want to make anything specific to kmeans, because I wanted the comparison to be meaningful for other algorithms where kmeans-specific optmizations would not apply. In the specific case of kmeans, there are a few easy optimizations to do: - first, since sqrt is increasing, all comparisons can be made with the squared distance, saving the sqrt operation - moreover, the main step of the algorithm requires to group points by their nearest centroid. In general a group-by operation requires a hashmap, but in this case there are a finite, known number of choices for the nearest centroid. It is more performant to just keep the index of the nearest centroid for each point, thereby avoiding to build a hashmap. In fact, it is more performant to accumulate the sum and the count of the points near the centroid while traversing, and then just perform a ratio at the end of the step. 2015-02-18 20:09 GMT+01:00 stepharo <stepharo(a)free.fr>: > I thought that didier provided k-means clustering already. > > Le 18/2/15 11:24, SergeStinckwich a Ã©crit : > >> Dear Andrea, >> thank you for your message. This is something really interesting for the >> sci-smalltalk project: >> https://github.com/SergeStinckwich/SciSmalltalk >> >> Do you mind to add your k-means code in Sci-Smalltalk distribution? >> >> Please feel free to join the sci-smalltalk for future discussions : >> https://groups.google.com/forum/#!forum/scismalltalk >> >> Regards, >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Small-benchmark-tp4806092p4806309.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >> > >

Feb. 18, 2015

Re: [Pharo-users] Small benchmark

by stepharo

I thought that didier provided k-means clustering already. Le 18/2/15 11:24, SergeStinckwich a Ã©crit : > Dear Andrea, > thank you for your message. This is something really interesting for the > sci-smalltalk project: > https://github.com/SergeStinckwich/SciSmalltalk > > Do you mind to add your k-means code in Sci-Smalltalk distribution? > > Please feel free to join the sci-smalltalk for future discussions : > https://groups.google.com/forum/#!forum/scismalltalk > > Regards, > > > > > -- > View this message in context: http://forum.world.st/Small-benchmark-tp4806092p4806309.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > >

Feb. 18, 2015

Re: [Pharo-users] moving to git and preserving monticello history

by Thierry Goubier

Le 18/02/2015 19:18, Peter UhnÃ¡k a Ã©crit : > Hi, > > we would like to switch our project over to git, however is it possible > to preserve the history? I.e. to convert mcz (or wherever monticello > stores it) to git commits, or do I have to start from scratch? Hi Peter, if you use a Gofer script to move from Monticello to Git via GitFileTree, such as the script proposed by Yuriy, it will recreates a commit for each mcz, from oldest to newest. Git will not keep the merge information contained in the mcz if you did any, but that history will still be stored in the metadata for each package in the git repository, and you can recover it, if needs be. If you do the copy over a filetree repository, you will loose all versions except the last one. Regards, Thierry

Feb. 18, 2015

Re: [Pharo-users] moving to git and preserving monticello history

by Yuriy Tymchuk

Hi, I believe that there should be a better solution, but if no one else answers, here is a script for moving between MC repositories, maybe if you make destination to be filetree repo it will work. https://gist.github.com/Uko/6898022 <https://gist.github.com/Uko/6898022> Uko > On 18 Feb 2015, at 19:18, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > we would like to switch our project over to git, however is it possible to preserve the history? I.e. to convert mcz (or wherever monticello stores it) to git commits, or do I have to start from scratch? > > Thanks, > > Peter

Feb. 18, 2015

moving to git and preserving monticello history

by Peter UhnÃ¡k

Hi, we would like to switch our project over to git, however is it possible to preserve the history? I.e. to convert mcz (or wherever monticello stores it) to git commits, or do I have to start from scratch? Thanks, Peter

Feb. 18, 2015

Re: [Pharo-users] Issues with code formatting

by Peter UhnÃ¡k

> > BTW two questions: > 1. are these only applied if you click "format" from a source pane's > context > menu or is there another way (e.g. automatically on method save)? > There is shortcut (ctrl+shift+f on linux, couple people mentioned it being broken on Mac). There was some discussion about it being formatted when writing, but that has yet to be thought through and implemented (afaik). 2. Is there a way to view the source pretty-printed without dirtying the > source? I feel like there used to be an obvious option... maybe in the old > browser? > You could probably feed the source to RBConfigurableFormatter (or whatever the object name is), however I'm not aware of any pretty viewer.

Feb. 18, 2015

Re: [Pharo-users] Learning Spec

by blake

> > From now on it is forbidden to complain about Spec in general, unspecific > terms As a rule, complaining about ANYTHING in general, unspecific terms is pretty useless, whether you've learned about it or not. =) (Not that most of us don't do that from time-to-time. But it's a bad habit.)

Feb. 18, 2015

Re: [Pharo-users] Issues with code formatting

by Sean P. DeNigris

Nicolai Hess wrote > Settings browser -> Refactoring Engine -> Configurable Formatter In 4.0 these settings have apparently been moved to Settings browser -> Code Browsing -> Pretty Printing. BTW two questions: 1. are these only applied if you click "format" from a source pane's context menu or is there another way (e.g. automatically on method save)? 2. Is there a way to view the source pretty-printed without dirtying the source? I feel like there used to be an obvious option... maybe in the old browser? Thanks. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issues-with-code-formatting-tp4806202p4806379.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 18, 2015

Videos PharoDays online

by Marcus Denker

Hi, Sorry for the delayâ¦ https://www.youtube.com/channel/UCp3mNigANqkesFzdm058bvw/videos

Feb. 18, 2015

Re: [Pharo-users] i feel dumb / Pharo3 > OrderedCollection >> do:

by Marcus Denker

> On 18 Feb 2015, at 18:13, Cameron Sanders via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > Date: 18 Feb 2015 18:12:33 CET > Subject: i feel dumb / Pharo3 > OrderedCollection >> do: > From: Cameron Sanders <camsanders(a)aol.com> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > > I must be making some silly error here that i cannot see clearly. Why does the following leave anything in the list 'a'? Run it in a workspace. With or without the shallowCopy, i am left with a list with half of the elements in it. Always half. > > This version of Pharo3 (21.0) was downloaded last week. I am running on a Mac. > > Thanks in advance. ... Maybe I just need more coffee. > -Cam > > | a | > a := { #a. #b. #c. #d. } asOrderedCollection. > a shallowCopy do: [ :item | (a includes: item) ifTrue: [ a remove: item ]]. > a size > shallowCopy is not enoughâ¦ OrderedCollection is made up of an internal array. #copy does the right thing, just copies the array: postCopy array := array copy and for Array, copy is a shallowCopy. Marcus

Feb. 18, 2015