Re: [Numpy-discussion] Use OpenBLAS for the binary releases?

[David Cournapeau]

On Tue, Nov 20, 2012 at 7:35 PM, Dag Sverre Seljebotn
 wrote:
> On 11/20/2012 06:22 PM, David Cournapeau wrote:
>> On Tue, Nov 20, 2012 at 5:03 PM, Sturla Molden  wrote:
>>> On 20.11.2012 15:38, David Cournapeau wrote:
>>>
 I support this as well in principle for our binary release: one issue
 is that we don't have the infrastructure on mac to build an installer
 with multi-arch support, and we can't assume every mac out there has
 SSE 3 or 4 available.
>>>
>>> Perhaps we could check the CPU architecture at run-time, and then load
>>> (or install) the correct extension module? OpenBLAS does have functions
>>> for testing if SSE 3 or 4 are available, which we could adapt:
>>
>> Doing at runtime would be really hard. On windows, our installer does
>> it at install time, and openblas should be pretty much the same than
>> atlas there.
>
> Is there a specific reason it *has* to happen at compile-time? I'd think
> one could do something like just shipping a lot of separate Python
> extensions which are really just the same module linked with different
> versions of the library, and then
>
> if cpu_is_nehalem:
>  import blas_nehalem as blas
> elif ...

For this to work, we would need to to compile not just the library
itself for each arch, but also every extension that link to it (e.g.
for blas, every extension linking to blas would need to be linked
against each arch library). That would be a nightmare to manage.

>
> One thing is one would want to propagate the BLAS/LAPACK to other
> extensions through a function pointer table much like the current NumPy
> C API.

That would be the better solution, but doing this in such a way that
would work on every platform is a significant effort.

David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Use OpenBLAS for the binary releases?

[David Cournapeau]

On Tue, Nov 20, 2012 at 8:52 PM, Henry Gomersall  wrote:
> On Tue, 2012-11-20 at 20:35 +0100, Dag Sverre Seljebotn wrote:
>> Is there a specific reason it *has* to happen at compile-time? I'd
>> think
>> one could do something like just shipping a lot of separate Python
>> extensions which are really just the same module linked with
>> different
>> versions of the library, and then
>>
>> if cpu_is_nehalem:
>>  import blas_nehalem as blas
>> elif ...
>>
>> I'm asking a question about whether this would work in principle, I
>> realize it would perhaps not fit that well in the current NumPy
>> codebase.
>
> I was wondering this in the context of a previous discussion. Could we
> not have an autotune module, that just runs a load of test scripts and
> picks the best library to link against?

You can't easily relink at install time, so what you want is pick up
the best library at runtime. It is more or less impossible to do this
in a portable way (e.g. there is no solution that I know of on windows
< windows 2008, short of requiring to install some dlls with admin
privileges).

cheers,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Building numpy with OpenBLAS using bento

[David Cournapeau]

On Tue, Nov 20, 2012 at 7:52 PM, George Nurser  wrote:
> Hi,
> I've tried to build numpy with OpenBLAS following on from the blog
> http://cournape.wordpress.com/2012/10/10/notes-on-building-numpyscipy-with-openblas/
>
> I've cloned and installed an up to date version of bento from git.
>
> Problem is that the bentomaker command doesn't seem to know about the
> --with-blas-lapack-libdir option. The only place this option is defined in
> the code seems to be in the blas_lapack.py routine  but I can't see how
> to use this routine -- it isn't imported into any other file.

Can you describe the exact steps you followed ? For example, just
cloning bento won't get you far enough, you need to have waf installed
as well, and you get an explicit error message otherwise.

>
> (I've tried sending this smessage to the bento list, but it doesn't seem to
> be appearing on it as far as I can see.)

Yeah, it looks like librelist is fundamentally broken, many messages
never appear. I need to move to something sane.

cheers,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] confused about univaritespline

[Charles R Harris]

On Tue, Nov 20, 2012 at 12:30 PM, Neal Becker  wrote:

