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
On Fri, Mar 28, 2014 at 5:09 PM, Sturla Molden 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 the README for
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
NumPy-Di
Olivier Grisel 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
___
NumPy-Discussion mailing
On 29.03.2014 00:02, Sturla Molden wrote:
> Julian Taylor 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
Julian Taylor 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 provide libgcc_s anyway? Eve
Nathaniel Smith 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
Hi,
On Fri, Mar 28, 2014 at 3:09 PM, 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 Kle
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
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?
--
Olivie
2014-03-28 22:55 GMT+01:00 Julian Taylor :
> On 28.03.2014 22:38, Olivier Grisel wrote:
>> 2014-03-28 22:18 GMT+01:00 Nathaniel Smith :
>>> 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
On 28.03.2014 22:38, Olivier Grisel wrote:
> 2014-03-28 22:18 GMT+01:00 Nathaniel Smith :
>> 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 th
2014-03-28 22:18 GMT+01:00 Nathaniel Smith :
> 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 the liblapack
I thought OpenBLAS is usually used with reference lapack?
On 28 Mar 2014 22:16, "Matthew Brett" wrote:
> Hi,
>
> On Fri, Mar 28, 2014 at 1:28 PM, Sturla Molden
> wrote:
> > Nathaniel Smith wrote:
> >
> >> If the only problem with eigen turns out to be that we have to add a
> line
> >> of text t
Hi,
On Fri, Mar 28, 2014 at 1:28 PM, Sturla Molden wrote:
> Nathaniel Smith 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 archit
Hi,
On Fri, Mar 28, 2014 at 12:57 PM, Robert Kern 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 that license.
> The P
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 datetime64
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 unders
Nathaniel Smith 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 OpenBLAS.
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 pr
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 pro
On 28 March 2014 19:56, Sturla Molden wrote:
> Matthew Brett 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 legend-ordering-in-a-plot
ap
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" wrote:
> On 28 Mar 2014 20:26, "Robert Kern" wrote:
> >
> > It's
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" wrote:
> Hi,
>
> On Fri, Mar 28, 2014 at 12:26 PM, Robert Kern
> wrote:
> > It's only a problem in that the binary will not be BSD, and we do
On 28 Mar 2014 20:26, "Robert Kern" 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 that we used force
Hi,
On Fri, Mar 28, 2014 at 12:26 PM, Robert Kern 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
Hi,
On Fri, Mar 28, 2014 at 11:56 AM, Sturla Molden wrote:
> Matthew Brett 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 relevant these are to our case. If I under
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
On Fri, Mar 28, 2014 at 8:01 PM, Sturla Molden wrote:
> Matthew Brett 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
Matthew Brett 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
__
Matthew Brett 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
___
Nu
Hi,
On Fri, Mar 28, 2014 at 8:58 AM, Robert Kern wrote:
> On Fri, Mar 28, 2014 at 2:54 PM, Sturla Molden
> wrote:
>> Matthew Brett 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, unfort
On Fri, Mar 28, 2014 at 4:58 PM, Robert Kern wrote:
> On Fri, Mar 28, 2014 at 2:54 PM, Sturla Molden
> wrote:
>> Matthew Brett 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, unfortunate
On Fri, Mar 28, 2014 at 2:54 PM, Sturla Molden wrote:
> Matthew Brett 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
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".
http:/
On Fri, Mar 28, 2014 at 3:31 PM, Alan G Isaac 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 chose MPL2
Matthew Brett 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 install numpy).
Sturl
Hi,
On Wed, Mar 26, 2014 at 1:41 PM, Nathaniel Smith wrote:
> On Wed, Mar 26, 2014 at 7:34 PM, Julian Taylor
> 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 reliable enough for a default.
>> E.g.
On 28 Mar 2014 05:00, "Sankarshan Mudkavi" 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
functions to modify
39 matches
Mail list logo
