ingw dlls in your %PATH%, right ?
David
>
>
> Regards Carl
>
>
> 2013/11/11 David Cournapeau
>
>> Carl,
>>
>> It looks like the google drive contains the binary and not the actual log
>> ? For the log, it is more convenient to put it on gist.github.co
On Mon, Nov 11, 2013 at 1:32 PM, Carl Kleffner wrote:
> Hi David,
>
> i used my customized mingw-w64 toolkit mentioned in this thread to
> circumvent several problems with the mixed compiler enviroment. It is a
> fully statically gcc build. Hence the compiled executables and dlls
?
While gcc 4.4 is not the most recent compiler, it is not ancient either,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Nov 12, 2013 at 6:17 PM, Julian Taylor <
jtaylor.deb...@googlemail.com> wrote:
> On 12.11.2013 03:17, David Cournapeau wrote:
> > Hi there,
> >
> > I have noticed more and more subtle and hard to track serious bugs in
> > numpy and scipy, due to the use
used PyArray_Check without segfault.
Typically, PyArray_Check will be inserted in foo_wrap.c by a typemap,
for example a typemap from numpy.i .
Do you use PyArray_Check in the foo_wrap.c or in another file? Is
PyArray_Check in called in another C library, that _foo.so is linked
with?
David
bers, where numpy.fft is actually O(N^2) and not the usual O(NLogN).
There is unfortunately no freely (aka BSD-like licensed) available fft
implementation that works for prime (or 'close to prime') numbers, and
implementing one that is precise enough is not trivial (look at Bernstein
t
3 orders of magnitude is huge.
This is expected if you go from N log N to N ** 2 for large N :)
You can for example compare np.fft.fft(a) for 2**16 and 2**16+1 (and
2**16-1 that while bad is not prime, so only 1 order of magnitude slower).
David
___
NumP
On Thu, Nov 14, 2013 at 7:05 PM, Jaime Fernández del Río <
jaime.f...@gmail.com> wrote:
> On Thu, Nov 14, 2013 at 9:37 AM, David Cournapeau wrote:
>
>>
>> You can for example compare np.fft.fft(a) for 2**16 and 2**16+1 (and
>> 2**16-1 that while bad is not prime
On Wed, Nov 13, 2013 at 6:16 PM, Julian Taylor <
jtaylor.deb...@googlemail.com> wrote:
> On 13.11.2013 18:26, David Cournapeau wrote:
> >
> >
> > Can you narrow it down to a specific intrinsic? they can be enabled
> and
> > disabled in set ./numpy/core/
; ;)
>
> Sure, give it a shot. Looks like subprocess.Popen was intended to replace
> os.system in any case.
>
Except that output is not 'real time' with straight Popen, and doing so
reliably on every platform (cough - windows - cough) is not completely
trivial. You also have
On Fri, Nov 15, 2013 at 7:41 PM, Robert Kern wrote:
> On Fri, Nov 15, 2013 at 7:28 PM, David Cournapeau
> wrote:
> >
> > On Fri, Nov 15, 2013 at 6:21 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
> >> Sure, give it a shot. Looks like sub
use scipy recently gained lots of files to be
compiled, and sometimes, for some reason, the compilers crash.
See: http://mail.scipy.org/pipermail/scipy-dev/2013-August/019169.html
Now, if using subprocess fixes those, that alone would be a big +1 from me
in its favor. Do you have the patch somewh
On Fri, Nov 15, 2013 at 10:47 PM, Max Linke wrote:
> On Thu, 2013-11-14 at 17:19 +0000, David Cournapeau wrote:
> > On Thu, Nov 14, 2013 at 4:45 PM, Charles Waldman
> wrote:
> >
> > > Can you post the raw data? It seems like there are just a couple of
> "bad&
The program at the bottom of this message returns the following runtime warning:
python test.py
test.py:5: RuntimeWarning: invalid value encountered in divide
return np.where(x==0., 1., np.sin(x)/x)
The function works correctly returning
x = np.array([ 0., 1., 2., 3., 4., 5., 6.,
should not lie to ourselves: our current ATLAS on windows are most
likely not very efficient anyway, SSE or not.
Ralf, you mentioned that openblas was problematic on windows ? I could not
find any recent discussion on that list.
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
scipy, and matplotlib?
>
I did for numpy and scipy. You had to hack a bit numpy.distutils to make it
work for scipy,but nothing that would be too complicated to really fix.
In your case, the trick is to use the setupegg file: python setupegg.py
bdist_wheel
David
> On Windows `bdist_
build
and
setarch x86_64 -B python setup.py build
But with the same results.
Someone worked around this by altering ccompiler.py, but I'm trying to find a
cleaner solution.
See:http://stackoverflow.com/questions/11265057/how-do-i-install-a-32-bit-version-of-num
On 12/12/13 15:54, Julian Taylor wrote:
> On 12.12.2013 19:58, David Jones wrote:
>> I'm trying to compile 32-bit numpy on a 64 bit Centos 6 system, but fails
>> with the message:
>>
>> "Broken toolchain: cannot link a simple C program"
>>
>>
Hi Ralf,
Thanks a lot for the quick fix release.
I can confirm it builds and tests correctly on windows, rhel5 and osx (both
32 and 64 bits).
cheers,
David
On Sun, Dec 8, 2013 at 10:06 AM, Ralf Gommers wrote:
> Hi,
>
> I'm happy to announce the availability of the scipy 0.13.2
On 12/12/13 16:35, Julian Taylor wrote:
> On 12.12.2013 20:40, David Jones wrote:
>> On 12/12/13 15:54, Julian Taylor wrote:
>>> On 12.12.2013 19:58, David Jones wrote:
>>>> I'm trying to compile 32-bit numpy on a 64 bit Centos 6 system, but fails
>&
On 12/12/13 16:35, Julian Taylor wrote:
> On 12.12.2013 20:40, David Jones wrote:
>> On 12/12/13 15:54, Julian Taylor wrote:
>>> On 12.12.2013 19:58, David Jones wrote:
>>>> I'm trying to compile 32-bit numpy on a 64 bit Centos 6 system, but fails
>&
On 12/12/13 16:35, Julian Taylor wrote:
> On 12.12.2013 20:40, David Jones wrote:
>> On 12/12/13 15:54, Julian Taylor wrote:
>>> On 12.12.2013 19:58, David Jones wrote:
>>>> I'm trying to compile 32-bit numpy on a 64 bit Centos 6 system, but fails
>&
cc
wrappers, as suggested below.
As I said, a cleaner, universally applicable method is definitely needed.
>
>
>
> On Fri, Dec 13, 2013 at 8:02 AM, David Jones wrote:
>> On 12/12/13 16:35, Julian Taylor wrote:
>>> On 12.12.2013 20:40, David Jones wrote:
>>>> On
ould be in CFLAGS. (and
> ld flags go into LDFLAGS). Otherwise you are saying to use a program
> called "gcc -m32" (with a space in the name).
>
>
>
> On Fri, Dec 13, 2013 at 8:02 AM, David Jones wrote:
>> On 12/12/13 16:35, Julian Taylor wrote:
>>>
On 12/13/13 13:48, Julian Taylor wrote:
> On 13.12.2013 18:46, David Jones wrote:
>> ...
>>
>> Correction. Of course LD_LIBRARY_PATH isn't seen by the compiler. It
>> only applies at run time. How embarrasing:) This isn't the first time
>> I've be
of work, as buffer management is not really
abstracted in NumPy ATM.
David
>
>
> [1] http://www.python.org/dev/peps/pep-3118/
> [2]
> https://github.com/numpy/numpy/blob/4050ac73af79ae8cc513648ff02e9a22041501c4/numpy/core/src/multiarray/ctors.c#L1253
> [3] http://docs.s
On 12/13/13 13:48, Julian Taylor wrote:
> On 13.12.2013 18:46, David Jones wrote:
>> ...
>>
>> Correction. Of course LD_LIBRARY_PATH isn't seen by the compiler. It
>> only applies at run time. How embarrasing:) This isn't the first time
>> I've be
>
> As for your proposal, it would be good to know if adding a warning would
> actually catch any bugs. For the truncation warning it caught several in
> scipy and other libs IIRC.
>
> Ralf
>
In light of this, perhaps the pertinent unit tests should be modified (even
if the warning suggestion isn'
o last question for Octonion and/or general n-basis
Grassmann (exterior) and/or Clifford Algebras? (rosettacode appears to
have none of these). Thanks!
David Goldsmith
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/m
Thanks Anthony and Paul!
OlyDLG
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
es, though I have not tried the new 3.4 version. See also that
discussion I had with one clang dev @ apple a couple of months ago:
https://twitter.com/cournape/status/381038514076655618
David
>
> Chuck
>
> ___
> NumPy-Discussion mail
On Wed, Jan 15, 2014 at 9:52 AM, wrote:
> Date: Wed, 15 Jan 2014 10:57:51 -0700
> From: Charles R Harris
> Subject: Re: [Numpy-discussion] using loadtxt to load a text file in
> to a numpy array
> To: Discussion of Numerical Python
> Message-ID:
> <
> cab6mnxjpvjbsozzy0ctk1bk+kd
On Mon, Jan 20, 2014 at 9:11 AM, wrote:
> I think that is right. Not having an effective way to handle these common
> scientific data sets will block acceptance of Python 3. But we do need to
> figure out the best way to add this functionality.
>
> Chuck
>
Sounds like it might be time for some f
Am I the only one who feels that this (very important--I'm being sincere,
not sarcastic) thread has matured and specialized enough to warrant it's
own home on the Wiki?
DG
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org
uot;utf-8"
>
> On 21 Jan 2014 17:28, "David Goldsmith" wrote:
> >
> >
> > Am I the only one who feels that this (very important--I'm being sincere,
> not sarcastic) thread has matured and specialized enough to warrant it's
> own home on the
On Tue, Jan 21, 2014 at 10:00 AM, wrote:
> Date: Tue, 21 Jan 2014 09:53:25 -0800
> From: David Goldsmith
> Subject: Re: [Numpy-discussion] A one-byte string dtype?
> To: numpy-discussion@scipy.org
> Message-ID:
> 7altpxmrz4miujy2xebyi_fy5...@mail.gmail.com>
>
Date: Tue, 21 Jan 2014 19:20:12 +
> From: Robert Kern
> Subject: Re: [Numpy-discussion] A one-byte string dtype?
>
> The wiki is frozen. Please do not add anything to it. It plays no role in
> our current development workflow. Drafting a NEP or two and iterating on
> them would be the next
in-visual-studio-2013.aspx
Of course, it will be a while before we can rely on this, but hey, it only
took them 14 years !
David
>
> Hopefully it is the former. Any insight is appreciated (and patches to
> fix the build even more!)
>
> Cheers,
> Julian
>
Date: Thu, 6 Feb 2014 08:42:38 -0800
> From: Chris Barker
> Subject: Re: [Numpy-discussion] create numerical arrays from strings
> To: Discussion of Numerical Python
> Message-ID:
> <
> calgmxekvnqok6wty-jbjzgaeu5ewhh1_flmsqxjsujfclex...@mail.gmail.com>
> Content-Type: text/plain; charse
Hi everyone,
I put together a np.nanmedian function to extend np.median to handle nans.
Could someone review this code and give me some feedback on it before I
submit a pull request for it?
https://github.com/dfreese/numpy/compare/master...feature;nanmedian
Thanks,
David
ned up
now)
https://github.com/dfreese/numpy/compare/master...feature;nanmedian
On Sun, Feb 16, 2014 at 9:52 AM, alex wrote:
> On Sun, Feb 16, 2014 at 12:13 PM, David Freese
> wrote:
> > Hi everyone,
> >
> > I put together a np.nanmedian function to extend np.median t
x27;real life applications' (TM).
What happens to your benchmark if you tune malloc to not use mmap at all ?
David
>
> I also found this paper which describes pretty much exactly what I'm
> proposing:
> pyhpc.org/workshop/papers/Dou
On Thu, Feb 20, 2014 at 10:37 PM, wrote:
> Date: Fri, 21 Feb 2014 07:43:17 +0100
> From: "V. Armando Sol?"
> *Ref. 8173* *- Deadline for returning application forms: * *01/04/2014*
>
I assume that's the European date format, i.e., the due date is April 1,
2014, not Jan. 4 2014, oui?
DG
Date: Wed, 05 Mar 2014 17:45:47 +0100
> From: Sebastian Berg
> Subject: [Numpy-discussion] Adding weights to cov and corrcoef
> To: numpy-discussion@scipy.org
> Message-ID: <1394037947.21356.20.camel@sebastian-t440>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi all,
>
> in Pull Request https
On Wed, Mar 5, 2014 at 9:11 PM, Nathaniel Smith wrote:
> On Mon, Mar 3, 2014 at 7:20 PM, Julian Taylor
> wrote:
> > hi,
> >
> > as the numpy gsoc topic page is a little short on options I was thinking
> > about adding two topics for interested students. But as I have no
> > experience with gsoc
; charset="UTF-8"
>
> On Mi, 2014-03-05 at 10:21 -0800, David Goldsmith wrote:
> > +1 for it being "too baroque" for NumPy--should go in SciPy (if it
> > isn't already there): IMHO, NumPy should be kept as "lean and mean" as
> > possible, e
On Thu, Mar 6, 2014 at 1:59 PM, Nathaniel Smith wrote:
> On Thu, Mar 6, 2014 at 9:11 AM, David Cournapeau
> wrote:
> >
> > On Wed, Mar 5, 2014 at 9:11 PM, Nathaniel Smith wrote:
> >> So this project would have the following goals, depending on how
> >>
is problem by manually using install_name_tool
> -change on the extension to link the correct library location, but this is
> really cumbersome. Is there an alternative solution, such as an additional
> command-line argument when invoking f2py?
>
This sounds like an issue specific to Anaconda,
in multiple directories, so we would need
to copy the dlls in multiple subdirectories
- copying dlls means that windows will load that dll multiple times, with
all the ensuing problems (I don't know for MKL/OpenBlas, but we've seen
serious issues when doing something similar for hdf5 d
On Wed, Apr 2, 2014 at 12:36 AM, Nathaniel Smith wrote:
> On Tue, Apr 1, 2014 at 11:58 PM, David Cournapeau
> wrote:
> > On Tue, Apr 1, 2014 at 6:43 PM, Nathaniel Smith wrote:
> >>
> >> On Tue, Apr 1, 2014 at 6:26 PM, Matthew Brett
> >&
On Wed, Apr 2, 2014 at 7:52 AM, Matthew Brett wrote:
> Hi,
>
> On Tue, Apr 1, 2014 at 4:46 PM, David Cournapeau
> wrote:
> >
> >
> >
> > On Wed, Apr 2, 2014 at 12:36 AM, Nathaniel Smith wrote:
> >>
> >> On Tue, Apr 1, 2014 at 11:58 PM, David
uted a fix for the VC builds to numpy yet.
>
Mingw generally has their own implementation, and do not use the C runtime
from MS for math functions:
https://github.com/mirror/mingw-w64/tree/master/trunk/mingw-w64-crt/math
David
___
NumPy-Discussi
2014-04-16 20:26 GMT+02:00 onefire :
> Hi all,
>
> I have been playing with the idea of using Numpy's binary format as a
> lightweight alternative to HDF5 (which I believe is the "right" way to do if
> one does not have a problem with the dependency).
>
> I am pretty happy with the npy format, but
function of the C library
> anyway, not the compiler? Numpy has its own implementations for a
> bunch of the math functions, and it's been unclear in the past whether
> numpy or the libc implementations were better in any particular case.
>
In the case of MS runtime, at least 9 (
> I just found the official numpy binary builds of ATLAS:
>
> https://github.com/numpy/vendor/tree/master/binaries
>
> But - they are from an old version of ATLAS / Lapack, and only for 32-bit.
>
> David - what say we update these to latest ATLAS stable?
>
Fine by me (not
On Fri, May 9, 2014 at 1:51 AM, Matthew Brett wrote:
> Hi,
>
> On Mon, Apr 28, 2014 at 3:29 PM, David Cournapeau
> wrote:
> >
> >
> >
> > On Sun, Apr 27, 2014 at 11:50 PM, Matthew Brett >
> > wrote:
> >>
> >> Aha,
> >>
>
On Fri, May 9, 2014 at 11:49 AM, Julian Taylor <
jtaylor.deb...@googlemail.com> wrote:
> On 09.05.2014 12:42, David Cournapeau wrote:
> >
> >
> >
> > On Fri, May 9, 2014 at 1:51 AM, Matthew Brett > <mailto:matthew.br...@gmail.com>> wrote:
> >
&
path:
export PATH=$HOME/bin:$PATH
Build numpy:
python setup.py build
On Thu, Dec 12, 2013 at 1:58 PM, David Jones wrote:
> I'm trying to compile 32-bit numpy on a 64 bit Centos 6 system, but fails
> with the message:
>
> "Broken toolchain: cannot link a simple C program&
Hi Onur,
Have you taken a look at https://github.com/numpy/numpy/issues/1350 ? Maybe
both issues are related.
Cheers,
David H.
On Fri, May 30, 2014 at 6:20 AM, Onur Solmaz wrote:
> Was this mail seen? I cannot be sure because it is the first time I posted.
>
>
>
> On Mon, Ma
FFTW is not used anymore in neither numpy or scipy (has not been for
several years). If you want to use fftw with numpy, there are 3rd party
extensions to do it, like pyfftw
On Mon, Jun 2, 2014 at 12:27 PM, Neal Becker wrote:
> I just d/l numpy-1.8.1 and try to build. I uncomment:
>
> [fftw]
>
but that's much more acceptable than a significant break at the
python level.
David
On Wed, Jun 4, 2014 at 9:58 AM, Sebastian Berg
wrote:
> On Mi, 2014-06-04 at 02:26 +0100, Nathaniel Smith wrote:
> > On Wed, Jun 4, 2014 at 12:33 AM, Charles R Harris
> > wrote:
> > &g
g something in the stdlib means it basically cannot change anymore:
API compatibility requirements would be stronger than what we provide even
now. NumPy is also a large codebase which would need some major clean up to
be accepted, etc...
David
___
NumPy-D
> exception handling, and templates? We will need a certain amount of
> flexibility going forward and we should decide, or at least discuss, such
> issues up front.
>
Last time the C++ discussion was brought up, no consensus could be made. I
think quite a few radical changes can be made without that consensus
already, though other may disagree there.
IMO, what is needed the most is refactoring the internal to extract the
Python C API low level from the rest of the code, as I think that's the
main bottleneck to get more contributors (or get new core features more
quickly).
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Jun 5, 2014 at 2:51 PM, Charles R Harris
wrote:
>
>
>
> On Thu, Jun 5, 2014 at 6:40 AM, David Cournapeau
> wrote:
>
>>
>>
>>
>> On Thu, Jun 5, 2014 at 3:36 AM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>
ile", (d) is a change that's worth the bother (this
> determination to include at least canvassing the list to check that
> users in general agree that it's worth it), then yeah we should do it.
> I don't anticipate that this will happen very often given how far
> we've gotten without it, but yeah.
>
Changing the ABI 'safely' (i.e. raise a python exception if changed) is
already handled in numpy. We can always increase the ABI version if we
think it is worth it
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Jun 5, 2014 at 11:48 PM, Nathaniel Smith wrote:
> On Thu, Jun 5, 2014 at 3:24 PM, David Cournapeau
> wrote:
> > On Thu, Jun 5, 2014 at 2:51 PM, Charles R Harris <
> charlesr.har...@gmail.com>
> > wrote:
> >> On Thu, Jun 5, 2014 at 6:40 AM, David Cou
On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris wrote:
> Ralf likes the speed of bento, but it is not currently maintained
>
What exactly is not maintained ?
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.sci
On Sat, Jul 5, 2014 at 5:23 PM, Ralf Gommers wrote:
>
>
>
> On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau
> wrote:
>
>>
>>
>>
>> On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>&
On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith wrote:
> On Sat, Jul 5, 2014 at 2:32 PM, Ralf Gommers
> wrote:
> >
> > On Sat, Jul 5, 2014 at 1:54 PM, Nathaniel Smith wrote:
> >>
> >> On 5 Jul 2014 09:23, "Ralf Gommers" wrote:
> >> >
On Sat, Jul 5, 2014 at 11:51 PM, Charles R Harris wrote:
>
>
>
> On Sat, Jul 5, 2014 at 8:28 AM, Matthew Brett
> wrote:
>
>> On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau
>> wrote:
>> >
>> >
>> >
>> > On Sat, Jul 5, 2014 at
OS X + clang.
David
On Sun, Jul 6, 2014 at 1:38 AM, Nathaniel Smith wrote:
> On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau
> wrote:
> >
> > On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith wrote:
> >>
> >> Maybe bento will revive and take over the new pyth
On Sun, Jul 6, 2014 at 1:55 AM, Julian Taylor wrote:
> On 05.07.2014 18:40, David Cournapeau wrote:
> > The efforts are on average less demanding than this discussion. We are
> > talking about adding entries to a list in most cases...
> >
> > Also, while adding the opt
On Sun, Jul 6, 2014 at 2:24 AM, Julian Taylor wrote:
> On 05.07.2014 19:11, David Cournapeau wrote:
> > On Sun, Jul 6, 2014 at 1:55 AM, Julian Taylor
> > mailto:jtaylor.deb...@googlemail.com>>
> > wrote:
> >
> > On 05.07.2014 18:40, David Cournap
On Sun, Jul 6, 2014 at 2:24 AM, Julian Taylor wrote:
> On 05.07.2014 19:11, David Cournapeau wrote:
> > On Sun, Jul 6, 2014 at 1:55 AM, Julian Taylor
> > mailto:jtaylor.deb...@googlemail.com>>
> > wrote:
> >
> > On 05.07.2014 18:40, David Cournap
The docstring at the beginning of the module is still relevant AFAIK: it
was about decreasing import times. See
http://mail.scipy.org/pipermail/numpy-discussion/2009-October/045981.html
On Fri, Aug 1, 2014 at 10:27 AM, Charles R Harris wrote:
> Hi All,
>
> The _inspect.py function looks like a
they are
>> used if you feel compelled to. Please do not replace the current uses
>> of `_inspect` with `inspect`.
>>
>
> It is used in just one place. Is importing inspect so much slower than all
> the other imports we do?
>
Yes, please look at the thread I referred to. The custom inspect cut
imports by 30 %, I doubt the ratio is much different today.
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
e was bundled for).
David
On Sat, Aug 2, 2014 at 5:11 AM, David Cournapeau wrote:
>
>
>
> On Fri, Aug 1, 2014 at 11:23 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>>
>> On Fri, Aug 1, 2014 at 7:59 AM, Robert Kern
>> wro
On Sat, Aug 2, 2014 at 11:17 AM, Charles R Harris wrote:
>
>
>
> On Fri, Aug 1, 2014 at 8:01 PM, David Cournapeau
> wrote:
>
>> On my machine, if I use inspect instead of _inspect in
>> numpy.compat.__init__, the import time increases ~ 25 % (from 82 ms to 99
>&
On Sat, Aug 2, 2014 at 11:36 AM, Charles R Harris wrote:
>
>
>
> On Fri, Aug 1, 2014 at 8:22 PM, David Cournapeau
> wrote:
>
>>
>>
>>
>> On Sat, Aug 2, 2014 at 11:17 AM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>
sage is not bogus, I would try import von_mises with a venv
containing numpy 1.5.1, then 1.6.0, etc... to detect when the change
happened.
David
> Cheers,
>
> Matthew
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
>
you can go, and
come back to this group with the result of your investigation.
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ew dtype: numpy hardcodes that long double is the highest
precision floating point type, for example, and there were similar issues
regarding datetime handling. Does not matter for completely new types that
don't require interactions with others (categorical ?).
Would it help to prepare a set of
Not exactly: if you build numpy with mingw (as is the official binary), you
need to build everything that uses numpy C API with it.
On Sun, Oct 26, 2014 at 1:22 AM, Matthew Brett
wrote:
> On Sat, Oct 25, 2014 at 2:15 PM, Matthew Brett
> wrote:
> > On Fri, Oct 24, 2014 at 6:04 PM, Matthew Brett
MKL, Accelerate, etc... all use a standard API
(BLAS/LAPACK), but for FFT, you need to reimplement pretty much the whole
thing. Unsurprisingly, this meant the code was not well maintained.
Wrapping non standard, non-BSD libraries makes much more sense in separate
libraries in general.
David
>
thing missing from fftpack is the handling of transform sizes that
> are not products of 2,3,4,5.
>
Strickly speaking, it is handled, just not through an FFT (it goes back to
the brute force O(N**2)).
I made some experiments with the Bluestein tr
t the Bluestein
transform to deal with prime/near-prime numbers on top of FFTS.
I did not look much, but it did not obviously support building on windows
as well ?
David
> -n
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy
On Tue, Oct 28, 2014 at 3:06 PM, David Cournapeau
wrote:
> I
>
> On Tue, Oct 28, 2014 at 2:31 PM, Nathaniel Smith wrote:
>
>> On 28 Oct 2014 07:32, "Jerome Kieffer" wrote:
>> >
>> > On Tue, 28 Oct 2014 04:28:37 +
>> > Nathaniel Smi
gt; interface, rather than having us debate which fft library is 'best'.
>
I would agree if it were not already there, but removing it (like
Blas/Lapack) is out of the question for backward compatibility reason. Too
much code depends on it.
David
>
> On Tue, Oct 28, 2014 at
Hi,
I have not followed closely the changes that happen in 1.9.1, but was
surprised by the following:
x = np.zeros(12, "d")
assert x.flags.aligned # fails
This is running numpy 1.9.1 built on windows with VS 2008. Is it expected
that zeros may return a non-aligned arra
).
(the context is > 100 test failures on scipy 0.14.x on top of numpy 1.9.,
because f2py intent(inout) fails on work arrays created by zeros, this is a
windows-32 only failure).
David
On Tue, Nov 18, 2014 at 6:26 PM, Julian Taylor <
jtaylor.deb...@googlemail.com> wrote:
> On 18.11.2014
Additional point: it seems to always return aligned data on 1.8.1 (same
platform/compiler/everything).
On Tue, Nov 18, 2014 at 6:35 PM, David Cournapeau
wrote:
> It is on windows 32 bits, but I would need to make this work for complex
> (pair of double) as well.
>
> Is this a bug
y 1.8.1 always returned 16 bytes aligned arrays in this
case (unlikely to be a coincidence, as I try quite a few times with
different sizes).
>
> is the array aligned?
>
> On 18.11.2014 19:37, David Cournapeau wrote:
> > Additional point: it seems to always return aligned data on
on't see the issues with f2py
not being able to
I am starting to think I got on the wrong track regarding the original
issue I see with scipy 0.14.x on win 32 bits... I will create a separate
ticket for that.
David
___
NumPy-Discussion
Shall we consider https://github.com/scipy/scipy/issues/4168 to be a
blocker (the issue arises on scipy master as well as 0.14.1) ?
On Sun, Nov 23, 2014 at 11:13 PM, Pauli Virtanen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dear all,
>
> We have finally finished preparing the S
On Tue, Nov 25, 2014 at 6:10 PM, Sturla Molden
wrote:
> David Cournapeau wrote:
> > Shall we consider > href="https://github.com/scipy/scipy/issues/4168";>
> https://github.com/scipy/scipy/issues/4168
> > to be a
> > blocker (the issue arises on scipy m
Hi,
Would anybody mind if I create a label "newcomers" on GH, and start
labelling simple issues ?
This is in anticipation to the bloomberg lab event in London this WE. I
will try to give a hand to people interested in numpy/scipy,
David
___
oups, I missed it. Will use that one then.
On Wed, Nov 26, 2014 at 9:01 AM, Julian Taylor <
jtaylor.deb...@googlemail.com> wrote:
> On 11/26/2014 09:44 AM, David Cournapeau wrote:
> > Hi,
> >
> > Would anybody mind if I create a label "newcomers" on GH,
Hi there,
I remember having seen some numpy-aware gdb macros at some point, but
cannot find any reference. Does anyone know of any ?
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy
On Sun, Nov 30, 2014 at 5:45 PM, Charles R Harris wrote:
>
>
> On Sun, Nov 30, 2014 at 4:54 AM, David Cournapeau
> wrote:
>
>> Hi there,
>>
>> I remember having seen some numpy-aware gdb macros at some point, but
>> cannot find any reference. Does anyon
/ similar results.
Thanks for all the hard work,
David
On Sun, Dec 14, 2014 at 10:29 PM, Pauli Virtanen wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dear all,
>
> We have finished preparing the Scipy 0.14.1 release candidate 1.
> If no regressions turn
701 - 800 of 3277 matches
Mail list logo