> Pauli Virtanen wrote:
>
> > 20.11.2012 21:11, Neal Becker kirjoitti:
> >> import numpy as np
> >> import matplotlib.pyplot as plt
> >>
> >> ibo = np.array ((12, 14, 16, 18, 20, 22, 24, 26, 28, 29, 29.8, 30.2))
> >> gain_deriv = np.array ((0, 0,  0,  0,   0, 0,  .2, .4, .5, .5, 0,
>  -2))
> >>
> >> import scipy.interpolate
> >> s = scipy.interpolate.UnivariateSpline(ibo, gain_deriv, s=0.1)
> >>
> >> xs = linspace(12, 31, 100)
> >> gain = np.vectorize (lambda x: s.integral (12, x)) (xs)
> >>
> >> plot (xs, s(xs))
> >> plot (xs, gain)
> >
> >>From fitpack/splint.f:
> >
> > c   s(x) is considered to be identically zero outside
> > c   the interval (t(k+1),t(n-k)).
> >
> > Not documented in the Python wrapper, though.
> >
>
> Ah, thanks!  Bitten one more by the fact that spline is not meant for
> extrapolation, which here I had done inadvertantly.
>
> IMO, if spline isn't intended to be used to extrapolate, I'd prefer it to
> throw.
>

That can be tricky at the ends due to round off errors. I added a flag to
splev for this back when:

outine splev evaluates in a number of points x(i),i=1,2,...,m
c  a spline s(x) of degree k, given in its b-spline representation.
c
c  calling sequence:
c call splev(t,n,c,k,x,y,m,e,ier)
c
c  input parameters:
ct: array,length n, which contains the position of the knots.
cn: integer, giving the total number of knots of s(x).
cc: array,length n, which contains the b-spline coefficients.
ck: integer, giving the degree of s(x).
cx: array,length m, which contains the points where s(x) must
c   be evaluated.
cm: integer, giving the number of points where s(x) must be
c   evaluated.
ce: integer, if 0 the spline is extrapolated from the end
c   spans for points not in the support, if 1 the spline
c   evaluates to zero for those points, and if 2 ier is set to
c   1 and the subroutine returns.


Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Use OpenBLAS for the binary releases?

[Henry Gomersall]

On Tue, 2012-11-20 at 20:35 +0100, Dag Sverre Seljebotn wrote:
> Is there a specific reason it *has* to happen at compile-time? I'd
> think 
> one could do something like just shipping a lot of separate Python 
> extensions which are really just the same module linked with
> different 
> versions of the library, and then
> 
> if cpu_is_nehalem:
>  import blas_nehalem as blas
> elif ...
> 
> I'm asking a question about whether this would work in principle, I 
> realize it would perhaps not fit that well in the current NumPy
> codebase. 

I was wondering this in the context of a previous discussion. Could we
not have an autotune module, that just runs a load of test scripts and
picks the best library to link against?

Cheers,

Henry

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Building numpy with OpenBLAS using bento

[George Nurser]

Hi,
I've tried to build numpy with OpenBLAS following on from the blog
http://cournape.wordpress.com/2012/10/10/notes-on-building-numpyscipy-with-openblas/

I've cloned and installed an up to date version of bento from git.

Problem is that the bentomaker command doesn't seem to know about
the --with-blas-lapack-libdir option. The only place this option is defined
in the code seems to be in the blas_lapack.py routine  but I can't see
how to use this routine -- it isn't imported into any other file.

(I've tried sending this smessage to the bento list, but it doesn't seem to
be appearing on it as far as I can see.)

Best regards, George Nurser
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Use OpenBLAS for the binary releases?

[Dag Sverre Seljebotn]

On 11/20/2012 08:35 PM, Dag Sverre Seljebotn wrote:
> On 11/20/2012 06:22 PM, David Cournapeau wrote:
>> On Tue, Nov 20, 2012 at 5:03 PM, Sturla Molden  wrote:
>>> On 20.11.2012 15:38, David Cournapeau wrote:
>>>
 I support this as well in principle for our binary release: one issue
 is that we don't have the infrastructure on mac to build an installer
 with multi-arch support, and we can't assume every mac out there has
 SSE 3 or 4 available.
