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
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 wrote:
> Heh, looks like we did the trac migration about a month too soon...
>
> --
Heh, looks like we did the trac migration about a month too soon...
-- Forwarded message --
From: Damon McDougall
Date: Fri, Dec 7, 2012 at 8:15 PM
Subject: [matplotlib-devel] GitHub attachments
To: matplotlib-de...@lists.sourceforge.net
Did everyone see that GitHub now allows a
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 NumP
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
On Thu, Dec 6, 2012 at 7:35 PM, Bradley M. Froehle
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 10:34 AM, David Cou
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')]))
