Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

On Tue, May 25, 2010 at 9:22 PM, Travis Oliphant wrote: > > On May 25, 2010, at 4:49 PM, David Goldsmith wrote: > > Travis: do you already have a place on the NumPy Development > Wikiwhere you're (b)logging your design decisions? > Seems like a good way for > concerned p

Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

On 25 May 2010 21:22, Travis Oliphant wrote: > This is a great idea of course and we will definitely post progess there. > So far, the code has been reviewed and several functions identified for > re-factoring.   This is taking place in a github branch of numpy called > numpy refactor. Awesome! S

Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

On May 25, 2010, at 5:06 PM, David Cournapeau wrote: > On Wed, May 26, 2010 at 6:19 AM, Charles R Harris > wrote: > >> Sounds good, but what if it doesn't get finished in a few months? I think we >> should get 2.0.0 out pronto, ideally it would already have been released. I >> think a major ref

Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

On May 25, 2010, at 4:49 PM, David Goldsmith wrote: > Travis: do you already have a place on the NumPy Development Wiki where > you're (b)logging your design decisions? Seems like a good way for concerned > parties to monitor your choices in more or less real time and thus provide > comment i

Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

>> >> I think 2.0 would be a bit early for this. Is there any reason it couldn't >> be done in 2.1? What is the planned policy with regards to the visible >> interface for extensions? It would also be nice to have a rough idea of how >> the resulting code would be layered, i.e., what is the des

Re: [Numpy-discussion] Geometric, negative binomial and poisson fail for extreme arguments

On Tue, May 25, 2010 at 9:20 PM, wrote: > On Tue, May 25, 2010 at 10:34 PM, Charles R Harris > wrote: > > Josef, > > > > This is ticket #896 from two years ago. IIRC, there was some more recent > > discussion on the list of some of these. Do you know what the current > state > > of these distrib

[Numpy-discussion] FW: Numpy python build

Hi, Can I just install numpy and scipy without ATLAS? And what does this means " gnu: no Fortran 90 compiler found"? Im installing on RHEL Thanks in advance! [r...@giswk002 numpy-1.3.0]# python setup.py build Running from numpy source directory. non-existing path in 'numpy/distutils': 'site.cfg

Re: [Numpy-discussion] Geometric, negative binomial and poisson fail for extreme arguments

On Tue, May 25, 2010 at 10:34 PM, Charles R Harris wrote: > Josef, > > This is ticket #896 from two years ago. IIRC, there was some more recent > discussion on the list of some of these. Do you know what the current state > of these distributions is? I don't have any information on these and I do

Re: [Numpy-discussion] Bug in nanmin called with unsigned integers

On Tue, May 25, 2010 at 8:21 PM, Tony S Yu wrote: > I got bit again by this bug with unsigned > integers. > (My original changes got overwritten when I updated from svn and, > unfortunately, merged conflicts without actually looking over the changes.)

Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

2010/5/25 Stéfan van der Walt > On 25 May 2010 15:06, David Cournapeau wrote: > > Naming it 3.0 or 2.1 does not matter much - I think we should avoid > > breaking things twice. I can see a few solutions: > > - postpone 2.0 "indefinitely", until this new work is done > > - backport py3k changes

[Numpy-discussion] Geometric, negative binomial and poisson fail for extreme arguments

Josef, This is ticket #896 from two years ago. IIRC, there was some more recent discussion on the list of some of these. Do you know what the current state of these distributions is? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org htt

[Numpy-discussion] Bug in nanmin called with unsigned integers

I got bit again by this bug with unsigned integers. (My original changes got overwritten when I updated from svn and, unfortunately, merged conflicts without actually looking over the changes.) In any case, I thought it'd be a good time to bump the issue (with patch). Cheers, -Tony PS: Just f

Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

