On Fri, Apr 11, 2014 at 7:58 PM, Stephan Hoyer wrote:
> print datetime(2010, 1, 1) < np.datetime64('2011-01-01') # raises exception
This is somewhat consistent with
>>> from datetime import *
>>> datetime(2010, 1, 1) < date(2010, 1, 1)
Traceback (most recent call last):
File "", line 1, in
On Fri, Apr 11, 2014 at 3:56 PM, Charles R Harris wrote:
> Are we in a position to start looking at implementation? If so, it would
> be useful to have a collection of test cases, i.e., typical uses with
> specified results. That should also cover conversion from/(to?)
> datetime.datetime.
>
Ind
Okay, I started taking notes here:
https://github.com/numpy/numpy/wiki/BLAS-desiderata
Please add as appropriate...
-n
On Sat, Apr 12, 2014 at 12:19 AM, Nathaniel Smith wrote:
> On Fri, Apr 11, 2014 at 7:29 PM, Julian Taylor
> wrote:
>> x86 cpus are backward compatible with almost all instru
On 12/04/14 01:07, Sturla Molden wrote:
>> ATM the only other way to work with
>> a data set that's larger than memory-divided-by-numcpus is to
>> explicitly set up shared memory, and this is *really* hard for
>> anything more complicated than a single flat array.
>
>
> Not difficult. You just go
On Fri, Apr 11, 2014 at 7:29 PM, Julian Taylor
wrote:
> x86 cpus are backward compatible with almost all instructions they ever
> introduced, so one machine with the latest instruction set supported is
> sufficient to test almost everything.
> For that the runtime kernel selection must be tuneable
On Sat, Apr 12, 2014 at 12:07 AM, Sturla Molden wrote:
> On 12/04/14 00:39, Nathaniel Smith wrote:
>
>> The spawn mode is fine and all, but (a) the presence of something in
>> 3.4 helps only a minority of users, (b) "spawn" is not a full
>> replacement for fork;
>
> It basically does the same as o
On 12/04/14 00:39, Nathaniel Smith wrote:
> The spawn mode is fine and all, but (a) the presence of something in
> 3.4 helps only a minority of users, (b) "spawn" is not a full
> replacement for fork;
It basically does the same as on Windows. If you want portability to
Windows, you must abide by
On Fri, Apr 11, 2014 at 4:25 PM, Sankarshan Mudkavi
wrote:
> So is the consensus that we don't accept any tags at all (not even
> temporarily)? Would that break too much existing code?
>
> Cheers,
> Sankarshan
>
> On Apr 1, 2014, at 2:50 PM, Alexander Belopolsky wrote:
>
>
> On Tue, Apr 1, 2014 a
On Fri, Apr 11, 2014 at 11:26 PM, Sturla Molden wrote:
> On 11/04/14 20:47, Nathaniel Smith wrote:
>
>> Also, while Windows is maybe in the worst shape, all platforms would
>> seriously benefit from the existence of a reliable speed-competitive
>> binary-distribution-compatible BLAS that doesn't b
On Fri, Apr 11, 2014 at 11:25 PM, Sankarshan Mudkavi
wrote:
> So is the consensus that we don't accept any tags at all (not even
> temporarily)? Would that break too much existing code?
Well, we don't know. If anyone has any ideas on how to figure it out
then they should speak up :-).
Barring an
On 11/04/14 20:47, Nathaniel Smith wrote:
> Also, while Windows is maybe in the worst shape, all platforms would
> seriously benefit from the existence of a reliable speed-competitive
> binary-distribution-compatible BLAS that doesn't break fork().
Windows is worst off, yes.
I don't think fork b
So is the consensus that we don't accept any tags at all (not even
temporarily)? Would that break too much existing code?
Cheers,
Sankarshan
On Apr 1, 2014, at 2:50 PM, Alexander Belopolsky wrote:
>
> On Tue, Apr 1, 2014 at 1:12 PM, Nathaniel Smith wrote:
> In [6]: a[0] = "garbage"
> ValueEr
On 11/04/14 04:44, Matthew Brett wrote:
> I've been working on a general wiki page on building numerical stuff on
> Windows:
>
> https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows
I am worried that the conclusion will be that there is no viable BLAS
alternative on Windows...
St
On 12/04/14 00:01, Matthew Brett wrote:
> No - sure - but it would be frustrating if you found yourself
> optimizing with a compiler that is useless for subsequent open-source
> builds.
No, I think MSVC or gcc 4.8/4.9 will work too. It's just that I happen
to have icc and clang on this computer
On Fri, Apr 11, 2014 at 2:58 PM, Sturla Molden wrote:
> On 11/04/14 23:11, Matthew Brett wrote:
>
>> Are you sure that you can redistribute object code statically linked
>> against icc runtimes?
>
> I am not a lawyer...
No - sure - but it would be frustrating if you found yourself
optimizing with
On 11/04/14 23:11, Matthew Brett wrote:
> Are you sure that you can redistribute object code statically linked
> against icc runtimes?
I am not a lawyer...
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/li
Hi,
On Fri, Apr 11, 2014 at 10:05 AM, Sturla Molden wrote:
> Sturla Molden wrote:
>
>> Making a totally new BLAS might seem like a crazy idea, but it might be the
>> best solution in the long run.
>
> To see if this can be done, I'll try to re-implement cblas_dgemm and then
> benchmark against M
On Fri, Apr 11, 2014 at 7:53 PM, Julian Taylor
wrote:
> On 11.04.2014 18:03, Nathaniel Smith wrote:
>> On Fri, Apr 11, 2014 at 12:21 PM, Carl Kleffner wrote:
>>> a discussion about OpenBLAS on the octave maintainer list:
>>> http://article.gmane.org/gmane.comp.gnu.octave.maintainers/38746
>>
>> I
Hi,
On Fri, Apr 11, 2014 at 10:49 AM, Sturla Molden wrote:
> Matthew Brett wrote:
>
>> Man, they have an awful license, making it quite useless for
>> open-source: http://www.pgroup.com/doc/LICENSE.txt
>
> Awful, and insanely expensive. :-(
>
> And if you look at ACML, you will find that the MSV
On 11.04.2014 18:03, Nathaniel Smith wrote:
> On Fri, Apr 11, 2014 at 12:21 PM, Carl Kleffner wrote:
>> a discussion about OpenBLAS on the octave maintainer list:
>> http://article.gmane.org/gmane.comp.gnu.octave.maintainers/38746
>
> I'm getting the impression that OpenBLAS is being both a tanta
On Fri, Apr 11, 2014 at 6:05 PM, Sturla Molden wrote:
> Sturla Molden wrote:
>
>> Making a totally new BLAS might seem like a crazy idea, but it might be the
>> best solution in the long run.
>
> To see if this can be done, I'll try to re-implement cblas_dgemm and then
> benchmark against MKL, Ac
Hi,
On Fri, Apr 11, 2014 at 11:26 AM, Aron Ahmadia wrote:
> Thanks Matthew for putting this page together.
>
> The OpenBLAS guys have been accepting/merging pull requests (their GitHub
> tree shows 26 contributors and no open pull requests), and I know that
> several people from the Python and Ju
On 11.04.2014 19:05, Sturla Molden wrote:
> Sturla Molden wrote:
>
>> Making a totally new BLAS might seem like a crazy idea, but it might be the
>> best solution in the long run.
>
> To see if this can be done, I'll try to re-implement cblas_dgemm and then
> benchmark against MKL, Accelerate a
Hi,
On Fri, Apr 11, 2014 at 9:03 AM, Nathaniel Smith wrote:
> On Fri, Apr 11, 2014 at 12:21 PM, Carl Kleffner wrote:
>> a discussion about OpenBLAS on the octave maintainer list:
>> http://article.gmane.org/gmane.comp.gnu.octave.maintainers/38746
>
> I'm getting the impression that OpenBLAS is b
On 11.04.2014 18:03, Nathaniel Smith wrote:
> On Fri, Apr 11, 2014 at 12:21 PM, Carl Kleffner wrote:
>> a discussion about OpenBLAS on the octave maintainer list:
>> http://article.gmane.org/gmane.comp.gnu.octave.maintainers/38746
>
> I'm getting the impression that OpenBLAS is being both a tanta
Thanks Matthew for putting this page together.
The OpenBLAS guys have been accepting/merging pull requests (their GitHub
tree shows 26 contributors and no open pull requests), and I know that
several people from the Python and Julia community have gotten pull
requests merged. I modified your comm
Hi,
On Fri, Apr 11, 2014 at 4:21 AM, Carl Kleffner wrote:
> Hi,
>
> a small correction: a recent octave for windows is here:
> http://mxeoctave.osuv.de
>
> see http://article.gmane.org/gmane.comp.gnu.octave.maintainers/38124 ...
> Binary of octave 3.8.0 on windows is now prepared in voluntary con
Matthew Brett wrote:
> Man, they have an awful license, making it quite useless for
> open-source: http://www.pgroup.com/doc/LICENSE.txt
Awful, and insanely expensive. :-(
And if you look at ACML, you will find that the MSVC compatible version is
built with the PG compiler. (There is an Intel i
Hi,
On Fri, Apr 11, 2014 at 5:31 AM, Sturla Molden wrote:
> Matthew Brett wrote:
>
>> """
>> This library contains an adaptation of the legacy cblas interface to BLAS for
>> C++ AMP. At this point almost all interfaces are not implemented. One
>> exception is the ampblas_saxpy and ampblas_daxpy
Sturla Molden wrote:
> Making a totally new BLAS might seem like a crazy idea, but it might be the
> best solution in the long run.
To see if this can be done, I'll try to re-implement cblas_dgemm and then
benchmark against MKL, Accelerate and OpenBLAS. If I can get the
performance better than
Nathaniel Smith wrote:
> I unfortunately don't have the skills to actually lead such an effort
> (I've never written a line of asm in my life...), but surely our
> collective communities have people who do?
The assembly part in OpenBLAS/GotoBLAS is the major problem. Not just that
it's AT&T synt
On Fri, Apr 11, 2014 at 12:21 PM, Carl Kleffner wrote:
> a discussion about OpenBLAS on the octave maintainer list:
> http://article.gmane.org/gmane.comp.gnu.octave.maintainers/38746
I'm getting the impression that OpenBLAS is being both a tantalizing
opportunity and a practical thorn-in-the-side
Matthew Brett wrote:
> """
> This library contains an adaptation of the legacy cblas interface to BLAS for
> C++ AMP. At this point almost all interfaces are not implemented. One
> exception is the ampblas_saxpy and ampblas_daxpy which serve as a
> template for the
> implementation of other routi
Hi,
a small correction: a recent octave for windows is here:
http://mxeoctave.osuv.de
see http://article.gmane.org/gmane.comp.gnu.octave.maintainers/38124 ...
Binary of octave 3.8.0 on windows is now prepared in voluntary contribution
by Markus Bergholz.
a discussion about OpenBLAS on the octave
On Fr, 2014-04-11 at 02:36 -0700, techaddict wrote:
> Like how do i convert these to previous versions ?
>
> copyto(ndarray(shape=[length], buffer=ba, offset=16, dtype="float64"), v)
> and
> copyto(ndarray(shape=[rows, cols], buffer=ba, offset=24, dtype="float64",
> order='C'), m)
>
>
First thi
Like how do i convert these to previous versions ?
copyto(ndarray(shape=[length], buffer=ba, offset=16, dtype="float64"), v)
and
copyto(ndarray(shape=[rows, cols], buffer=ba, offset=24, dtype="float64",
order='C'), m)
--
View this message in context:
http://numpy-discussion.10968.n7.nabble.com
Is there a alternative way to mimic the same behaviour like numpy.copyto in
previous versions of numpy ?
--
View this message in context:
http://numpy-discussion.10968.n7.nabble.com/numpy-copyto-alternative-for-previous-versions-than-1-7-0-tp37282.html
Sent from the Numpy-discussion mailing lis
37 matches
Mail list logo
