On 28 Mar 2014 05:00, Sankarshan Mudkavi smudk...@uwaterloo.ca wrote:
Hi all,
Apologies for the delay in following up, here is an expanded version of
the proposal, which hopefully clears up most of the details. I have not
included specific implementation details for the code, such as which
Hi,
On Wed, Mar 26, 2014 at 1:41 PM, Nathaniel Smith n...@pobox.com wrote:
On Wed, Mar 26, 2014 at 7:34 PM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
as for using openblas by default in binary builds, no.
pthread openblas build is now fork safe which is great but it is still
not
Matthew Brett matthew.br...@gmail.com wrote:
I see it should be possible to build a full blas and partial lapack
library with eigen [1] [2].
Eigen has a licensing issue as well, unfortunately, MPL2.
E.g. it requires recipients to be informed of the MPL requirements (cf.
impossible with pip
On Fri, Mar 28, 2014 at 3:31 PM, Alan G Isaac alan.is...@gmail.com wrote:
On 3/28/2014 10:54 AM, Sturla Molden wrote:
Eigen has a licensing issue as well, unfortunately, MPL2.
E.g. it requires recipients to be informed of the MPL requirements (cf.
impossible with pip install numpy).
Eigen
On 3/28/2014 10:54 AM, Sturla Molden wrote:
Eigen has a licensing issue as well, unfortunately, MPL2.
E.g. it requires recipients to be informed of the MPL requirements (cf.
impossible with pip install numpy).
Eigen chose MPL2 with the intent that Eigen be usable by
all projects.
On Fri, Mar 28, 2014 at 2:54 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Matthew Brett matthew.br...@gmail.com wrote:
I see it should be possible to build a full blas and partial lapack
library with eigen [1] [2].
Eigen has a licensing issue as well, unfortunately, MPL2.
E.g. it
On Fri, Mar 28, 2014 at 4:58 PM, Robert Kern robert.k...@gmail.com wrote:
On Fri, Mar 28, 2014 at 2:54 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
Matthew Brett matthew.br...@gmail.com wrote:
I see it should be possible to build a full blas and partial lapack
library with eigen [1]
Hi,
On Fri, Mar 28, 2014 at 8:58 AM, Robert Kern robert.k...@gmail.com wrote:
On Fri, Mar 28, 2014 at 2:54 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
Matthew Brett matthew.br...@gmail.com wrote:
I see it should be possible to build a full blas and partial lapack
library with eigen
Matthew Brett matthew.br...@gmail.com wrote:
Does anyone know how their performance compares to MKL or the
reference implementations?
http://eigen.tuxfamily.org/index.php?title=Benchmark
http://gcdart.blogspot.de/2013/06/fast-matrix-multiply-and-ml.html
Sturla
Matthew Brett matthew.br...@gmail.com wrote:
So - is Eigen our best option for optimized blas / lapack binaries on
64 bit Windows?
Maybe not:
http://gcdart.blogspot.de/2013/06/fast-matrix-multiply-and-ml.html
With AVX the difference is possibly even larger.
Sturla
On Fri, Mar 28, 2014 at 8:01 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Matthew Brett matthew.br...@gmail.com wrote:
So - is Eigen our best option for optimized blas / lapack binaries on
64 bit Windows?
Maybe not:
http://gcdart.blogspot.de/2013/06/fast-matrix-multiply-and-ml.html
It's only a problem in that the binary will not be BSD, and we do need to
communicate that appropriately. It will contain a significant component
that is MPL2 licensed. The terms that force us to include the link to the
Eigen source that we used forces downstream redistributors of the binary to
do
Hi,
On Fri, Mar 28, 2014 at 11:56 AM, Sturla Molden sturla.mol...@gmail.com wrote:
Matthew Brett matthew.br...@gmail.com wrote:
Does anyone know how their performance compares to MKL or the
reference implementations?
http://eigen.tuxfamily.org/index.php?title=Benchmark
I don't know how
Hi,
On Fri, Mar 28, 2014 at 12:26 PM, Robert Kern robert.k...@gmail.com wrote:
It's only a problem in that the binary will not be BSD, and we do need to
communicate that appropriately. It will contain a significant component that
is MPL2 licensed. The terms that force us to include the link to
On 28 Mar 2014 20:26, Robert Kern robert.k...@gmail.com wrote:
It's only a problem in that the binary will not be BSD, and we do need to
communicate that appropriately. It will contain a significant component
that is MPL2 licensed. The terms that force us to include the link to the
Eigen source
The BSD license alters the recipient's rights. BSD binaries can be
redistributed without pointing to the sources.
On Mar 28, 2014 7:33 PM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Fri, Mar 28, 2014 at 12:26 PM, Robert Kern robert.k...@gmail.com
wrote:
It's only a problem in that
No, the license does not contain a pointer to the Eigen sources, which is
required.
https://bitbucket.org/eigen/eigen/src/fabd880592ac3343713cc07e7287098afd0f18ca/COPYING.MPL2?at=default
On Mar 28, 2014 7:34 PM, Nathaniel Smith n...@pobox.com wrote:
On 28 Mar 2014 20:26, Robert Kern
On 28 March 2014 19:56, Sturla Molden wrote:
Matthew Brett matthew.br...@gmail.com wrote:
Does anyone know how their performance compares to MKL or the
reference implementations?
http://eigen.tuxfamily.org/index.php?title=Benchmark
Very, very funny and twisted approach to
Of course, that's besides the point. Yes, pretty much everyone that likes
the BSD license of numpy will be okay with the minimal burdens the MPL2
lays on them. The problem is that we need to properly communicate that
license. The PyPI page is not adequate to that task, in my opinion. I have
no
Yes, because they're distributing source. But *our* license file could
contain the text of the BSD, the text of the MPL, and the text Eigen
source is available at http://eigen.org.;
If the only problem with eigen turns out to be that we have to add a line
of text to a file then I think we can
Nathaniel Smith n...@pobox.com wrote:
If the only problem with eigen turns out to be that we have to add a line
of text to a file then I think we can probably manage this somehow.
We would also have to compile Eigen-BLAS for various architectures and CPU
counts. It is not adaptive like MKL or
Hi Nathaniel,
1- You give as an example of naive datetime handling:
np.datetime64('2005-02-25T03:00Z')
np.datetime64('2005-02-25T03:00')
This IIUC is incorrect. The Z modifier is a timezone offset, and for normal
naive datetimes would cause an error.
If what I understand from
FYI
Here are docs for panda of timezone handling
wesm worked thru the various issues w.r.t. conversion, localization, and
ambiguous zone crossing.
http://pandas.pydata.org/pandas-docs/stable/timeseries.html#time-zone-handling
implementation is largely in here:
(underlying impl is a
Hi,
On Fri, Mar 28, 2014 at 12:57 PM, Robert Kern robert.k...@gmail.com wrote:
Of course, that's besides the point. Yes, pretty much everyone that likes
the BSD license of numpy will be okay with the minimal burdens the MPL2 lays
on them. The problem is that we need to properly communicate
Hi,
On Fri, Mar 28, 2014 at 1:28 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Nathaniel Smith n...@pobox.com wrote:
If the only problem with eigen turns out to be that we have to add a line
of text to a file then I think we can probably manage this somehow.
We would also have to compile
I thought OpenBLAS is usually used with reference lapack?
On 28 Mar 2014 22:16, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Fri, Mar 28, 2014 at 1:28 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
Nathaniel Smith n...@pobox.com wrote:
If the only problem with eigen turns out
2014-03-28 22:18 GMT+01:00 Nathaniel Smith n...@pobox.com:
I thought OpenBLAS is usually used with reference lapack?
I am no longer sure myself. Debian thus Ubuntu seem to be only
packaging the BLAS part of OpenBLAS for the libblas.so symlink and
uses the reference implementation of lapack for
On 28.03.2014 22:38, Olivier Grisel wrote:
2014-03-28 22:18 GMT+01:00 Nathaniel Smith n...@pobox.com:
I thought OpenBLAS is usually used with reference lapack?
I am no longer sure myself. Debian thus Ubuntu seem to be only
packaging the BLAS part of OpenBLAS for the libblas.so symlink and
2014-03-28 22:55 GMT+01:00 Julian Taylor jtaylor.deb...@googlemail.com:
On 28.03.2014 22:38, Olivier Grisel wrote:
2014-03-28 22:18 GMT+01:00 Nathaniel Smith n...@pobox.com:
I thought OpenBLAS is usually used with reference lapack?
I am no longer sure myself. Debian thus Ubuntu seem to be
This is great! Has anyone started to work on OSX whl packages for
scipy? I assume the libgfortran, libquadmath libgcc_s dylibs will
not make it as easy as for numpy. Would it be possible to use a static
gcc toolchain as Carl Kleffner is using for his experimental windows
whl packages?
--
On 28.03.2014 23:09, Olivier Grisel wrote:
This is great! Has anyone started to work on OSX whl packages for
scipy? I assume the libgfortran, libquadmath libgcc_s dylibs will
not make it as easy as for numpy. Would it be possible to use a static
gcc toolchain as Carl Kleffner is using for his
Hi,
On Fri, Mar 28, 2014 at 3:09 PM, Olivier Grisel
olivier.gri...@ensta.org wrote:
This is great! Has anyone started to work on OSX whl packages for
scipy? I assume the libgfortran, libquadmath libgcc_s dylibs will
not make it as easy as for numpy. Would it be possible to use a static
gcc
Nathaniel Smith n...@pobox.com wrote:
I thought OpenBLAS is usually used with reference lapack?
It is.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Julian Taylor jtaylor.deb...@googlemail.com wrote:
On 28.03.2014 23:09, Olivier Grisel wrote:
you can get rid of libgfortran and quadmath with the -static-libgfortran
flag
libgcc_s is probably more tricky as scipy uses c++ so -static-libgcc may
need checking before using it
doesn't mac
On 29.03.2014 00:02, Sturla Molden wrote:
Julian Taylor jtaylor.deb...@googlemail.com wrote:
On 28.03.2014 23:09, Olivier Grisel wrote:
you can get rid of libgfortran and quadmath with the -static-libgfortran
flag
libgcc_s is probably more tricky as scipy uses c++ so -static-libgcc may
Olivier Grisel olivier.gri...@ensta.org wrote:
Would it be possible to use a static
gcc toolchain as Carl Kleffner is using for his experimental windows
whl packages?
I think we should consider to device a Fortran to C99 translator.
Sturla
___
On 29/03/14 00:05, Julian Taylor wrote:
But the library is still installed in the system (at least on the 10.9
macs I saw)
I only find it in the gfortran 4.8 I installed separately. Nowhere else.
Sturla
___
NumPy-Discussion mailing list
On Fri, Mar 28, 2014 at 5:09 PM, Sturla Molden sturla.mol...@gmail.com wrote:
On 29/03/14 00:05, Julian Taylor wrote:
But the library is still installed in the system (at least on the 10.9
macs I saw)
I only find it in the gfortran 4.8 I installed separately. Nowhere else.
Have a look at
Hi,
I have submitted a PR (https://github.com/numpy/numpy/pull/4568) that
speeds up `np.vander` by using accumulated multiplication instead of
exponentiation to compute the Vandermonde matrix. For largish matrices the
speed-ups can be quite dramatic, over an order of magnitude.
Julian has raised
39 matches
Mail list logo
