[Pharo-project] SortedCollection>>median
I notice that the current median is: median "Return the middle element, or as close as we can get." ^ self at: self size + 1 // 2 Any reason not to make that accurate and return the average of the middle two values for collections containing an even number of items? Or...better yet...should statistics functions be removed and placed into another package with other useful items like mode, range, standardDeviation, etc...? Just wondering! Rob
On Mon, Mar 2, 2009 at 1:34 PM, Rob Rothwell <r.j.rothwell@gmail.com> wrote:
I notice that the current median is:
median "Return the middle element, or as close as we can get."
^ self at: self size + 1 // 2
Any reason not to make that accurate and return the average of the middle two values for collections containing an even number of items?
Or...better yet...should statistics functions be removed and placed into another package with other useful items like mode, range, standardDeviation, etc...?
Hmm... | μ Ï | s := StatisticalAnalysis on: myCollection. μ := s mean. Ï := s standardDeviation. range := μ ± Ï. This might be interesting. Gulik -- http://gulik.pbwiki.com/
Well, I work in a Six Sigma department so...! Anyway, I agree that your proposal could be interesting...what do you think of the current implementations in Pharo? #median, for example, doesn't seem to be used anywhere except as an "approved" method name in MethodFinder>>initialize... Take care, Rob 2009/3/1 Michael van der Gulik <mikevdg@gmail.com>
On Mon, Mar 2, 2009 at 1:34 PM, Rob Rothwell <r.j.rothwell@gmail.com>wrote:
I notice that the current median is:
median "Return the middle element, or as close as we can get."
^ self at: self size + 1 // 2
Any reason not to make that accurate and return the average of the middle two values for collections containing an even number of items?
Or...better yet...should statistics functions be removed and placed into another package with other useful items like mode, range, standardDeviation, etc...?
Hmm...
| μ Ï | s := StatisticalAnalysis on: myCollection. μ := s mean. Ï := s standardDeviation. range := μ ± Ï.
This might be interesting.
Gulik
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
This reminds me some thoughts about time and date. Originally date and time were ok but not so great. Then one guy (brent) fixed it and people were happy and it was introduced in the base system. At that time when time was introduced (in 3.7 I guess) it was a obvious choice. Then chronos and aconcagua went out showing some other properties. Now retrospectively I think that it would be better to have a minimal version in the system and loadable external package. There are some exceptions to this strategy: announcements and regexp (where this is more a language decision), but in general this is a good strategy So we could rename median naiveMedian and have a package that does all the rest and that people can load it. Stef
On Mar 2, 2009, at 09:00 , Stéphane Ducasse wrote:
This reminds me some thoughts about time and date.
Originally date and time were ok but not so great. Then one guy (brent) fixed it and people were happy and it was introduced in the base system. At that time when time was introduced (in 3.7 I guess) it was a obvious choice. Then chronos and aconcagua went out showing some other properties.
Now retrospectively I think that it would be better to have a minimal version in the system and loadable external package. There are some exceptions to this strategy: announcements and regexp (where this is more a language decision), but in general this is a good strategy
I think a good rule of thumb is whether the code is used by the kernel. Having packages like Regex and Announcements in the core makes only sense if they are also used in the core. Else they would better be external packages. Not sure about median, though, as for just one method you wouldn't want to create and load an extra package... Adrian
So we could rename median naiveMedian and have a package that does all the rest and that people can load it.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Adrian Lienhard wrote:
On Mar 2, 2009, at 09:00 , Stéphane Ducasse wrote:
This reminds me some thoughts about time and date.
Originally date and time were ok but not so great. Then one guy (brent) fixed it and people were happy and it was introduced in the base system. At that time when time was introduced (in 3.7 I guess) it was a obvious choice. Then chronos and aconcagua went out showing some other properties.
Now retrospectively I think that it would be better to have a minimal version in the system and loadable external package. There are some exceptions to this strategy: announcements and regexp (where this is more a language decision), but in general this is a good strategy
I think a good rule of thumb is whether the code is used by the kernel. Having packages like Regex and Announcements in the core makes only sense if they are also used in the core. Else they would better be external packages.
Then why not structure the packages in 3 parts: core- All needed to bootstrap a minimal image (kernel, packages to install more packages, logging, scripting,etc) base- All the packages that have various versions but the included one is the prefered, suggested, standarized to (Announcements, SUnit, etc) universes/distros/monticellos/squeaksources- all the packages existing and *easily* loadable by the users Then, with a core image, and a script, you can create a base image. With a base image and a script or a GUI, you can create your very own image (e.g. Damien Cassou's images) Regards, Miguel Cobá
Not sure about median, though, as for just one method you wouldn't want to create and load an extra package...
Adrian
So we could rename median naiveMedian and have a package that does all the rest and that people can load it.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mar 2, 2009, at 1:34 AM, Rob Rothwell wrote:
I notice that the current median is:
median "Return the middle element, or as close as we can get."
^ self at: self size + 1 // 2
Any reason not to make that accurate and return the average of the middle two values for collections containing an even number of items?
Or...better yet...should statistics functions be removed and placed into another package with other useful items like mode, range, standardDeviation, etc...?
I think that it would be good. A nice package with a nice documentation and associated tests. Stef
On Sun, Mar 1, 2009 at 4:34 PM, Rob Rothwell <r.j.rothwell@gmail.com> wrote:
I notice that the current median is:
median "Return the middle element, or as close as we can get."
^ self at: self size + 1 // 2
Any reason not to make that accurate and return the average of the middle two values for collections containing an even number of items?
One nice thing about the existing definition is that you can use #median on collections that are numeric based. So, median of: #( 'Ford' 'Audi' 'Nissan' 'Hyundai' ) median would actually return in the current definition, but not in a 'statistical' definition. Similarly, #max and #min and #size would work for this, although #sum wouldn't. Chris
participants (6)
-
Adrian Lienhard -
Chris Cunningham -
Michael van der Gulik -
Miguel Enrique Cobá MartÃnez -
Rob Rothwell -
Stéphane Ducasse