Ralf,
Do these licenses allow fully free distribution of binaries? And are those
binaries themselves redistributive? I.e. with py2exe and friends?
If so, that could be nice.
-Chris
On Dec 14, 2012, at 1:01 PM, Ralf Gommers wrote:
Hi all,
Intel has offered to provide free MKL licenses for mai
Point well taken. It is always a tradeoff / balancing act where you can
have 'anything' but not 'everything'. Where would the fun be if we could
have everything :) ? . In our situation, there were a couple of
extensions that did not work (at least out of the box) in Python 2.7.
Raul
On 14
Hi all,
Intel has offered to provide free MKL licenses for main contributors to
scientific Python projects - at least those listed at numfocus.org/projects/.
Licenses for all OSes that are required can be provided, the condition is
that they're used for building/testing our projects and not for br
On Fri, Dec 14, 2012 at 9:49 AM, Nathaniel Smith wrote:
> The top of the build log has the actual git command they used to check out
> the source - it's some clever GitHub thing that gives the same thing as
> pressing the green button would iirc. You could copy the commands from the
> log to check
The top of the build log has the actual git command they used to check out
the source - it's some clever GitHub thing that gives the same thing as
pressing the green button would iirc. You could copy the commands from the
log to check that out locally though and see what the .travis.tml actually
sa
On Fri, Dec 14, 2012 at 12:32 AM, Nathaniel Smith wrote:
> I only checked this build:
> https://secure.travis-ci.org/#!/certik/numpy/jobs/3656960
> But that log clearly shows 'python setup.py install' being used instead of
> 'pip install'. How certain are you that your branch actually has my fix?
Hi Sergey:
I recently ran into similar problems with ACML.
See an original bug report (https://github.com/numpy/numpy/issues/2728) &
documentation fix (https://github.com/numpy/numpy/pull/2809).
Personally, I ended up using a patch similar to
https://github.com/numpy/numpy/pull/2751 to force
On Fri, Dec 14, 2012 at 2:40 PM, Chao YUE wrote:
> Thanks. You mean actually when numpy handle masked array, it will first
> treat all the base data, and then apply the mask after the treatment.
> and normally the base data of maksed elements will very likely to intrigure
> these errors, and you w
Thanks. You mean actually when numpy handle masked array, it will first
treat all the base data, and then apply the mask after the treatment.
and normally the base data of maksed elements will very likely to intrigure
these errors, and you will see a lot errory warning or print in the process,
and
Dear numpy users,
I think since long I am confused by if a function works as expected or not
for masked array.
like np.reshape works for masked array, but not np.sum (I mean, I expect
np.sum to drop the masked elements when do summing, of course we have
np.ma.sum).
So I always use fuctions precedi
We (STScI) are ending support for Python 2.5 in our stsci_python project
and told our users as much last July. I have no objections to ending
support for Python 2.5.
Chris
On Thu, Dec 13, 2012 at 12:38 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
> The previous proposal to drop py
On Fri, Dec 14, 2012 at 1:57 PM, Chao YUE wrote:
> Dear all,
>
> I tried to capture the zero divide error when I divide a masked array by
> another. It seems that np.seterr is not working for masked array?
> when I do np.divide on two masked array, it directly put the zero divides
> part as being
Dear all,
I tried to capture the zero divide error when I divide a masked array by
another. It seems that np.seterr is not working for masked array?
when I do np.divide on two masked array, it directly put the zero divides
part as being masked. The np.seterr works if the two arrays for dividing
ar
On 14.12.2012 10:17, Sergey Bartunov wrote:
> Now things went even worse. I assume that numpy built with BLAS and
> LAPACK should do dot operation faster than "clean" installation on
> relatively large matirces (say 2000 x 2000). Here I don't use OpenBLAS
> anyway.
No, _dotblas is only built agai
Hi. I'm trying to build numpy (1.6.2 and master from git) with
OpenBLAS on Ubuntu server 11.10.
I succeed with this just once and performance boost was really big for
me, but unfortunately something went wrong with my application and I
had to reinstall numpy. After that I couldn't reproduce this r
I only checked this build:
https://secure.travis-ci.org/#!/certik/numpy/jobs/3656960
But that log clearly shows 'python setup.py install' being used instead of
'pip install'. How certain are you that your branch actually has my fix?
-n
On 14 Dec 2012 03:49, "Ondřej Čertík" wrote:
> On Thu, Dec 13
On 14 Dec 2012 04:14, "Raul Cota" wrote:
>
>
> +1 from me
>
> For what is worth, we are just moving forward from Python 2.2 / Numeric
> and are going to 2.6 and it has been rather painful because of the
> several little details of extensions and other subtleties. I believe we
> will settle there f
So when upgrading everything you prefer to keep the bugs in 2.6 that were
squashed in 2.7? Who has taught IT managers that older and more buggy versions
of software are more "professional" and better for corporate environments?
Sturla
Den 14. des. 2012 kl. 05:14 skrev Raul Cota :
>
> +1 from
18 matches
Mail list logo
