Hello,
the following code using np.object_ data types works with numpy 1.5.1
but fails with 1.6.2. Is this intended or a regression? Other data
types, np.float64 for example, seem to work.
In [1]: import numpy as np
In [2]: np.array(['a'], dtype='O').astype(('O', [('name', 'O')]))
On Thu, Dec 6, 2012 at 7:35 PM, Bradley M. Froehle
brad.froe...@gmail.com wrote:
Right, but if I link to libcblas, cblas would be available, no?
No, because we don't explicitly check for CBLAS. We assume it is there
if Atlas, Accelerate or MKL is found.
cheers,
David
On Thu, Dec 6, 2012 at
Aha, thanks for the clarification. I've always been surpassed that NumPy
doesn't ship with a copy of CBLAS. It's easy to compile --- just a thin
wrapper over BLAS, if I remember correctly.
-Brad
On Friday, December 7, 2012 at 4:01 AM, David Cournapeau wrote:
On Thu, Dec 6, 2012 at 7:35
One way of fixing this I'm sort of itching to do is to create a
pylapack project which can iterate quickly on these build issues,
run-time selection of LAPACK backend and so on. (With some templates
generating some Cython code it shouldn't be more than a few days for an
MVP.)
Then patch NumPy
Heh, looks like we did the trac migration about a month too soon...
-- Forwarded message --
From: Damon McDougall damon.mcdoug...@gmail.com
Date: Fri, Dec 7, 2012 at 8:15 PM
Subject: [matplotlib-devel] GitHub attachments
To: matplotlib-de...@lists.sourceforge.net
Did everyone
Oh, never mind, I guess they *only* allow image files. So, uh, no test
data files, but if we have any lolcats in the trac attachments, we can
migrate those.
On Fri, Dec 7, 2012 at 9:00 PM, Nathaniel Smith n...@pobox.com wrote:
Heh, looks like we did the trac migration about a month too soon...
On 12/7/12 3:21 PM, Nathaniel Smith wrote:
Oh, never mind, I guess they *only* allow image files. So, uh, no test
data files, but if we have any lolcats in the trac attachments, we can
migrate those.
It looks like what they do is just automatically upload it to their own
cloud, and then
