Re: [Numpy-discussion] ANN: Scipy 0.13.0 beta 1 release

2013-09-02 Thread David Cournapeau
On Mon, Sep 2, 2013 at 5:46 PM, Pauli Virtanen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > 02.09.2013 18:30, David Cournapeau kirjoitti: > [clip] > > Ok, I think the commit 5935030f8cced33e433804a21bdb15572d1d38e8 is > > quite wrong. > > > > It conflates the issue of deal

Re: [Numpy-discussion] ANN: Scipy 0.13.0 beta 1 release

2013-09-02 Thread Pauli Virtanen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, 02.09.2013 18:30, David Cournapeau kirjoitti: [clip] > Ok, I think the commit 5935030f8cced33e433804a21bdb15572d1d38e8 is > quite wrong. > > It conflates the issue of dealing with Accelerate brokenness and > using g77 ABI. I would suggest reverti

Re: [Numpy-discussion] ANN: Scipy 0.13.0 beta 1 release

2013-09-02 Thread David Cournapeau
On Fri, Aug 30, 2013 at 7:16 PM, David Cournapeau wrote: > It looks like it broke the build with MKL as well (in, surprised, ARPACK). > I will investigate this further this WE > Ok, I think the commit 5935030f8cced33e433804a21bdb15572d1d38e8 is quite wrong. It conflates the issue of dealing with

Re: [Numpy-discussion] find appropriate dtype based on a set of values

2013-09-02 Thread Stéfan van der Walt
On Mon, Sep 2, 2013 at 4:21 PM, Gregorio Bastardo wrote: np.min_scalar_type([-1,256]) # int16 expected > dtype('int32') > > Am I missing something? Anyone knows how to achieve the desired operation? The docstring states explicitly that this use case is not supported. Here's one way of doing

[Numpy-discussion] find appropriate dtype based on a set of values

2013-09-02 Thread Gregorio Bastardo
Hi, I'd like to find the smallest possible representation of an array given a set of possible values. I've checked the function 'np.min_scalar_type', it works well for scalar input, but contrary to my assumption when array-like param is given: array's dtype is simply returned, instead of finding a

Re: [Numpy-discussion] numpy.org down - any ETA on when it's back up?

2013-09-02 Thread Robert Kern
On Sun, Sep 1, 2013 at 4:32 PM, Ambrose LI wrote: > > Hi, > > numpy.org has been down for at least a few days and is currently > accessible only through archive.org. So I’m just wondering if anyone > with admin access to the site is working on bringing numpy.org back > up. > > Apparently, github h

Re: [Numpy-discussion] Stick intersection path algorithm

2013-09-02 Thread Robert Kern
On Sun, Sep 1, 2013 at 11:55 PM, Josè Luis Mietta < joseluismie...@yahoo.com.ar> wrote: > > Hi experts! > > I wanna study the intersection between line segments (sticks). > I wrote a algorithm that generate a matrix, M, with N rows and N columns. The M-element Mij is 1 if stick number 'i' intersect

Re: [Numpy-discussion] Are NEPs still a thing?

2013-09-02 Thread Robert Kern
On Mon, Sep 2, 2013 at 8:53 AM, Juan Luis Cano wrote: > > The subject speaks for itself, I was diving into NumPy source code and > saw some NEPs, and I wonder if there still function as a mechanism to > propose changes to NumPy, and if it is documented somewhere. Yes, the NEP "process", such as i

Re: [Numpy-discussion] Deprecation of financial routines

2013-09-02 Thread Juan Luis Cano
[snip] On 08/19/2013 05:06 PM, Joe Harrington wrote: > A reorg that would bring us to a very heirarchical structure would be > disruptive to existing code. Yet, there are maintenance and startup > speed arguments in favor of a heirarchy. However we resolve it, I don't > know that singling out th

[Numpy-discussion] Are NEPs still a thing?

2013-09-02 Thread Juan Luis Cano
The subject speaks for itself, I was diving into NumPy source code and saw some NEPs, and I wonder if there still function as a mechanism to propose changes to NumPy, and if it is documented somewhere. ___ NumPy-Discussion mailing list NumPy-Discussion@

Re: [Numpy-discussion] Faster np.triu_indices

2013-09-02 Thread Stéfan van der Walt
On Mon, Sep 2, 2013 at 12:38 AM, Daniel Smith wrote: > This is just a first run at the function, and unfortunately does not work for > k<0. However, it does return the correct results for k>=0 and is between 2-8 > faster on my machine then `np.triu_indices`. Any thoughts on this? That looks lik