On 25 May 2010 15:06, David Cournapeau wrote: > Naming it 3.0 or 2.1 does not matter much - I think we should avoid > breaking things twice. I can see a few solutions: >  - postpone 2.0 "indefinitely", until this new work is done >  - backport py3k changes to 1.5 (which would be API and ABI > comp

Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

On Tue, May 25, 2010 at 4:31 PM, David Cournapeau wrote: > On Wed, May 26, 2010 at 4:37 AM, Travis Oliphant > wrote: > > > > Hi everyone, > > > > There has been some talk about re-factoring NumPy to separate out the > > Python C-API layer and make NumPy closer to a C-library. I know > > there a

Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

On Tue, 25 May 2010 15:54:26 -0500, Travis Oliphant wrote: >On May 25, 2010, at 2:50 PM, Charles R Harris wrote: > >> >> >> On Tue, May 25, 2010 at 1:37 PM, Travis Oliphant > > wrote: >> >> Hi everyone, >> >> There has been some talk about re-factoring NumPy to separate out the >> Python C-API

Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

On Tue, May 25, 2010 at 4:06 PM, David Cournapeau wrote: > On Wed, May 26, 2010 at 6:19 AM, Charles R Harris > wrote: > > > Sounds good, but what if it doesn't get finished in a few months? I think > we > > should get 2.0.0 out pronto, ideally it would already have been released. > I > > think a

Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

On Wed, May 26, 2010 at 4:37 AM, Travis Oliphant wrote: > > Hi everyone, > > There has been some talk about re-factoring NumPy to separate out the > Python C-API layer and make NumPy closer to a C-library.   I know > there are a few different ideas about what this means, and also that > people are

Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

On Wed, May 26, 2010 at 6:19 AM, Charles R Harris wrote: > Sounds good, but what if it doesn't get finished in a few months? I think we > should get 2.0.0 out pronto, ideally it would already have been released. I > think a major refactoring like this proposal should get the 3.0.0 label. Naming

Re: [Numpy-discussion] Extending documentation to c code

On Tue, May 25, 2010 at 11:18 PM, Benjamin Root wrote: > >> it does - I looked into synopsis because we could use rest, and I >> don't think anyone wants to go the doxygen route. > > I am curious as to why doxygen isn't a viable option.  While I don't have > experience with the other suggestions,

Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

Travis: do you already have a place on the NumPy Development Wikiwhere you're (b)logging your design decisions? Seems like a good way for concerned parties to monitor your choices in more or less real time and thus provide comment in a timely fashion. DG On Tue, May 25, 2

Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

On Tue, May 25, 2010 at 2:54 PM, Travis Oliphant wrote: > > On May 25, 2010, at 2:50 PM, Charles R Harris wrote: > > > > On Tue, May 25, 2010 at 1:37 PM, Travis Oliphant > wrote: > >> >> Hi everyone, >> >> There has been some talk about re-factoring NumPy to separate out the >> Python C-API layer

Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

On May 25, 2010, at 2:50 PM, Charles R Harris wrote: On Tue, May 25, 2010 at 1:37 PM, Travis Oliphant > wrote: Hi everyone, There has been some talk about re-factoring NumPy to separate out the Python C-API layer and make NumPy closer to a C-library. I know there are a few different idea

Re: [Numpy-discussion] __eq__ with str and object

Seems like a bug to me. Certain branches in _array_richcompare return False to fail rather than Py_NotImplemented, which means the string-understanding comparison fallbacks don't run. Attached is a (simple) patch that resolves this bug, and doesn't seem to cause any of the unit tests to fail.

Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

On Tue, May 25, 2010 at 1:37 PM, Travis Oliphant wrote: > > Hi everyone, > > There has been some talk about re-factoring NumPy to separate out the > Python C-API layer and make NumPy closer to a C-library. I know > there are a few different ideas about what this means, and also that > people are

[Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

Hi everyone, There has been some talk about re-factoring NumPy to separate out the Python C-API layer and make NumPy closer to a C-library. I know there are a few different ideas about what this means, and also that people are very busy. I also know there is a NumPy 2.0 release that is

[Numpy-discussion] ensuring docstrings in new code

Over on [Numpy-discussion] Extending documentation to c code, David G. gave voice to a frustration he and I share about the status of documentation in the new-code development process. I don't want to paint with a broad brush, yet in recent months there have been a number of checkins, unanimously

[Numpy-discussion] __eq__ with str and object

I don't understand this: >> a1 = np.array(['a', 'b'], dtype=object) >> a2 = np.array(['a', 'b']) >> >> a1 == a2 array([ True, True], dtype=bool) # Looks good >> a2 == a1 False # Should I have expected this? This works like I expected: >> a1 = np.array([1, 2], dtype=object) >> a2 = np.ar

Re: [Numpy-discussion] Extending documentation to c code

> it does - I looked into synopsis because we could use rest, and I > don't think anyone wants to go the doxygen route. I am curious as to why doxygen isn't a viable option. While I don't have experience with the other suggestions, I have used doxygen in a few of my personall projects and have b

Re: [Numpy-discussion] calling C function from Python via f2py

Thanks for your time and assistance, Nadav. I will look into the SWIG list and or cython. On Mon, May 24, 2010 at 2:37 PM, Nadav Horesh wrote: > > Sorry, can not figure it out, if you don't gen an answer on this list maybe > you should address it on swig list. Personally I use cython for this pu

Re: [Numpy-discussion] Extending documentation to c code

Excerpts from Daniele Nicolodi's message of 2010-05-25 11:37:50 +0200: > On 25/05/10 09:04, Sebastien Binet wrote: > > > note that llvm/clang is versatile enough to easily provide indices into > > the source code, which of course includes the comments... I am actually > > working on improving the

Re: [Numpy-discussion] Extending documentation to c code

On 25/05/10 09:04, Sebastien Binet wrote: > note that llvm/clang is versatile enough to easily provide indices into > the source code, which of course includes the comments... I am actually > working on improving the python bindings to clang (which are already > quite useful for this thread's top

Re: [Numpy-discussion] Extending documentation to c code

Excerpts from David Cournapeau's message of 2010-05-25 09:51:36 +0200: > On Tue, May 25, 2010 at 4:04 PM, Sebastien Binet wrote: > > Excerpts from David Cournapeau's message of 2010-05-25 05:06:09 +0200: > >> On Tue, May 25, 2010 at 3:01 AM, Charles R Harris > > [snip] > >> Maybe as a first step,

Re: [Numpy-discussion] Extending documentation to c code

On Tue, May 25, 2010 at 4:04 PM, Sebastien Binet wrote: > Excerpts from David Cournapeau's message of 2010-05-25 05:06:09 +0200: >> On Tue, May 25, 2010 at 3:01 AM, Charles R Harris > [snip] >> Maybe as a first step, something that could extract function signature >> would be enough, and writing t

Re: [Numpy-discussion] Extending documentation to c code

Hi, ma, 2010-05-24 kello 12:01 -0600, Charles R Harris kirjoitti: > I'm wondering if we could extend the current documentation format to > the c source code. The string blocks would be implemented something > like [clip] I'd perhaps stick closer to C conventions and use something like /** * Spa

Re: [Numpy-discussion] Extending documentation to c code

On Tue, May 25, 2010 at 2:09 PM, David Goldsmith wrote: > > This does sound promising/a good first step.  But it doesn't really answer > Charles' question about a standard (which would be useful to have to help > guide doc editor design). it does - I looked into synopsis because we could use res

Re: [Numpy-discussion] Extending documentation to c code

Excerpts from David Cournapeau's message of 2010-05-25 05:06:09 +0200: > On Tue, May 25, 2010 at 3:01 AM, Charles R Harris [snip] > Maybe as a first step, something that could extract function signature > would be enough, and writing this should not take too much time > (Sebastien B wrote something