Menu
▾
▴
numpy-discussion — Discussion list for all users of Numerical Python
You can subscribe to this list here.
| 2000 |
Jan
(8) |
Feb
(49) |
Mar
(48) |
Apr
(28) |
May
(37) |
Jun
(28) |
Jul
(16) |
Aug
(16) |
Sep
(44) |
Oct
(61) |
Nov
(31) |
Dec
(24) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(56) |
Feb
(54) |
Mar
(41) |
Apr
(71) |
May
(48) |
Jun
(32) |
Jul
(53) |
Aug
(91) |
Sep
(56) |
Oct
(33) |
Nov
(81) |
Dec
(54) |
| 2002 |
Jan
(72) |
Feb
(37) |
Mar
(126) |
Apr
(62) |
May
(34) |
Jun
(124) |
Jul
(36) |
Aug
(34) |
Sep
(60) |
Oct
(37) |
Nov
(23) |
Dec
(104) |
| 2003 |
Jan
(110) |
Feb
(73) |
Mar
(42) |
Apr
(8) |
May
(76) |
Jun
(14) |
Jul
(52) |
Aug
(26) |
Sep
(108) |
Oct
(82) |
Nov
(89) |
Dec
(94) |
| 2004 |
Jan
(117) |
Feb
(86) |
Mar
(75) |
Apr
(55) |
May
(75) |
Jun
(160) |
Jul
(152) |
Aug
(86) |
Sep
(75) |
Oct
(134) |
Nov
(62) |
Dec
(60) |
| 2005 |
Jan
(187) |
Feb
(318) |
Mar
(296) |
Apr
(205) |
May
(84) |
Jun
(63) |
Jul
(122) |
Aug
(59) |
Sep
(66) |
Oct
(148) |
Nov
(120) |
Dec
(70) |
| 2006 |
Jan
(460) |
Feb
(683) |
Mar
(589) |
Apr
(559) |
May
(445) |
Jun
(712) |
Jul
(815) |
Aug
(663) |
Sep
(559) |
Oct
(930) |
Nov
(373) |
Dec
|
|
From: Sasha <nd...@ma...> - 2006-10-31 20:10:03
|
On 10/31/06, Travis Oliphant <oli...@ie...> wrote: > > I'm recruiting more comments on python-dev regarding my two proposals > for improving Python's native ability to share ndarray-like information. > I would love to help, but I feel that I will be on the other side of the disagreement. (That's why I reply here rather than on python-dev first.) I've suggested that numpy could use ctypes way to describe binary data a long time ago: http://sourceforge.net/mailarchive/message.php?msg_id=15395017 I agree that it would not work out of the box, but I don't see any major obstacles to adding the missing features. I think we should attempt to implement a ctypes approach and compare the result to the dtype object approach. If we discover any unimplementable features along the way, this will be a strong argument to abandon ctypes as a standard. The last time I looked at the issue, the only feature that ctypes were lacking for me was the itemsize information (endianness is probably lacking as well, but I did not need it.) I am not sure, however that this information belongs to the type description object rather than carried separately. Note that it is trivial to add an itemsize attribute to ctypes because each primitive ctype has a fixed itemsize and Structure can easily compute its itemsize. Doubling the number of ctypes to allow for different endianness is a more troubling proposition. In any case, I think we should seriously discuss the relative merits of the two approaches on this list and present our view to python-dev when we reach some consensus. |
|
From: Erin S. <eri...@gm...> - 2006-10-31 19:38:41
|
Hi Alan - I have not had luck with the binary distros. There is always something that doesn't work, so I will be interested in the results of your efforts. The biggest problem with compiling things yourself is going to be dealing with LAPACK and fortran issues, and the backends in matplotlib. FWIW, the most stable solution I have found that doesn't involve dealing with dependencies yourself is darwinports (now macports). It currently has 1.0b5 numpy and scipy 0.5.1, which depend on python 2.4. Matplotlib worked with the wxPython backend but not others. While not the latest versions it will get you started, and I would guess 1.0 will be available soon (anyone?). I had absolutely zero problems using this once I realized that I had to use wxPython for the plotting backend. The snag is that gfortran is needed, which requires compiling gcc 4.0 which took 6 hours on my powerbook, so you will need some patience. Erin On 10/31/06, Steve Lianoglou <lis...@ar...> wrote: > Hi Alan, > > > > I installed Python 2.5 > > from python.org painlessly, but it looks like > > I'll have to compile numpy from source. > > Do I understand that right? > > I believe you'll have to if you want to use Python 2.5. > > > ... so I am hoping someone patient > > will point me to or lead me through the steps I need > > to take to successfully install numpy on this platform. > > I think the instructions on the scipy wiki are pretty thorough: > http://scipy.org/Installing_SciPy/Mac_OS_X > > One thing to note is that I think I've seen on this list that people > have been having problems compiling and using num/scipy on Python 2.5 > (on any platform (?)) ... I haven't tried it myself, but that's the > general feeling I've gotten from some of the emails on that subject. > I could be wrong though. > > Another thing to consider would be to install the "Superpack" which > is linked to in the mac section from the scipy downloads page: > http://www.scipy.org/Download > > I also remember seeing on the ML that there were some problems w/ > that superpack it not including some config file for ipython or > something, but I'm not sure. > > For what it's worth, I'm using MacPorts (http://macports.org) to > manage my python (and a other) installations, and have been compiling > scipy/numpy/matplotlib/ipython from svn checkouts every now and > again ... this has been working well for me. The version of python > you get from macports is 2.4.3 > > Hope that helps. > -steve > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > |
|
From: Steve L. <lis...@ar...> - 2006-10-31 18:59:43
|
Hi Alan, > I installed Python 2.5 > from python.org painlessly, but it looks like > I'll have to compile numpy from source. > Do I understand that right? I believe you'll have to if you want to use Python 2.5. > ... so I am hoping someone patient > will point me to or lead me through the steps I need > to take to successfully install numpy on this platform. I think the instructions on the scipy wiki are pretty thorough: http://scipy.org/Installing_SciPy/Mac_OS_X One thing to note is that I think I've seen on this list that people have been having problems compiling and using num/scipy on Python 2.5 (on any platform (?)) ... I haven't tried it myself, but that's the general feeling I've gotten from some of the emails on that subject. I could be wrong though. Another thing to consider would be to install the "Superpack" which is linked to in the mac section from the scipy downloads page: http://www.scipy.org/Download I also remember seeing on the ML that there were some problems w/ that superpack it not including some config file for ipython or something, but I'm not sure. For what it's worth, I'm using MacPorts (http://macports.org) to manage my python (and a other) installations, and have been compiling scipy/numpy/matplotlib/ipython from svn checkouts every now and again ... this has been working well for me. The version of python you get from macports is 2.4.3 Hope that helps. -steve |
|
From: Fernando P. <fpe...@gm...> - 2006-10-31 18:54:30
|
On 10/31/06, Alan Isaac <ai...@am...> wrote: > If other users will not profit from this question, > please consider it OT and ignore it. But perhaps > it will prove useful to some potential numpy users. > > I am a long time Windows user who has been happily > using the Python and numpy installers. At work I > need to use a Mac for a while. I installed Python 2.5 > from python.org painlessly, but it looks like > I'll have to compile numpy from source. > Do I understand that right? > > I have used interpreted languages for pretty much > all my computing needs, so I am hoping someone patient > will point me to or lead me through the steps I need > to take to successfully install numpy on this platform. This is probably a good starting point: http://www.scipy.org/Installing_SciPy/Mac_OS_X There have been numerous threads on this issue recently, so you may also want to do a bit of searching of the mailing list archives. Cheers, f |
|
From: Alan I. <ai...@am...> - 2006-10-31 18:44:11
|
If other users will not profit from this question, please consider it OT and ignore it. But perhaps it will prove useful to some potential numpy users. I am a long time Windows user who has been happily using the Python and numpy installers. At work I need to use a Mac for a while. I installed Python 2.5 from python.org painlessly, but it looks like I'll have to compile numpy from source. Do I understand that right? I have used interpreted languages for pretty much all my computing needs, so I am hoping someone patient will point me to or lead me through the steps I need to take to successfully install numpy on this platform. Thank you, Alan Isaac |
|
From: Fernando P. <fpe...@gm...> - 2006-10-31 18:18:08
|
On 10/31/06, Travis Oliphant <oli...@ee...> wrote: > Fernando Perez wrote: > >I actually worry about the same: I really would like to help, but > >after reading the whole discussion, I realized that the low-level > >details being asked and discussed are something I don't really know > >enough to say anything. And I don't want to sound simply saying 'Hey, > >Travis is great, listen to him!' to python-dev, since that (asides > >from looking silly) can be somewhat counter-productive. > > > > > >How does that sound, Travis? Is that something you think might help > >you, esp. since so many of us are feeling woefully underqualified to > >lend a useful hand in the actual discussion on python-dev? > > > > > > That would be great. I think a couple of things would also be useful. OK, my experience so far has been that there's a certain 'activation barrier' with Wikis, but once pages are there, people for some reason feel more comfortable filling in. So even though it's mostly a place holder, I went ahead and made this: http://www.scipy.org/ArrayInterfacePEP Hopefully as the discussion evolves, this page can be filled in with all the necessary info in one place, and it will become in a few days a solid, organized repository of all the key points in this discussion. This will be a LOT easier to refer to in the python-dev battle than randomly scattered bits of emails in the discussion thread. I'll try to spend more time on it over the next few days to fill in, but I'm pretty busy with other things as well, so hopefully others can pitch in as well. Cheers, f ps - one more thing. This guy: http://blog.vrplumber.com/ has been rewriting the OpenGL bindings using ctypes, and I've seen posts from him about numpy (in his blog). He might be able to contribute something... |
|
From: Charles R H. <cha...@gm...> - 2006-10-31 17:55:57
|
On 10/31/06, John Hunter <jdh...@ac...> wrote: > > >>>>> "Travis" == Travis Oliphant <oli...@ee...> writes: > Travis> All of these seem to define their own objects which are > Travis> basically just interpretations of chunks of memory. At > Travis> one time, we might have said "these should all be > Travis> sub-classes of the ndarray". Now, we are thinking more > > What about blitting pixel buffers from mpl or chaco agg into various > GUI windows, GTK, Tk, WX, etc.... This seems like a ready made case > for the array interface. I could pipe in with an example like this if > it would help. I would also like to see the socket object take a more general type than python strings. I suspect there are a lot of such things in python -- interfaces to services and such -- that would benefit from using a more general interface to memory blocks. But I am not a python developer and don't really know how to make that case. Chuck |
|
From: David L G. <Dav...@no...> - 2006-10-31 17:46:38
|
Perhaps you could please elaborate on what you regard as "the issue(s)" and "what's at stake"? I'm still comparatively new (been using python and numpy circa 8-9 months), but so far I haven't encountered any problems I'd attribute to "Python's ... [in]ability to share ndarray-like information". (The most vexing problems I've had have all been with matplotlib, its dual-mode API, and its rather clumsy and haphazard documentation.) I'd like to be supportive, but not blindly-so. DG Travis Oliphant wrote: > I'm recruiting more comments on python-dev regarding my two proposals > for improving Python's native ability to share ndarray-like information. > > There is a dearth of scientific-computing and number-crunching-aware > people on python-dev. The result is that I sound like a lone voice > arguing for something that nobody cares about. When, I don't think that > is true. Please, please. If you want Python to grow support for the > array interface (or something like it), then please speak up on > python-dev. > > Even something as simple as I really see the need for a way to exchange > data-format information between two objects sharing the buffer protocol > can be helpful. > > You can post through the gmane newsgroup interface: > > gmane.comp.python.devel > > Find any of the posts on the PEP's I've introduced. Thanks for your help. > > -Travis > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > -- HMRD/ORR/NOS/NOAA <http://response.restoration.noaa.gov/emergencyresponse/> |
|
From: Travis O. <oli...@ee...> - 2006-10-31 17:25:31
|
Travis Oliphant wrote: >Matthew Brett wrote: > > >>Hi, >> >>I notice that the value for: >> >>zeros((1,), dtype=object).dtype.hasobject >> >>is now 63, whereas previously it had been 1. Is this intended? >> >> >> >> > >Yes. We are using hasobject as an 8-bit flag now and separating out >some of the concepts that make object arrays object arrays. > >This will be in 1.0.1 which will come out soon. It should be binary >compatible with 1.0. > > Let me follow up with this. I've changed back dtype.hasobject so that it returns a Python boolean object. Thus comparisons to 1 should work fine. Under the covers it is (dtype->hasobject & NPY_ITEM_HASOBJECT) == NPY_ITEM_HASOBJECT) There is a new attribute (flags) that contains all the flags in the hasobject variable. -Travis |
|
From: John H. <jdh...@ac...> - 2006-10-31 17:15:18
|
>>>>> "Travis" == Travis Oliphant <oli...@ee...> writes:
Travis> All of these seem to define their own objects which are
Travis> basically just interpretations of chunks of memory. At
Travis> one time, we might have said "these should all be
Travis> sub-classes of the ndarray". Now, we are thinking more
What about blitting pixel buffers from mpl or chaco agg into various
GUI windows, GTK, Tk, WX, etc.... This seems like a ready made case
for the array interface. I could pipe in with an example like this if
it would help.
JDH
|
|
From: Travis O. <oli...@ee...> - 2006-10-31 17:04:54
|
Fernando Perez wrote: >On 10/31/06, Rich Shepard <rsh...@ap...> wrote: > > >>On Tue, 31 Oct 2006, Alan Isaac wrote: >> >> >> >>>The easiest access to this discussion for me was >>>http://news.gmane.org/group/gmane.comp.python.devel/ I cannot add to this >>>discussion, but I REALLY hope others will help Travis out here. (A few >>>have.) He is fielding a lot of questions, some of which look to me to be >>>from individuals who are ready to have fairly strong opinions without >>>really understanding the "why" of his proposals. >>> >>> >> All this is sufficiently far from my areas of expertise that I cannot >>contribute anything useful. Otherwise, I'd be happy to lend support. >> >> > >I actually worry about the same: I really would like to help, but >after reading the whole discussion, I realized that the low-level >details being asked and discussed are something I don't really know >enough to say anything. And I don't want to sound simply saying 'Hey, >Travis is great, listen to him!' to python-dev, since that (asides >from looking silly) can be somewhat counter-productive. > > >How does that sound, Travis? Is that something you think might help >you, esp. since so many of us are feeling woefully underqualified to >lend a useful hand in the actual discussion on python-dev? > > That would be great. I think a couple of things would also be useful. 1) Some way to indicate to python-dev that I'm actually speaking for more than just myself. So, while I agree that just supporting my PEP (which probably in reality needs work) without understanding it is counter-productive, a voice that says. "We really do need this kind of functionality" is at least one more voice. 2) Examples of sharing memory between two objects. PIL is the classic example and has some merit, but because the internal memory layout of the PIL is 'pointer-to-pointers' instead of 'big-chunk-of-memory' it's not a 1-1 match to NumPy and the array interface only can comunicate information about the "mode." But, I can see other examples. PyMedia, PyGame, PyVideo? CVXOPT, PyVoxel. All of these seem to define their own objects which are basically just interpretations of chunks of memory. At one time, we might have said "these should all be sub-classes of the ndarray". Now, we are thinking more along the lines of "these should all expose an array interface". The array interface is still more bulky then it needs to be (it has to go through the attribute-lookup process which can be slow). It would be much better if the extended buffer protocol were available as a function-pointer on the type object of the type. If you have an application where you've ever wanted NumPy in the core. See if the extended buffer protocol serves your purposes and if you agree, voice your approval for the PEP. In my mind, the data-format PEP does not need to go through if there really is a better way to pass data-format information through the buffer protocol. But, the extended buffer protocol we *do* need. -Travis >Regards, > >f >_______________________________________________ >SciPy-user mailing list >Sci...@sc... >http://projects.scipy.org/mailman/listinfo/scipy-user > > |
|
From: Alan I. <ai...@am...> - 2006-10-31 16:14:11
|
On Tue, 31 Oct 2006, Travis Oliphant wrote: > Please, please. If you want Python to grow support for > the array interface (or something like it), then please > speak up on python-dev. The easiest access to this discussion for me was http://news.gmane.org/group/gmane.comp.python.devel/ I cannot add to this discussion, but I REALLY hope others will help Travis out here. (A few have.) He is fielding a lot of questions, some of which look to me to be from individuals who are ready to have fairly strong opinions without really understanding the "why" of his proposals. The good news is, there seems to be (on my naive reading) some sympathy for what Travis is trying to do. I think more motivating examples would prove helpful in swinging things. Cheers, Alan Isaac |
|
From: David C. <da...@ar...> - 2006-10-31 13:38:40
|
Hi,
I improved pyaudio last WE using indications given by various people
on the list or privately, and as I finally got the motivation to set-up
something which looks like a webpage, there is a doc with examples which
show how to use it. The API to open files for writing is much saner, and
the setup.py should be smart enough to grab all informations necessary
to the wrapper, including the location of the shared libsndfile:
download:
http://www.ar.media.kyoto-u.ac.jp/members/david/softwares/pyaudio/#installation
doc + examples:
http://www.ar.media.kyoto-u.ac.jp/members/david/softwares/pyaudio/
I would appreciate to hear reports on platforms which are not linux
(windows, mac os X) to see if my the setup.py works there,
Cheers,
David
|
|
From: Travis O. <oli...@ie...> - 2006-10-31 12:56:05
|
I'm recruiting more comments on python-dev regarding my two proposals for improving Python's native ability to share ndarray-like information. There is a dearth of scientific-computing and number-crunching-aware people on python-dev. The result is that I sound like a lone voice arguing for something that nobody cares about. When, I don't think that is true. Please, please. If you want Python to grow support for the array interface (or something like it), then please speak up on python-dev. Even something as simple as I really see the need for a way to exchange data-format information between two objects sharing the buffer protocol can be helpful. You can post through the gmane newsgroup interface: gmane.comp.python.devel Find any of the posts on the PEP's I've introduced. Thanks for your help. -Travis |
|
From: Xavier G. <gn...@ob...> - 2006-10-31 11:05:00
|
Hi, Your histograms functions look fine for me :) As it is a quite usual operation on an array, I would suggest to put it in numpy as numpy.histogram. IMHO, there is no point to create an numpy.stats only for histograms (or do you have plans to move other stats related function to numpy.stats?) Xavier. > Nicolas, thanks for the bug report, I fooled around with argument > passing and should have checked every case. > > You'll find the histogram function that deals with weights on the > numpy trac ticket 189, <http://projects.scipy.org/scipy/numpy/ticket/189> > I'm waiting for some hints as to where the histogram function should > reside (numpy.histogram, numpy.stats.histogram, ...) before submitting > a patch . > > Salut, > David > > > 2006/10/25, Nicolas Champavert <nic...@ob... > <mailto:nic...@ob...>>: > > Hi, > > it would be great if you could add the weight option in the 1D > histogram too. > > Nicolas > > David Huard a écrit : > > Xavier, > > Here is the patch against svn. Please report any bug. I haven't had > > the time to test it extensively, something that should be done > before > > commiting the patch to the repo. I'd appreciate your feedback. > > > > David > > > > 2006/10/24, David Huard < dav...@gm... > <mailto:dav...@gm...> > > <mailto:dav...@gm... <mailto:dav...@gm...>>>: > > > > Hi Xavier, > > > > You could tweak histogram2d to do what you want, or you > could give > > me a couple of days and I'll do it and let you know. If you want > > to help, you could write a test using your particular > application > > and data. > > > > David > > > > > > 2006/10/24, Xavier Gnata < gn...@ob... > <mailto:gn...@ob...> > > <mailto:gn...@ob... > <mailto:gn...@ob...>>>: > > > > Hi, > > > > I have a set of 3 1D large arrays. > > The first 2 one stand for the coordinates of particules and > > the last one > > for their masses. > > I would like to be able to plot this data ie to compute > a 2D > > histogram > > summing the masses in each bin. > > I cannot find a way to do that without any loop on the > indices > > resulting > > too a very slow function. > > > > I'm looking for an elegant way to do that with numpy (or > > scipy??) function. > > > > For instance, scipy.histogram2d cannot do the job because it > > only counts > > the number of samples in each bin. > > There is no way to deal with weights. > > > > Xavier. > > > > > > -- > > ############################################ > > Xavier Gnata > > CRAL - Observatoire de Lyon > > 9, avenue Charles André > > 69561 Saint Genis Laval cedex > > Phone: +33 4 78 86 85 28 > > Fax: +33 4 78 86 83 86 > > E-mail: gn...@ob... > <mailto:gn...@ob...> <mailto:gn...@ob... > <mailto:gn...@ob...>> > > ############################################ > > > > > > > ------------------------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web > > services, security? > > Get stuff done quickly with pre-integrated technology to > make > > your job easier > > Download IBM WebSphere Application Server v.1.0.1 based on > > Apache Geronimo > > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642> > > > <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>> > > _______________________________________________ > > Numpy-discussion mailing list > > Num...@li... > <mailto:Num...@li...> > > <mailto:Num...@li... > <mailto:Num...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > > > > > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642> > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > <mailto:Num...@li...> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ------------------------------------------------------------------------ > > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > -- ############################################ Xavier Gnata CRAL - Observatoire de Lyon 9, avenue Charles André 69561 Saint Genis Laval cedex Phone: +33 4 78 86 85 28 Fax: +33 4 78 86 83 86 E-mail: gn...@ob... ############################################ |
|
From: Travis O. <oli...@ie...> - 2006-10-31 05:20:47
|
Colin J. Williams wrote: > Line 71 has: data.view(subtype) > > This appears to involve a call to __array_finalize__. Is this an > unconditional call? > Yes. Every-time an array is constructed the __array_finalize__ method is called unless the __array_finalize__ attribute is None > If not, what are the conditions? > > Why not use __init__ to handle these things, since it is always called > after the __new__? > Because __init__ must have the same calling signature as __new__ and we have no way of knowing what it is. -Travis |
|
From: Travis O. <oli...@ie...> - 2006-10-31 05:18:06
|
Tom Denniston wrote: > I recently upgraded to numpy 1.0 from 1.0b5. I noticed that > numpy.argmax behavior is very strange on object arrays. See below: > > (Pdb) numpy.__version__ > '1.0' > (Pdb) numpy.argmax(numpy.array([2, 3], dtype=object)) > 0 > (Pdb) numpy.argmax(numpy.array([2, 3], dtype=int)) > 1 > (Pdb) numpy.argmax(numpy.array([2, 3], dtype=object), axis=0) > 0 > > > I would expect the argmax to behave the same on the dtype=int and > dtype=object examples but it doesn't. Am I missing some subtelty or > is this just a bug? 1.0 is the most recent version, right? This is a bug. I've fixed in in SVN. Thanks for the test. -Travis |
|
From: Travis O. <oli...@ie...> - 2006-10-31 04:45:45
|
Matthew Brett wrote: > Hi, > > I notice that the value for: > > zeros((1,), dtype=object).dtype.hasobject > > is now 63, whereas previously it had been 1. Is this intended? > > Yes. We are using hasobject as an 8-bit flag now and separating out some of the concepts that make object arrays object arrays. This will be in 1.0.1 which will come out soon. It should be binary compatible with 1.0. -Travis |
|
From: Andrew S. <str...@as...> - 2006-10-31 01:41:38
|
Fernando Perez wrote: > Here is some more info. We left a long-running job over the weekend > with the prints you suggested. Oddly, something happened at the OS > level which killed our SSH connection to that machine, but the above > numpy dealloc() warning never printed (we logged this). As an aside, I always use GNU screen when starting long-running jobs just in case something like this happens. screen lets you reconnect to a session from any login to a machine. Just a point of information... -Andrew |
|
From: Colin J. W. <cj...@sy...> - 2006-10-31 01:01:36
|
Travis Oliphant wrote: > If anybody has a desire to see the array interface into Python, please > help by voicing an opinion on python-dev in the discussion about adding > data-type objects to Python. There are a few prominent people who > don't get why applications would need to share data-type information > about memory areas. I need help giving reasons why. > > -Travis > It seems to make sense to me. Perhaps a pointer to some document on just what is being proposed would help. Colin W. |
|
From: Fernando P. <fpe...@gm...> - 2006-10-31 00:28:43
|
On 10/30/06, Lisandro Dalcin <da...@gm...> wrote: > FYI, this is what is defined in Include/object.h > > /* PyObject_HEAD defines the initial segment of every PyObject. */ > #define PyObject_HEAD \ > _PyObject_HEAD_EXTRA \ > Py_ssize_t ob_refcnt; \ > struct _typeobject *ob_type; > > #define Py_INCREF(op) ( \ > _Py_INC_REFTOTAL _Py_REF_DEBUG_COMMA \ > (op)->ob_refcnt++) > > #define Py_DECREF(op) \ > if (_Py_DEC_REFTOTAL _Py_REF_DEBUG_COMMA \ > --(op)->ob_refcnt != 0) \ > _Py_CHECK_REFCNT(op) \ > else \ > _Py_Dealloc((PyObject *)(op)) > > And '_Py_CHECK_REFCNT' macro will finally call Py_FatalError > > 'ob_refcnt' is a Py_ssize_t integer, so I think you will not be able > to overflow it, unless in case of C code with refcounting bugs. Am I > right? I think you are, and fortunately this indicates that they /did/ change to a longer data type for refcounting in newer pythons. The box where we have this problem is running 2.3 though, and obviously a runaway refcount in f2py can still die even if it's a longer data type. However, Travis mentioned he just fixed precisely a bug like that in f2py, so I'm optimistic, and I'm currently making a new test. Thanks for the info, f |
|
From: Fernando P. <fpe...@gm...> - 2006-10-31 00:23:44
|
On 10/30/06, Travis Oliphant <oli...@ee...> wrote: > David Huard wrote: > > > Ok, > > I'll update numpy and give it another try tonight. > > > > I just fixed some reference-count problems in f2py today. These were of > the variety that there was a missing decref that would cause the > reference count of certain often-used data-types to increase without > bound and eventually wrap (to 0) in long-running processes using f2py. > > I suspect this is the fundamental problem in both cases. Many thanks, Travis. We're rebuilding numpy and all of our f2py-generated wrappers, and will start a new run. I'll report on the results as well. Cheers, f |
|
From: Christopher B. <Chr...@no...> - 2006-10-30 23:48:29
|
Lisandro Dalcin wrote:
> Perhaps the reason for this is simple:
> few Python core developers are involved in scientific computing and do
> not have a clear idea of what it is needed for this.
Perhaps true, but.....
I imagine one of the issues that the python-dev crowd has is that they
don't want to add features solely for the scientific computing crowd.
Indeed, they don't need to. The features are there in numpy, everyone
who uses numpy has access to them.
The reason I want to have these features in the standard library is that
there are a lot of good uses for them outside the scientific computing
community, and, in particular, for interaction between scientific
computing and more general purpose packages (GUI toolkits, Image
processing, web frameworks, who knows?)
Specifically, this is useful stuff for exchanging data with PIL,
wxPython (two specific uses I have), and Matplotlib could really use it
with all of its back-ends (TK, GTK, QT, etc....).
In addition, I don't think it's on the table at the moment, but an n-d
array has a lot of use well outside of number crunching. I've introduced
a handful of users to numpy just to get access to a nice n-d object
array type for completely no-numeric uses.
Off to go post on python-dev.....
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...
|
|
From: Lisandro D. <da...@gm...> - 2006-10-30 23:10:15
|
On 10/30/06, Lisandro Dalcin <da...@gm...> wrote: > FYI, this is what is defined in Include/object.h > I forgoy to say in Python-2.5 --=20 Lisandro Dalc=EDn --------------- Centro Internacional de M=E9todos Computacionales en Ingenier=EDa (CIMEC) Instituto de Desarrollo Tecnol=F3gico para la Industria Qu=EDmica (INTEC) Consejo Nacional de Investigaciones Cient=EDficas y T=E9cnicas (CONICET) PTLC - G=FCemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 |
|
From: Lisandro D. <da...@gm...> - 2006-10-30 23:05:58
|
On 10/30/06, Fernando Perez <fpe...@gm...> wrote: > On 10/30/06, Charles R Harris <cha...@gm...> wrote: > > > I suspect the real problem is that the refcount keeps going up. Even i= f it > > was unsigned it would eventually wrap to zero and with a bit of luck ge= t > > garbage collected. So probably something isn't decrementing the refcoun= t. > > Oops, my bad: I meant *unsigned long long*, so that the refcount is a > 64-bit object. By the time it wraps around, you'll have run out of > memory long ago. Having 32 bit ref counters can potentially mean you > run out of the counter before you run out of RAM on a system with > sufficient memory. > > Cheers, FYI, this is what is defined in Include/object.h /* PyObject_HEAD defines the initial segment of every PyObject. */ #define PyObject_HEAD=09=09=09\ =09_PyObject_HEAD_EXTRA=09=09\ =09Py_ssize_t ob_refcnt;=09=09\ =09struct _typeobject *ob_type; #define Py_INCREF(op) (=09=09=09=09\ =09_Py_INC_REFTOTAL _Py_REF_DEBUG_COMMA=09\ =09(op)->ob_refcnt++) #define Py_DECREF(op)=09=09=09=09=09\ =09if (_Py_DEC_REFTOTAL _Py_REF_DEBUG_COMMA=09\ =09 --(op)->ob_refcnt !=3D 0)=09=09=09\ =09=09_Py_CHECK_REFCNT(op)=09=09=09\ =09else=09=09=09=09=09=09\ =09=09_Py_Dealloc((PyObject *)(op)) And '_Py_CHECK_REFCNT' macro will finally call Py_FatalError 'ob_refcnt' is a Py_ssize_t integer, so I think you will not be able to overflow it, unless in case of C code with refcounting bugs. Am I right? --=20 Lisandro Dalc=EDn --------------- Centro Internacional de M=E9todos Computacionales en Ingenier=EDa (CIMEC) Instituto de Desarrollo Tecnol=F3gico para la Industria Qu=EDmica (INTEC) Consejo Nacional de Investigaciones Cient=EDficas y T=E9cnicas (CONICET) PTLC - G=FCemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 |
258 messages has been excluded from this view by a project administrator.