>>>
>>> Perhaps we could check the CPU architecture at run-time, and then load
>>> (or install) the correct extension module? OpenBLAS does have functions
>>> for testing if SSE 3 or 4 are available, which we could adapt:
>>
>> Doing at runtime would be really hard. On windows, our installer does
>> it at install time, and openblas should be pretty much the same than
>> atlas there.
>
> Is there a specific reason it *has* to happen at compile-time? I'd think

Sorry, I meant install-time.

DS

> one could do something like just shipping a lot of separate Python
> extensions which are really just the same module linked with different
> versions of the library, and then
>
> if cpu_is_nehalem:
>  import blas_nehalem as blas
> elif ...
>
> I'm asking a question about whether this would work in principle, I
> realize it would perhaps not fit that well in the current NumPy codebase.
>
> One thing is one would want to propagate the BLAS/LAPACK to other
> extensions through a function pointer table much like the current NumPy
> C API.
>
> Dag Sverre

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Use OpenBLAS for the binary releases?

[Dag Sverre Seljebotn]

On 11/20/2012 06:22 PM, David Cournapeau wrote:
> On Tue, Nov 20, 2012 at 5:03 PM, Sturla Molden  wrote:
>> On 20.11.2012 15:38, David Cournapeau wrote:
>>
>>> I support this as well in principle for our binary release: one issue
>>> is that we don't have the infrastructure on mac to build an installer
>>> with multi-arch support, and we can't assume every mac out there has
>>> SSE 3 or 4 available.
>>
>> Perhaps we could check the CPU architecture at run-time, and then load
>> (or install) the correct extension module? OpenBLAS does have functions
>> for testing if SSE 3 or 4 are available, which we could adapt:
>
> Doing at runtime would be really hard. On windows, our installer does
> it at install time, and openblas should be pretty much the same than
> atlas there.

Is there a specific reason it *has* to happen at compile-time? I'd think 
one could do something like just shipping a lot of separate Python 
extensions which are really just the same module linked with different 
versions of the library, and then

if cpu_is_nehalem:
 import blas_nehalem as blas
elif ...

I'm asking a question about whether this would work in principle, I 
realize it would perhaps not fit that well in the current NumPy codebase.

One thing is one would want to propagate the BLAS/LAPACK to other 
extensions through a function pointer table much like the current NumPy 
C API.

Dag Sverre
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] confused about univaritespline

[Neal Becker]

Pauli Virtanen wrote:

> 20.11.2012 21:11, Neal Becker kirjoitti:
>> import numpy as np
>> import matplotlib.pyplot as plt
>> 
>> ibo = np.array ((12, 14, 16, 18, 20, 22, 24, 26, 28, 29, 29.8, 30.2))
>> gain_deriv = np.array ((0, 0,  0,  0,   0, 0,  .2, .4, .5, .5, 0,-2))
>> 
>> import scipy.interpolate
>> s = scipy.interpolate.UnivariateSpline(ibo, gain_deriv, s=0.1)
>> 
>> xs = linspace(12, 31, 100)
>> gain = np.vectorize (lambda x: s.integral (12, x)) (xs)
>> 
>> plot (xs, s(xs))
>> plot (xs, gain)
> 
>>From fitpack/splint.f:
> 
> c   s(x) is considered to be identically zero outside
> c   the interval (t(k+1),t(n-k)).
> 
> Not documented in the Python wrapper, though.
> 

Ah, thanks!  Bitten one more by the fact that spline is not meant for 
extrapolation, which here I had done inadvertantly.

IMO, if spline isn't intended to be used to extrapolate, I'd prefer it to throw.

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] confused about univaritespline

[Pauli Virtanen]

