Hi folks, Is there anything in scipy (or in python at all) that can calculate the (approximate) convex hull of a set of N-dimensional points? All I need are the vertices, actually. I could get qhull or something and wrap that, or use one of the sets of libSVM wrappers to train a one-class SVM and extract the support vectors which probably provide an approximate convex hull... but if there's anything already out there, I'd be interested in finding out. Zach Pincus Program in Biomedical Informatics and Department of Biochemistry Stanford University School of Medicine
Hi Zach, PyXL written by Chris Meyers will be of great use to you: http://www.tc.cornell.edu/~myers/PyXL/ Currently I'm working wit PyXL a lot, so feel free to be in touch off-list. Cheers, -jelle -----Original Message----- From: scipy-user-bounces@scipy.net [mailto:scipy-user-bounces@scipy.net] On Behalf Of Zachary Pincus Sent: Wednesday, May 03, 2006 10:24 AM To: SciPy Users List Subject: [SciPy-user] N-D Convex Hull? Hi folks, Is there anything in scipy (or in python at all) that can calculate the (approximate) convex hull of a set of N-dimensional points? All I need are the vertices, actually. I could get qhull or something and wrap that, or use one of the sets of libSVM wrappers to train a one-class SVM and extract the support vectors which probably provide an approximate convex hull... but if there's anything already out there, I'd be interested in finding out. Zach Pincus Program in Biomedical Informatics and Department of Biochemistry Stanford University School of Medicine _______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
Hello Zach I'm currently putting the finishing touches on my libsvm wrapper for SciPy. I used ctypes and my wrapper allows one to pass NumPy arrays as data to libsvm. If you're interested in playing with it, I'll send it to you. Regards, Albert
-----Original Message----- From: scipy-user-bounces@scipy.net [mailto:scipy-user-bounces@scipy.net] On Behalf Of Zachary Pincus Sent: 03 May 2006 10:24 To: SciPy Users List Subject: [SciPy-user] N-D Convex Hull?
Hi folks,
Is there anything in scipy (or in python at all) that can calculate the (approximate) convex hull of a set of N-dimensional points? All I need are the vertices, actually.
I could get qhull or something and wrap that, or use one of the sets of libSVM wrappers to train a one-class SVM and extract the support vectors which probably provide an approximate convex hull... but if there's anything already out there, I'd be interested in finding out.
Zach Pincus
Program in Biomedical Informatics and Department of Biochemistry Stanford University School of Medicine
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
I would appreciate it if someone could clarify for me the various Python "numerical" packages. One web site (I can't remember which) suggested that, in chronological order, - first there was Numeric - then there was numarray - finally there was numpy. However, various web sites seem to have different views of this. I've seen references to Numerical (is that the same as Numeric ??), and also references that seem to use Numeric(al) as a name for numpy. Or visa versa. I suspect that names have either been reused, or changed, or both, at some point leading to my confusion. The background to this question is that I've started using matplotlib (an excellent package BTW), and in the "Matplotlib User's Guide" (.PDF) page 8 it mentions Numeric and numarray, and then gives matching websites with (respectively) numpy and numarray in the name. So if anyone can clarify the relationship between the various Python mathematical extensions, that would be appreciated! Thanks Matthew
Some time ago, there were two packages implementing arrays and various mathematical functions named Numeric and Numarray. Numarray was designed (correct me if I'm wrong) to deal with larges arrays efficiently, while Numeric was faster on small arrays. Then, Travis Oliphant came and unified those two packages in what was called Scipy and Scipy_core. Scipy_core contained the lower level mathematical functions and types, while Scipy was the repository of various higher level algorithms (optimize, stats, signal, etc.). Around January 2006, Scipy_core was renamed numpy, which was, I believe, the nickname of Numeric. Numeric and Numarray are used by a lot of people and many scientific apps import one or both these packages. They are, however, bound to become unsupported once Numpy has reached some maturity. If you're starting with matplotlib, it is suggested you use Numpy (the new one). If you do, make sure you specify it in the matplotlibrc file. Apologies for any innacuracies or errors on my part, I'm also a numpy rookie. David 2006/5/3, Matthew Webber <m_webber_sydney@yahoo.com.au>:
I would appreciate it if someone could clarify for me the various Python "numerical" packages.
One web site (I can't remember which) suggested that, in chronological order, - first there was Numeric - then there was numarray - finally there was numpy.
However, various web sites seem to have different views of this. I've seen references to Numerical (is that the same as Numeric ??), and also references that seem to use Numeric(al) as a name for numpy. Or visa versa.
I suspect that names have either been reused, or changed, or both, at some point leading to my confusion.
The background to this question is that I've started using matplotlib (an excellent package BTW), and in the "Matplotlib User's Guide" (.PDF) page 8 it mentions Numeric and numarray, and then gives matching websites with (respectively) numpy and numarray in the name.
So if anyone can clarify the relationship between the various Python mathematical extensions, that would be appreciated!
Thanks Matthew
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
I believe there was a Numerical Python project a long time ago whose python module was named num.py and was sometimes referred to as numpy but that numpy is unrelated to the scipy numpy. Bill David Huard wrote:
Some time ago, there were two packages implementing arrays and various mathematical functions named Numeric and Numarray. Numarray was designed (correct me if I'm wrong) to deal with larges arrays efficiently, while Numeric was faster on small arrays. Then, Travis Oliphant came and unified those two packages in what was called Scipy and Scipy_core. Scipy_core contained the lower level mathematical functions and types, while Scipy was the repository of various higher level algorithms (optimize, stats, signal, etc.). Around January 2006, Scipy_core was renamed numpy, which was, I believe, the nickname of Numeric.
Numeric and Numarray are used by a lot of people and many scientific apps import one or both these packages. They are, however, bound to become unsupported once Numpy has reached some maturity. If you're starting with matplotlib, it is suggested you use Numpy (the new one). If you do, make sure you specify it in the matplotlibrc file.
Apologies for any innacuracies or errors on my part, I'm also a numpy rookie.
David
2006/5/3, Matthew Webber <m_webber_sydney@yahoo.com.au <mailto:m_webber_sydney@yahoo.com.au>>:
I would appreciate it if someone could clarify for me the various Python "numerical" packages.
One web site (I can't remember which) suggested that, in chronological order, - first there was Numeric - then there was numarray - finally there was numpy.
However, various web sites seem to have different views of this. I've seen references to Numerical (is that the same as Numeric ??), and also references that seem to use Numeric(al) as a name for numpy. Or visa versa.
I suspect that names have either been reused, or changed, or both, at some point leading to my confusion.
The background to this question is that I've started using matplotlib (an excellent package BTW), and in the "Matplotlib User's Guide" (.PDF) page 8 it mentions Numeric and numarray, and then gives matching websites with (respectively) numpy and numarray in the name.
So if anyone can clarify the relationship between the various Python mathematical extensions, that would be appreciated!
Thanks Matthew
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net <mailto:SciPy-user@scipy.net> http://www.scipy.net/mailman/listinfo/scipy-user
------------------------------------------------------------------------
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
Matthew Webber wrote:
I would appreciate it if someone could clarify for me the various Python "numerical" packages.
I'm afraid that both David and Bill are also confused on some points. In the beginning was Numeric. Unfortunately, Numeric acquired several nicknames: Numerical Python, Numerical, NumPy. For example, the SourceForge project name for it is numpy, the old CVS module is Numerical, Konrad Hinsen named his package Scientific Python in reference to Numerical Python. Development on Numeric slowed down several years ago, and people wanted to extend it in ways that the then-current codebase did not really allow. Furthermore, there was a desire to get Numeric or something like it into the standard library, and Guido was quite clear that the code was not maintainable in its state then. The numarray project began as a complete rewrite of Numeric that, among other things, pushed some of the code up into the Python level. This gave numarray a lot of flexibility and allowed it to experiment with a number of alternatives that have proven their usefulness. It also was quite fast for very large arrays because the people working on it were at the Space Telescope Science Institute and were intending to use it for astronomical image processing. Unfortunately, as fast as it was for large arrays, it was too slow for small arrays. In particular, SciPy codes ran quite a bit slower. Also, the C API for creating ufuncs was not as convenient as that of Numeric. Consequently, it was going to be very difficult to convert the SciPy codebase to use numarray. This split fractured the community quite a bit: some people wrote code only for numarray, seeing it as the next Numeric; some people wrote code for Numeric, because they needed SciPy. Travis Oliphant wanted to reunify the community around a single array package. He refactored Numeric's code to make it more maintainable (although probably not enough to get the whole thing into the standard library, more on that later) and flexible enough to implement the novel features of numarray. He named this project "scipy core" and intended to use the package name "scipy". The rest of SciPy would simply add more modules to core SciPy package. Eventually, it became clear that people were mistakenly thinking that Numeric had been subsumed into SciPy and that they would have to install the whole of SciPy just to get an array object. We had a long discussion about what to name the package, and the winner was numerix! Unfortunately, that name is trademarked by a company that does DSP. In order to avoid trademark infringement by ourselves and by our users, we needed another name. We picked numpy. Moral: Don't let your software project acquire nicknames! -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Thanks Robert, I'd like to put this historical note on the wiki. Any objections ? David 2006/5/3, Robert Kern <robert.kern@gmail.com>:
Matthew Webber wrote:
I would appreciate it if someone could clarify for me the various Python "numerical" packages.
I'm afraid that both David and Bill are also confused on some points.
In the beginning was Numeric. Unfortunately, Numeric acquired several nicknames: Numerical Python, Numerical, NumPy. For example, the SourceForge project name for it is numpy, the old CVS module is Numerical, Konrad Hinsen named his package Scientific Python in reference to Numerical Python.
Development on Numeric slowed down several years ago, and people wanted to extend it in ways that the then-current codebase did not really allow. Furthermore, there was a desire to get Numeric or something like it into the standard library, and Guido was quite clear that the code was not maintainable in its state then. The numarray project began as a complete rewrite of Numeric that, among other things, pushed some of the code up into the Python level. This gave numarray a lot of flexibility and allowed it to experiment with a number of alternatives that have proven their usefulness. It also was quite fast for very large arrays because the people working on it were at the Space Telescope Science Institute and were intending to use it for astronomical image processing.
Unfortunately, as fast as it was for large arrays, it was too slow for small arrays. In particular, SciPy codes ran quite a bit slower. Also, the C API for creating ufuncs was not as convenient as that of Numeric. Consequently, it was going to be very difficult to convert the SciPy codebase to use numarray. This split fractured the community quite a bit: some people wrote code only for numarray, seeing it as the next Numeric; some people wrote code for Numeric, because they needed SciPy.
Travis Oliphant wanted to reunify the community around a single array package. He refactored Numeric's code to make it more maintainable (although probably not enough to get the whole thing into the standard library, more on that later) and flexible enough to implement the novel features of numarray. He named this project "scipy core" and intended to use the package name "scipy". The rest of SciPy would simply add more modules to core SciPy package. Eventually, it became clear that people were mistakenly thinking that Numeric had been subsumed into SciPy and that they would have to install the whole of SciPy just to get an array object.
We had a long discussion about what to name the package, and the winner was numerix!
Unfortunately, that name is trademarked by a company that does DSP. In order to avoid trademark infringement by ourselves and by our users, we needed another name. We picked numpy.
Moral: Don't let your software project acquire nicknames!
-- Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
On May 3, 2006, at 11:04 AM, David Huard wrote:
I'd like to put this historical note on the wiki. Any objections ?
+1. Also, I would like an update on how far along numpy (or some subset) is in being included in the standard python codebase. A while ago, I thought it was going to maybe be put into 2.5. Is this still true, because I don't see much evidence for it in the python2.5 What's New documentation. If false, what are the present plans? -Rob. ----- Rob Hetland, Assistant Professor Dept of Oceanography, Texas A&M University p: 979-458-0096, f: 979-845-6331 e: hetland@tamu.edu, w: http://pong.tamu.edu
Robert Hetland wrote:
On May 3, 2006, at 11:04 AM, David Huard wrote:
I'd like to put this historical note on the wiki. Any objections ?
None from me. There are some gaps, of course, but maybe the Wiki magic will help fill them in. Also, reference should be made to the Introduction of _The Guide to NumPy_ which goes into some more detail on this subject. http://numeric.scipy.org/scipybooksample.pdf
Also, I would like an update on how far along numpy (or some subset) is in being included in the standard python codebase. A while ago, I thought it was going to maybe be put into 2.5. Is this still true, because I don't see much evidence for it in the python2.5 What's New documentation. If false, what are the present plans?
It's definitely not going to happen in 2.5. I don't think numpy as a whole will ever go into the standard library. It's possible that an ndarray object and ufuncs and very little else might go into 3.0, but my crystal ball is cloudy at the moment. The most likely thing to happen is that Tim Hochberg's basearray or something like it will go into 2.6. Pre-3.0, the focus is going to be on spreading the use of the array interface rather than putting a whole array-handling package into the standard library. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Robert Kern wrote:
Robert Hetland wrote:
On May 3, 2006, at 11:04 AM, David Huard wrote:
I'd like to put this historical note on the wiki. Any objections ?
None from me. There are some gaps, of course, but maybe the Wiki magic will help fill them in. Also, reference should be made to the Introduction of _The Guide to NumPy_ which goes into some more detail on this subject.
Robert gave a good start to the wiki. Somebody should copy his comments over.
http://numeric.scipy.org/scipybooksample.pdf
Also, I would like an update on how far along numpy (or some subset) is in being included in the standard python codebase. A while ago, I thought it was going to maybe be put into 2.5. Is this still true, because I don't see much evidence for it in the python2.5 What's New documentation. If false, what are the present plans?
It's definitely not going to happen in 2.5. I don't think numpy as a whole will ever go into the standard library. It's possible that an ndarray object and ufuncs and very little else might go into 3.0, but my crystal ball is cloudy at the moment. The most likely thing to happen is that Tim Hochberg's basearray or something like it will go into 2.6. Pre-3.0, the focus is going to be on spreading the use of the array interface rather than putting a whole array-handling package into the standard library.
Again this is right on. If a student were to get funded by the Summer of Code project. I proposed a project and one student has expressed interest... If this is successful, perhaps the idea of a basearray object going into Python itself could actually get done by version 2.6. I've already got an outline for this thing (I've called it genarray, others dimarray). I like basearray best of all the names. For my outline, look at the PEP here: http://svn.scipy.org/svn/PEP
On 5/4/06, Travis Oliphant <oliphant@ee.byu.edu> wrote:
Again this is right on. If a student were to get funded by the Summer of Code project. I proposed a project and one student has expressed interest...
FWIW I'm also considering applying to work on a scipy project for SOC, pending a number of other things I'm considering for the next few months. Tim If this is successful, perhaps the idea of a basearray object going into
Python itself could actually get done by version 2.6. I've already got an outline for this thing (I've called it genarray, others dimarray). I like basearray best of all the names.
For my outline, look at the PEP here:
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
Tim Leslie wrote:
On 5/4/06, *Travis Oliphant* <oliphant@ee.byu.edu <mailto:oliphant@ee.byu.edu>> wrote:
Again this is right on. If a student were to get funded by the Summer of Code project. I proposed a project and one student has expressed interest...
FWIW I'm also considering applying to work on a scipy project for SOC, pending a number of other things I'm considering for the next few months.
Consider fast. :-) The deadline for student applications is May 8th. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
participants (10)
-
Albert Strasheim -
Bill Dandreta -
David Huard -
Jelle Feringa / EZCT Architecture & Design Research -
Matthew Webber -
Robert Hetland -
Robert Kern -
Tim Leslie -
Travis Oliphant -
Zachary Pincus