20.11.2012 21:11, Neal Becker kirjoitti:
> import numpy as np
> import matplotlib.pyplot as plt
> 
> ibo = np.array ((12, 14, 16, 18, 20, 22, 24, 26, 28, 29, 29.8, 30.2))
> gain_deriv = np.array ((0, 0,  0,  0,   0, 0,  .2, .4, .5, .5, 0,-2))
> 
> import scipy.interpolate
> s = scipy.interpolate.UnivariateSpline(ibo, gain_deriv, s=0.1)
> 
> xs = linspace(12, 31, 100)
> gain = np.vectorize (lambda x: s.integral (12, x)) (xs)
> 
> plot (xs, s(xs))
> plot (xs, gain)

>From fitpack/splint.f:

c   s(x) is considered to be identically zero outside
c   the interval (t(k+1),t(n-k)).

Not documented in the Python wrapper, though.

-- 
Pauli Virtanen

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] confused about univaritespline

[Neal Becker]

I don't understand why the plot of the spline continues on a negative slope at 
the end, but the plot of the integral of it flattens.

-

import numpy as np
import matplotlib.pyplot as plt

ibo = np.array ((12, 14, 16, 18, 20, 22, 24, 26, 28, 29, 29.8, 30.2))
gain_deriv = np.array ((0, 0,  0,  0,   0, 0,  .2, .4, .5, .5, 0,-2))

import scipy.interpolate
s = scipy.interpolate.UnivariateSpline(ibo, gain_deriv, s=0.1)

xs = linspace(12, 31, 100)
gain = np.vectorize (lambda x: s.integral (12, x)) (xs)

plot (xs, s(xs))
plot (xs, gain)

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Confused with qr decomposition function

[Pauli Virtanen]

20.11.2012 20:03, Virgil Stokes kirjoitti:
[clip]
> Here are two that had opposite signs compared to MATLAB:
[clip]

Interestingly, I get the same signs also for these matrices.

This probably means that the issue is specific to the Windows binaries.
Probably, the ATLAS+LAPACK combination shipped with it is somehow strange.

-- 
Pauli Virtanen

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Confused with qr decomposition function

[Virgil Stokes]

On 2012-11-20 18:09, Pauli Virtanen wrote:
> 20.11.2012 15:24, Virgil Stokes kirjoitti:
> [clip]
>> I am aware that they are both correct; but, if you are doing covariance
>> QR decomposition then you almost surely are interested in the positive
>> results (which is the default for MATLAB and most papers/books on this
>> subject).
> I get exactly identical results from MATLAB (R2011b), Octave, Numpy, and
> Scipy. Can you give an example matrix which behaves differently?
>
> Note that Numpy and Scipy return exactly what LAPACK's *GEQRF routines
> give, and Octave seems also to do this.
>
Here are two that had opposite signs compared to MATLAB:

array([[  7.07106781e+02,  -2.32273270e+04,  -2.46173719e+04],
[ -3.53553391e+01,  -2.31566171e+04,  -2.46173719e+04],
[  2.32273276e+04,  -3.97555166e+00,  -1.39003725e+03],
[  2.25202208e+04,  -6.48214647e-04,  -1.39004432e+03],
[  2.46527272e+04,   1.31933390e+03,   1.66675481e-19],
[  2.46173719e+04,   1.39401993e+03,  -7.07106781e-03],
[  0.e+00,   0.e+00,   0.e+00],
[  0.e+00,   0.e+00,   0.e+00],
[  0.e+00,   0.e+00,   0.e+00]])


array([[  3.66711160e+04,   3.36224799e+04,   7.60569110e+02, 
-1.19158202e+03],
[  3.24652853e+03,   0.e+00,  -2.32192233e+04, 
-2.46276301e+04],
[ -1.71055253e+04,   0.e+00,   0.e+00, 
-8.47443620e+01],
[  1.15905933e+04,  -3.36224799e+04,  -7.60569110e+02, 
1.19158202e+03],
[ -1.72015604e+04,   0.e+00,   2.32192233e+04, 
2.46276301e+04],
[ -1.72015604e+04,   0.e+00,   0.e+00, 
8.47443620e+01],
[  3.e+01,   0.e+00,   0.e+00, 
0.e+00]])
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Use OpenBLAS for the binary releases?

[David Cournapeau]

On Tue, Nov 20, 2012 at 5:03 PM, Sturla Molden  wrote:
> On 20.11.2012 15:38, David Cournapeau wrote:
>
>> I support this as well in principle for our binary release: one issue
>> is that we don't have the infrastructure on mac to build an installer
>> with multi-arch support, and we can't assume every mac out there has
>> SSE 3 or 4 available.
>
> Perhaps we could check the CPU architecture at run-time, and then load
> (or install) the correct extension module? OpenBLAS does have functions
> for testing if SSE 3 or 4 are available, which we could adapt:

Doing at runtime would be really hard. On windows, our installer does
it at install time, and openblas should be pretty much the same than
atlas there.

We would need a solution on mac (where I really want to get away from
Accelerate which has a very nasty limitation w.r.t GD vs fork, making
multiprocessing with our official numpy  binary essentially useless).

David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Confused with qr decomposition function

[Pauli Virtanen]

20.11.2012 15:24, Virgil Stokes kirjoitti:
[clip]
> I am aware that they are both correct; but, if you are doing covariance
> QR decomposition then you almost surely are interested in the positive
> results (which is the default for MATLAB and most papers/books on this
> subject).

I get exactly identical results from MATLAB (R2011b), Octave, Numpy, and
Scipy. Can you give an example matrix which behaves differently?

Note that Numpy and Scipy return exactly what LAPACK's *GEQRF routines
give, and Octave seems also to do this.

-- 
Pauli Virtanen

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Use OpenBLAS for the binary releases?

[Sturla Molden]

On 20.11.2012 15:38, David Cournapeau wrote:

> I support this as well in principle for our binary release: one issue
> is that we don't have the infrastructure on mac to build an installer
> with multi-arch support, and we can't assume every mac out there has
> SSE 3 or 4 available.

Perhaps we could check the CPU architecture at run-time, and then load 
(or install) the correct extension module? OpenBLAS does have functions 
for testing if SSE 3 or 4 are available, which we could adapt:

https://github.com/xianyi/OpenBLAS/blob/master/cpuid.h
https://github.com/xianyi/OpenBLAS/blob/master/cpuid_x86.c

cf. the last function in cpuid_x86.c called "get_sse".

> We would need more testing first, as this is not a change to make lightly.

I'm not saying it will be easy :)


Sturla
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] the fast way to loop over ndarray elements?

[Chao YUE]

Dear Thouis,

I take some time to check, before I tried with cython, I tried the
np.interp first, and very luckily, it's exeactly what I need.

And with the old written by me, it spend 20 seconds, now it's 0.2 seconds!

Thanks a lot to all you guys.

Chao

On Mon, Nov 19, 2012 at 3:08 PM, Thouis (Ray) Jones wrote:

> On Sat, Nov 17, 2012 at 8:28 AM, Chao YUE  wrote:
> > Dear all,
> >
> > I need to make a linear contrast of the 2D numpy array "data" from an
> > interval to another, the approach is:
> > I have another two list: "base" & "target", then I check for each ndarray
> > element "data[i,j]",
> > if   base[m] =< data[i,j] <= base[m+1], then it will be linearly
> converted
> > to be in the interval of (target[m], target[m+1]),
> > using another function called "lintrans".
> >
> >
> > #The way I do is to loop each row and column of the 2D array, and finally
> > loop the intervals constituted by base list:
> >
> > for row in range(data.shape[0]):
> > for col in range(data.shape[1]):
> > for i in range(len(base)-1):
> > if data[row,col]>=base[i] and data[row,col]<=base[i+1]:
> >
> >
> data[row,col]=lintrans(data[row,col],(base[i],base[i+1]),(target[i],target[i+1]))
> > break  #use break to jump out of loop as the data have
> to be
> > ONLY transferred ONCE.
> >
> >
> > Now the profiling result shows that most of the time has been used in
> this
> > loop over the array ("plot_array_transg"),
> > and less time in calling the linear transformation fuction "lintrans":
> >
> >ncalls tottime  percallcumtimepercall
> > filename:lineno(function)
> >   180470.1100.000  0.1100.000
> > mathex.py:132(lintrans)
> >   112.495  12.495   19.061  19.061
> > mathex.py:196(plot_array_transg)
> >
> >
> > so is there anyway I can speed up this loop?  Thanks for any
> suggestions!!
> >
> > best,
> >
> > Chao
>
> If lintrans() is a linear interpolation, could you use interp?
>
> http://docs.scipy.org/doc/numpy/reference/generated/numpy.interp.html
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
***
Chao YUE
Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL)
UMR 1572 CEA-CNRS-UVSQ
Batiment 712 - Pe 119
91191 GIF Sur YVETTE Cedex
Tel: (33) 01 69 08 29 02; Fax:01.69.08.77.16

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Use OpenBLAS for the binary releases?

[David Cournapeau]

On Mon, Nov 19, 2012 at 5:42 PM, Dag Sverre Seljebotn
 wrote:
> On 11/19/2012 06:12 PM, Sturla Molden wrote:
>> I think NumPy and SciPy should consider to use OpenBLAS (a fork of
>> GotoBLAS2) instead of ATLAS or f2c'd Netlib BLAS for the binary releases.
>>
>> Here are its virtues:
>>
>> * Very easy to build: Just a makefile, no configuration script or
>> special build tools.
>>
>> * Building ATLAS can be a PITA. So why bother?
>>
>> * Faster than ATLAS, sometimes faster than MKL.
>>
>> * Multithreaded BLAS kernels: OpenMP on Unix, Windows threads on Windows.
>>
>> * The quality of its ancestor GotoBLAS is undisputed. I was the BLAS
>> implementation of choice for major HPC projects around the World.
>>
>> * Free as in BSD licensed.
>>
>> * Funded and developed for use in major Chinese HPC projects. Actively
>> maintained. (GotoBLAS2 is abandonware.)
>>
>> * Open source. The C sources are a pleasure to read, and very easy to
>> verify.
>>
>> * No OpenMP on Windows means no dependency on pthreads-win32 (an LGPL
>> library) when building with MinGW.
>>
>> * Builds on Windows with MinGW and MSYS, and perhaps even without MSYS.
>>
>> * Cygwin is not needed on Windows (this is just BS from the GotoBLAS
>> documentation). Thus, 64-buit builds are possible (I've built it using
>> TDM-GCC for Win64 and 32-bit MSYS).
>
> +1.
>
> Even on CPUs that are not directly supported, this is at least better
> than reference BLAS.
>
> (On our AMD CPUs, which are too new to have a separate OpenBLAS
> implementation, the implementations for older AMD CPUs still outperform
> at least Intel MKL, because MKL does so poorly on these -- although ACML
> beats them both by a factor 2. And of course on supported CPUs
> (everything Intel and older AMD) OpenBLAS is wonderful.

I support this as well in principle for our binary release: one issue
is that we don't have the infrastructure on mac to build an installer
with multi-arch support, and we can't assume every mac out there has
SSE 3 or 4 available.

We would need more testing first, as this is not a change to make lightly.

cheers,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Compiling NumPy on Windows for Python 3.3 with MSVC 2010

[Peter Cock]

On Fri, Nov 16, 2012 at 10:08 AM, Christoph Gohlke  wrote:
> On 11/16/2012 1:28 AM, Peter Cock wrote:
>> On Thu, Nov 15, 2012 at 6:15 PM, Christoph Gohlke  wrote:
>>>
>>> Naturally the file would be named msvc10compiler.py but the name may be
>>> kept for compatibility reasons. AFAIK msvc10 does not use manifests any
>>> longer for the CRT dependencies and all the code handling msvc9
>>> manifests could be removed for Python 3.3. I have been building
>>> extensions for Python 3.3 with msvc10 and this distutils patch for some
>>> months and did not notice any issues.
>>>
>>
>> Sounds Python 3.3 needs a fix then - have you reported this?
>> If not, could you report it (since you know far more about the
>> Windows build system than I do)?
>>
>> If it will be fixed in Python itself, then perhaps a manual hack like
>> this will be enough for NumPy in the short term. Otherwise, maybe
>> numpy needs to include its own copy of msvc9compiler.py (or
>> msvc10compiler.py)?
>>
>> Thanks,
>>
>> Peter
>
> Could be related to .
>
> Christoph

Thanks Christoph, you're probably right this is linked to
http://bugs.python.org/issue16296

Note here's an example of the manifest file, obtained from a hack
to Python 3.3's distutitls/msvc9compiler.py - looks like there are
no MSVC version numbers in here that we would need to
worry about:

build\temp.win32-3.3\Release\numpy\core\src\_dummy.pyd.manifest


  

  

  

  


I tried the patch from http://bugs.python.org/issue16296
applied by hand (in place of Christoph's one line change),
and it also seemed to work. I wanted to double check this,
so started by reverting to an unmodified copy of Python 3.3.

I just removed Python 3.3, and reinstalled it afresh using
python-3.3.0.msi, then updated to the latest commit on the
master branch of numpy, as it happens Ralf merging my
fixes to get mingw32  to compile numpy Python 3.3:
724da615902b9feb140cb6f7307ff1b1c2596a40

Now a clean numpy build under Python 3.3 with MSVC 10
"just worked", the error "Broken toolchain: cannot link a simple
C program" has gone. The comments in msvc9compiler.py did
mention this manifest stuff was fragile... but I am puzzled.

My hunch right now is that the order of installation of
MSVC 2010 and Python 3.3 could be important. Either
that, or something else changed on the numpy master
which had an impact?

Regards,

Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] PRs for MaskedArray bugs

[Michael Droettboom]

If I may also point out another simple (but critical for astropy) bugfix 
related to masked arrays:


https://github.com/numpy/numpy/pull/2747

Mike

On 11/14/2012 02:46 PM, Thomas Robitaille wrote:

I've recently opened a couple of pull requests that fix bugs with
MaskedArray - these are pretty straightforward, so would it be
possible to consider them in time for 1.7?

https://github.com/numpy/numpy/pull/2703

https://github.com/numpy/numpy/pull/2733

Thanks!
Tom
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Confused with qr decomposition function

[Virgil Stokes]

On 20-Nov-2012 00:30, Charles R Harris wrote:



On Mon, Nov 19, 2012 at 4:17 PM, Virgil Stokes > wrote:


I am using the latest versions of numpy (from
numpy-1.7.0b2-win32-superpack-python2.7.exe) and scipy (from
scipy-0.11.0-win32-superpack-python2.7.exe ) on a windows 7 (32-bit)
platform.

I have used

import numpy as np
q,r = np.linalg.qr(A)

and compared the results obtained  from MATLAB (R2010B)

[q,r] = qr(A)

The q,r returned from numpy are both the negative of theq,r returned
from MATLAB for the same matrix A. I believe that the q,r returned from
MATLAB are correct. Why am I getting their negative from numpy?

Note, I have tried this on several different matrices ---  numpy always
gives the negative of MATLAB's q,r values.
[I mistakenly have already sent a similar email to the scipy list ---
please excuse this mistake.]


They are both correct, the decomposition isn't unique. In particular, if both 
algorithms use Housholder reflections there are two possible reflection planes 
at each step, one of which is more numerically stable than the other, and the 
two choices lead to different signs at each step. That said, MATLAB may be 
normalizing the result in some way or using some other algorithm.


Chuck



___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
I am aware that they are both correct; but, if you are doing covariance QR 
decomposition then you almost surely are interested in the positive results 
(which is the default for MATLAB and most papers/books on this subject).


This problem came up recently when converting MATLAB code to python/numpy, with 
some Kalman Filter/Smooth code. It took some time to isolate the problem. It 
would useful if the documentation (numpy) stated explicitly what the default 
"signs" are for q,r.


Thanks for your interest in the problem, Chuck.

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion