On Thu, Jul 2, 2009 at 5:25 AM, Charles R
Harrischarlesr.har...@gmail.com wrote:
On Wed, Jul 1, 2009 at 1:57 PM, Pauli Virtanen p...@iki.fi wrote:
On 2009-07-01, Charles R Harris charlesr.har...@gmail.com wrote:
On Wed, Jul 1, 2009 at 1:59 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp
On Thu, Jul 2, 2009 at 5:34 AM, Pauli Virtanenp...@iki.fi wrote:
Don't know, probably we can?
yes, they are functions (the builtins are __real__ and __imag__)
I think that for scipy.special this would be useful. Of course,
the operator semantics for complex numbers can't be used there,
but
On Mon, Jun 29, 2009 at 4:09 PM, Hanni Alihanni@gmail.com wrote:
Hi David,
Sounds very interesting, have you noticed any improvement in performance ove
using the builtin numpy blas lite?
For now, I focus on building and passing the test suite. That's
already a lot of work since MS
On Tue, Jun 30, 2009 at 2:15 AM, Robert Kernrobert.k...@gmail.com wrote:
On Mon, Jun 29, 2009 at 00:34, David
Cournapeauda...@ar.media.kyoto-u.ac.jp wrote:
Hi,
I started working on a new approach for windows 64 bits support, to
be able to combine gfortran and visual studio. Basically, I
On Tue, Jun 30, 2009 at 3:06 AM, Bruce Southeybsout...@gmail.com wrote:
I would think that you could just provide an appropriately licensed package
that combines a separately downloaded numpy/scipy with the separately
downloaded/installed gfortran to install the new version of numpy/scipy.
On Sun, Jun 28, 2009 at 4:38 AM, Charles R
Harrischarlesr.har...@gmail.com wrote:
On Sat, Jun 27, 2009 at 1:12 PM, Pauli Virtanen p...@iki.fi wrote:
On 2009-06-27, Charles R Harris charlesr.har...@gmail.com wrote:
[clip]
PyOS_snprintf(format, sizeof(format), _FMT1, prec);
res =
Hi,
I started working on a new approach for windows 64 bits support, to
be able to combine gfortran and visual studio. Basically, I am
reimplementing the needed functions from libgfortran so that it can be
built with MS compiler, but I cannot hope to do that without using
gfortran sources
On Sun, Jun 28, 2009 at 2:05 AM, Dinesh B
Vadhiadineshbvad...@hotmail.com wrote:
Okay. Maybe a bit harsh, but wouldn't it be better not to have the release
as available if it cannot be imported?
It cannot be imported in some situations, but it works fine in others.
David
On Sun, Jun 28, 2009 at 11:31 AM, Dinesh B
Vadhiadineshbvad...@hotmail.com wrote:
The machine in question is factory installed with:
OS: Windows Vista 64-bit SP2
Processor: Intel Core2 Quad CPU, Q6600 @ 2.4Ghz @2.4GHz
Memory: 8Gb
Apart from Python 2.5.4 nothing has been installed on this
On Sat, Jun 27, 2009 at 6:42 AM, Dinesh B
Vadhiadineshbvad...@hotmail.com wrote:
Ticket# 1084
(http://projects.scipy.org/numpy/timeline?from=2009-06-09T03%3A01%3A59-0500precision=second)
says that the numpy import on Windows Vista x64 AMD systems works now.
I mistakenly closed it as fixed, but
Sandeep Devadas wrote:
Hi David,
I tried what you told me and Im getting this error.Please
let me know what to do next.
What about installing nose :)
http://somethingaboutorange.com/mrl/projects/nose/0.11.1/
You need setuptools installed. Note that those are only necessary for
Kurt Smith wrote:
On Wed, Jun 24, 2009 at 9:05 AM, David
Cournapeauda...@ar.media.kyoto-u.ac.jp wrote:
Kurt Smith wrote:
On Tue, Jun 23, 2009 at 10:17 PM, David Cournapeaucourn...@gmail.com
wrote:
If possible, you should not build executables, it is not portable.
Sandeep Devadas wrote:
Hi David,
On Mon, Jun 22, 2009 at 7:03 PM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp mailto:da...@ar.media.kyoto-u.ac.jp
wrote:
Hi Sandeep,
Sandeep Devadas wrote:
Hello There,
My name is Sandeep Devadas and im trying
On Wed, Jun 24, 2009 at 3:41 AM, Lisandro Dalcindalc...@gmail.com wrote:
On Mon, Jun 22, 2009 at 11:53 PM, Kurt Smithkwmsm...@gmail.com wrote:
Hello,
Is there a way for numpy.distutils to compile a fortran source file
into an executable?
If the whole point of building the executable is to
Sandeep Devadas wrote:
Hi,
I got numpy working on Python under cygwin and am getting this
error .
Please let me know what to do as I am new to Python and dont know
anything.
$ python
Python 2.5.2 (r252:60911, Dec 2 2008, 09:26:14)
[GCC 3.4.4 (cygming special, gdc 0.12, using
On Mon, Jun 22, 2009 at 3:18 PM, Pierre GMpgmdevl...@gmail.com wrote:
On Jun 21, 2009, at 5:01 AM, David Cournapeau wrote:
(Continuing the discussion initiated in the neighborhood iterator
thread)
Hi,
I would like to gather people's opinion on what to target for numpy
1.4.0
On Mon, Jun 22, 2009 at 10:15 AM, Bruce Southeybsout...@gmail.com wrote:
On Sun, Jun 21, 2009 at 4:01 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
(Continuing the discussion initiated in the neighborhood iterator thread)
Hi,
I would like to gather people's opinion on what
Hi Sandeep,
Sandeep Devadas wrote:
Hello There,
My name is Sandeep Devadas and im trying to install
numpy for python on Cygwins latest version(1.5.xx) on Windows XP.I'm
getting an error message when I follow the instructions given at
Neil Crighton wrote:
David Cournapeau cournape at gmail.com writes:
David Cournapeau wrote:
(Continuing the discussion initiated in the neighborhood iterator
thread)
- Chuck suggested to drop python 2.6 support from now on. I am
against it without a very strong
(Continuing the discussion initiated in the neighborhood iterator thread)
Hi,
I would like to gather people's opinion on what to target for numpy
1.4.0.
- Chuck suggested to drop python 2.6 support from now on. I am
against it without a very strong and detailed rationale, because many
On Sun, Jun 21, 2009 at 11:55 PM, Darren Daledsdal...@gmail.com wrote:
On Sun, Jun 21, 2009 at 10:38 AM, John Reid j.r...@mail.cryst.bbk.ac.uk
wrote:
David Cournapeau wrote:
(Continuing the discussion initiated in the neighborhood iterator
thread)
- Chuck suggested to drop python
On Mon, Jun 22, 2009 at 12:42 AM, Charles R
Harrischarlesr.har...@gmail.com wrote:
On Sun, Jun 21, 2009 at 8:55 AM, Darren Daledsdal...@gmail.com wrote:
On Sun, Jun 21, 2009 at 10:38 AM, John Reid j.r...@mail.cryst.bbk.ac.uk
wrote:
David Cournapeau wrote:
(Continuing the discussion
On Mon, Jun 22, 2009 at 12:59 AM, David Cournapeaucourn...@gmail.com wrote:
Another suggestion is to avoid breaking the API when transitioning for
python 3. But that seems quite unrealistic. How do we deal with the
removing of string/long APIs ?
^ This should
On Mon, Jun 22, 2009 at 7:04 AM, Travis Oliphantoliph...@enthought.com wrote:
I don't remember dropping support for 2.4. When did that happen?
It does work on 2.4, I regularly test numpy and scipy on RHEL 5 with
64 bits python 2.4. We dropped 2.3 support since 1.2 IIRC.
David
On Mon, Jun 22, 2009 at 2:17 AM, Robertkxrobe...@googlemail.com wrote:
I'd like even support for Python 2.3. Many basic libraries still
support 2.3
and many don't :) In my experience, the limit is often python 2.4
(which we still support).
And numpy is a very basic library. And what is in
On Thu, Jun 18, 2009 at 2:05 PM, Charles R
Harrischarlesr.har...@gmail.com wrote:
I don't know. I think it is cleaner to depend on 1.4.0
Oh, definitely - I certainly prefer this solution as well.
but there
might be other considerations such as release schedules, both for
numpy/scipy and
Stéfan van der Walt wrote:
Hi,
I am running NumPy from SVN with nose 0.10.4 on Karmic and everything
seems ok. Could be that one of the packages in Karmic itself is
broken?
Or maybe something with nose 0.11 (I don't see any change related to new
nose in numpy/testing since 1.3.0,
On Sun, Jun 21, 2009 at 3:08 AM, Charles R
Harrischarlesr.har...@gmail.com wrote:
Since we are extending the API and bumping up the API number, I wonder
if we should change the python dependency to 2.6?
I think we should keep compatibility with python 2.4, it is still used
by many people, and
On Mon, Jun 15, 2009 at 1:45 AM, Charles R
Harrischarlesr.har...@gmail.com wrote:
1) The documentation of PyObject_Init doesn't say whether it is NULL
safe, so I think there needs to be a check here before the call:
I checked the code of PyObject_init: I think it is safe to call it
with NULL,
On Sun, Jun 14, 2009 at 3:51 AM, Charles R
Harrischarlesr.har...@gmail.com wrote:
On Sat, Jun 13, 2009 at 12:35 PM, David Cournapeau courn...@gmail.com
wrote:
On Sun, Jun 14, 2009 at 3:22 AM, Charles R
Harrischarlesr.har...@gmail.com wrote:
1) Since reference counting is such a pain, you
On Sun, Jun 14, 2009 at 4:59 PM, David Cournapeaucourn...@gmail.com wrote:
On Sun, Jun 14, 2009 at 3:51 AM, Charles R
Harrischarlesr.har...@gmail.com wrote:
On Sat, Jun 13, 2009 at 12:35 PM, David Cournapeau courn...@gmail.com
wrote:
On Sun, Jun 14, 2009 at 3:22 AM, Charles R
On Sun, Jun 14, 2009 at 3:22 AM, Charles R
Harrischarlesr.har...@gmail.com wrote:
1) Since reference counting is such a pain, you should document that the
constructor returns a new reference and that the PyArrayIterObject does not
need to have its reference count incremented before the call
Hi,
I have finally spent some time so that we can install pure C
libraries using numpy.distutils. With this, one could imagine having a C
library for fft, special functions in numpy or scipy, so that the
library could be reused in another package at the C level. If someone
knowledgeable about
Gael Varoquaux wrote:
On Fri, Jun 12, 2009 at 07:46:04PM +0900, David Cournapeau wrote:
I have finally spent some time so that we can install pure C
libraries using numpy.distutils. With this, one could imagine having a C
library for fft, special functions in numpy or scipy, so
Hi,
I have uploaded the binaries and source tarballs for 0.7.1rc3. The
rc3 fixes some issues in scipy.special, which caused wrong
behavior/crashes on some platforms. Hopefully, this will be the 0.7.1
release,
cheers,
David
=
SciPy 0.7.1 Release Notes
On Fri, Jun 12, 2009 at 12:56 AM, Samir Unnisru...@gmail.com wrote:
On Wed, Jun 10, 2009 at 8:32 PM, David Cournapeaucourn...@gmail.com wrote:
On Thu, Jun 11, 2009 at 5:04 AM, Samir Unnisru...@gmail.com wrote:
On Wed, Jun 10, 2009 at 2:59 PM, Adam Mercerramer...@gmail.com wrote:
On Wed, Jun
On Thu, Jun 11, 2009 at 12:30 AM, Carl, Andrew F (AS)a.c...@ngc.com wrote:
Then how about known combinations of version numbers for g77/gcc,
python, and numpy?
Any of them should work. Numpy on windows is built with g77/gcc as
available from the official MinGW installer.
. Something on where
On Thu, Jun 11, 2009 at 1:22 AM, Andrew Hawrylukhawr...@novachem.com wrote:
I was able to get gfortran working on Windows just a few weeks ago. The
only problem I had was that I needed Python = 2.5.3 before it would
work. See issue #2234 in
On Thu, Jun 11, 2009 at 5:04 AM, Samir Unnisru...@gmail.com wrote:
On Wed, Jun 10, 2009 at 2:59 PM, Adam Mercerramer...@gmail.com wrote:
On Wed, Jun 10, 2009 at 12:44, Samir Unnisru...@gmail.com wrote:
I'm trying to use F2PY on Mac OS 10.5 with G95, but I'm getting the
error g95: unrecognized
Robin wrote:
On Mon, Jun 8, 2009 at 7:14 PM, David Warde-Farleyd...@cs.toronto.edu wrote:
On 8-Jun-09, at 8:33 AM, Jason Rennie wrote:
Note that EM can be very slow to converge:
That's absolutely true, but EM for PCA can be a life saver in cases where
diagonalizing (or even computing)
David Cournapeau wrote:
I think the biggest problem is the 'babel tower' aspect of machine
learning (the expression is from David H. Wolpert I believe), and
practitioners in different subfields often use totally different words
for more or less the same concepts (and many keep being
Charles R Harris wrote:
On Tue, Jun 9, 2009 at 2:32 AM, John Schulman jos...@caltech.edu
mailto:jos...@caltech.edu wrote:
I'm getting the error
OverflowError: cannot fit 'long' into an index-sized integer
when I try to memmap a 6gb file
top of the stack trace is
mm =
John Schulman wrote:
What's the best way to install a 64-bit python alongside my existing
installation?
It is a bit complicated because you need to build your own python
interpreter (the python.org one does not handle 64 bits AFAIK). You
could just install your python somewhere in your
Hi Benoit,
Benoit Jacob wrote:
No, because _we_ are serious about compilation times, unlike other c++
template libraries. But granted, compilation times are not as short as
a plain C library either.
I concede it is not as bad as the heavily templated libraries in boost.
But C++ is just
Carl, Andrew F (AS) wrote:
Would it be a reasonable request, that the F2PY Windows web page
contain known combinations of version numbers for Python, Numpy and
Gfortran verified to play nice? Some references as to queried compiler
system environmental variables would be useful also.
I have
David Warde-Farley wrote:
On 9-Jun-09, at 3:54 AM, David Cournapeau wrote:
For example, what ML people call PCA is called Karhunen Loéve in
signal
processing, and the concepts are quite similar.
Yup. This seems to be a nice set of review notes:
http
Matthieu Brucher wrote:
I'm trying to compile it with ICC 10.1.018, and it fails :|
icc: scipy/special/cephes/const.c
scipy/special/cephes/const.c(94): error: floating-point operation
result is out of range
double INFINITY = 1.0/0.0; /* 99e999; */
^
On Mon, Jun 8, 2009 at 8:45 PM, Matthieu
Bruchermatthieu.bruc...@gmail.com wrote:
2009/6/8 David Cournapeau da...@ar.media.kyoto-u.ac.jp:
Matthieu Brucher wrote:
I'm trying to compile it with ICC 10.1.018, and it fails :|
icc: scipy/special/cephes/const.c
scipy/special/cephes/const.c(94
Jason Rennie wrote:
Note that EM can be very slow to converge:
http://www.cs.toronto.edu/~roweis/papers/emecgicml03.pdf
http://www.cs.toronto.edu/%7Eroweis/papers/emecgicml03.pdf
EM is great for churning-out papers, not so great for getting real
work done.
I think it depends on what you
Matthieu Brucher wrote:
David,
I've checked out the trunk, and the segmentation fault isn't there
anymore (the trunk is labeled 0.8.0 though)
Yes, the upcoming 0.7.1 release has its code in the 0.7.x svn branch.
But the fix for #946 is a backport of 0.8.0, so in theory, it should be
fixed
Jason Rennie wrote:
I hung-out in the machine learning community appx. 1999-2007 and
thought the Salakhutdinov work was extremely refreshing to see after
listening to no end of papers applying EM to whatever was the hot
topic at the time. :)
Isn't it true for any general framework who enjoys
Matthieu Brucher wrote:
Concerning the other errors: did you compile with intel compilers or GNU
ones ?
Only Intel compilers. Maybe I should check the rc branch instead of the trunk?
I just wanted to confirm - I am actually rather surprised there are not
more errors :)
cheers,
George Nurser wrote:
running config_fc
unifing config_fc, config, build_clib, build_ext, build commands
--fcompiler options
running build_clib
customize UnixCCompiler
customize UnixCCompiler using build_clib
building 'npymath' library
compiling C sources
C compiler: gcc -arch ppc -arch
Gabriel Beckers wrote:
OK, perhaps I drank that beer too soon...
Now, numpy.test() hangs at:
test_pinv (test_defmatrix.TestProperties) ...
So perhaps something is wrong with ATLAS, even though the building went
fine, and make check and make ptcheck reported no errors.
Maybe you did
Gael Varoquaux wrote:
On Sun, Jun 07, 2009 at 06:37:21PM +0900, David Cournapeau wrote:
That's why compiling atlas by yourself is hard, and I generally advise
against it: there is nothing intrinsically hard about it, but you need
to know a lot of small details and platform oddities to get
(Please do not send twice your message to numpy/scipy ML, thank you)
wierob wrote:
Hi,
int64 and float seem to work for the stderr calculation. Now, the
calculation of the p-value causes an underflow.
File C:\Python26\lib\site-packages\scipy\stats\distributions.py, line
2829,in _cdf
George Nurser wrote:
Sorry, I should have said that I'd always deleted the build directories.
I now have a better idea about what the problem is.
python setup.py config_fc --fcompiler=gnu95 build_clib
--fcompiler=gnu95 build_ext --fcompiler=gnu95 install
works OK for svn versions 6481
Gabriel Beckers wrote:
On Sun, 2009-06-07 at 18:37 +0900, David Cournapeau wrote:
That's why compiling atlas by yourself is hard, and I generally advise
against it: there is nothing intrinsically hard about it, but you need
to know a lot of small details and platform oddities to get
Gael Varoquaux wrote:
I am using the heuristic exposed in
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4562996
We have very noisy and long time series. My experience is that most
model-based heuristics for choosing the number of PCs retained give us
way too much on this problem
Sebastian Walter wrote:
On Thu, Jun 4, 2009 at 10:56 PM, Chris Colbertsccolb...@gmail.com wrote:
I should update after reading the thread Sebastian linked:
The current 1.3 version of numpy (don't know about previous versions) uses
the optimized Atlas BLAS routines for numpy.dot() if numpy
Sebastian Walter wrote:
On Fri, Jun 5, 2009 at 11:58 AM, David
Cournapeauda...@ar.media.kyoto-u.ac.jp wrote:
Sebastian Walter wrote:
On Thu, Jun 4, 2009 at 10:56 PM, Chris Colbertsccolb...@gmail.com wrote:
I should update after reading the thread Sebastian linked:
The
Hi,
The RC2 for 0.7.1 scipy release has just been tagged. This is a
bug-fixes only release, see below for the release notes. More
information can
also be found on the trac website:
http://projects.scipy.org/scipy/milestone/0.7.1
The only code change compared to the RC1 is one fix which is
Eric Firing wrote:
David,
The eigen web site indicates that eigen achieves high performance
without all the compilation difficulty of atlas. Does eigen have enough
functionality to replace atlas in numpy?
No, eigen does not provide a (complete) BLAS/LAPACK interface. I don't
know if
On Tue, Jun 2, 2009 at 10:56 PM, Ryan May rma...@gmail.com wrote:
On Tue, Jun 2, 2009 at 5:59 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
Robin wrote:
On Tue, Jun 2, 2009 at 11:36 AM, David Cournapeau courn...@gmail.com
wrote:
Done in r7031 - correlate/PyArray_Correlate
Hi,
The RC1 for 0.7.1 scipy release has just been tagged. This is a
bug-only release, see below for the release notes. More information can
also be found on the trac website:
http://projects.scipy.org/scipy/milestone/0.7.1
Please test it !
The scipy developers
--
=
Matthew Brett wrote:
Hi,
The RC1 for 0.7.1 scipy release has just been tagged. This is a
bug-only release
I feel (y)our pain, but don't you mean 'bug-fix only release'? ;-)
Actually, there is one big bug on python 2.6 for mac os x, so maybe the
bug-only is appropriate :)
Neal Becker wrote:
Has this been considered as a candidate for our fft?
http://sourceforge.net/projects/kissfft
I looked at it when I was looking for a BSD-compatible FFT with support
for prime factors (which fftpack does not handle). As Robert mentioned,
I did not see any compelling
David Warde-Farley wrote:
On 4-Jun-09, at 5:03 PM, Anne Archibald wrote:
Apart from the implementation issues people have chimed in about
already, it's worth noting that the speed of matrix multiplication
depends on the memory layout of the matrices. So generating B instead
directly as a
Charles R Harris wrote:
On Mon, Jun 1, 2009 at 11:08 PM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp mailto:da...@ar.media.kyoto-u.ac.jp
wrote:
Hi,
I have a question related to #1121
(http://projects.scipy.org/numpy/ticket/1121). With python 2.6,
PyInt_Check
On Tue, Jun 2, 2009 at 12:37 PM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
Robert Kern wrote:
This does not solve the C function problem (PyArray_Correlate). The easy
solution would be to keep the current C version, deal with the problem
in python for acorrelate for the time being
Robin wrote:
On Tue, Jun 2, 2009 at 11:36 AM, David Cournapeau courn...@gmail.com wrote:
Done in r7031 - correlate/PyArray_Correlate should be unchanged, and
acorrelate/PyArray_Acorrelate implement the conventional definitions,
I don't know if it's been discussed before but while
Charles R Harris wrote:
I also think that having weighting options would be good. I now
understand the complexities of the various
weightings that can be applied to the correlation i.e. biased vs
unbiased but I think that having correlate
include these options might
, David Cournapeau
da...@ar.media.kyoto-u.ac.jp
mailto:da...@ar.media.kyoto-u.ac.jp wrote:
I think we should just fix it to use conjugate - I will do
this in the
branch, and I will integrate it in the trunk later unless
someone stands
Hi,
I have a question related to #1121
(http://projects.scipy.org/numpy/ticket/1121). With python 2.6,
PyInt_Check(a) if a is an instance of numpy.int32 does not work anymore.
It think this is related to the python issue 2263
(http://bugs.python.org/issue2263), where the tp_flags has been
Charles R Harris wrote:
On Sun, May 31, 2009 at 11:54 AM, rob steed rjst...@talk21.com
mailto:rjst...@talk21.com wrote:
Hi,
After my previous email, I have opened a ticket #1117 (correlate
not order dependent)
I have found that the correlate function is defined in
Charles R Harris wrote:
On Sun, May 31, 2009 at 7:18 PM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp mailto:da...@ar.media.kyoto-u.ac.jp
wrote:
Charles R Harris wrote:
On Sun, May 31, 2009 at 11:54 AM, rob steed rjst...@talk21.com
mailto:rjst...@talk21.com
Charles R Harris wrote:
On Sun, May 31, 2009 at 9:08 PM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp mailto:da...@ar.media.kyoto-u.ac.jp
wrote:
Charles R Harris wrote:
On Sun, May 31, 2009 at 7:18 PM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp
mailto:da
Francesc Alted wrote:
A Tuesday 26 May 2009 15:14:39 Andrew Friedley escrigué:
David Cournapeau wrote:
Francesc Alted wrote:
Well, it is Andrew who should demonstrate that his measurement is
correct, but in principle, 4 cycles/item *should* be feasible when using
8 cores
cp wrote:
The image I tested initially is 2000x2000 RGB tif ~11mb in size.
I continued testing, with the initial PIL approach
and 3 alternative numpy scripts:
#Script 1 - indexing
for i in range(10):
imarr[:,:,0].mean()
imarr[:,:,1].mean()
imarr[:,:,2].mean()
#Script
Andrew Friedley wrote:
David Cournapeau wrote:
Francesc Alted wrote:
No, that seems good enough. But maybe you can present results in
cycles/item.
This is a relatively common unit and has the advantage that it does not
depend
on the frequency of your cores.
Sure
Brennan Williams wrote:
Not a question really but just for discussion/pie-in-the-sky etc
This is a news item on vizworld about getting Matlab code to run on a
CUDA enabled GPU.
http://www.vizworld.com/2009/05/cuda-enable-matlab-with-gpumat/
There is this which looks similar for
Francesc Alted wrote:
Well, it is Andrew who should demonstrate that his measurement is correct,
but
in principle, 4 cycles/item *should* be feasible when using 8 cores in
parallel.
But the 100x speed increase is for one core only unless I misread the
table. And I should have mentioned
Charles R Harris wrote:
On Mon, May 25, 2009 at 4:59 AM, Andrew Friedley afrie...@indiana.edu
mailto:afrie...@indiana.edu wrote:
For some reason the list seems to occasionally drop my messages...
Francesc Alted wrote:
A Friday 22 May 2009 13:52:46 Andrew Friedley escrigué:
David Warde-Farley wrote:
Can someone with the requisite permissions change the title of ticket
#1113 to reflect the fact that it affects both ppc and ppc64?
Done.
Alternately, if you know why the bug is happening, you could file a
patch ;)
I have not looked at the code, but if
dmitrey wrote:
hi all,
I have tried the example from numpy/add_newdocs.py
np.ldexp(5., 2)
but instead of the 20 declared there it yields
TypeError: function not supported for these types, and can't coerce
safely to supported types
Which OS/Compiler are you using ?
David
dmitrey wrote:
I have updated numpy to latest '1.4.0.dev7008', but the bug still
remains.
I use KUBUNTU 9.04, compilers - gcc (using build-essential), gfortran.
D.
Can you post the build output (after having removed the build directory
: rm -rf build python setup.py build build.log) ?
Stéfan van der Walt wrote:
Hi John
2009/5/20 josef.p...@gmail.com:
On Wed, May 20, 2009 at 3:07 PM, John Hunter jdh2...@gmail.com wrote:
We are trying to build and test mpl installers for python2.4, 2.5 and
2.6. What we are finding is that if we build mpl against a more
recent
Klaus Noekel wrote:
I doubt that the DLL was not physically present and rather suspect a
dependency on some other DLL that was missing. The INSTALL.TXT
unfortunately was not helpful. Can anybody please explain what other
dependencies exist? Anything else I need to install?
This exact
Eric Firing wrote:
That would incur the overhead of an extra function call for each
element; I suspect it would slow it down a lot. My motivation is to make
masked array overhead negligible, at least for medium to large arrays.
You can use inline in that case - starting with numpy 1.3.0,
Robert Cimrman wrote:
Hi (David)!
I am evaluating numpy.distutils as a build/install system for my project
- is it possible to build the extension modules in-place so that the
project can be used without installing it? A pointer to documentation
concerning this would be handy...
On Wed, May 13, 2009 at 6:14 AM, James Jackson james.jack...@cern.ch wrote:
I note that the distribution directory being created is build/
src.linux-x86_64-2.4 - not i386. Can I force the architecture in the
configure step, as it appears this would be the problem (hinted at by
LONG_BIG wrong
2009/5/10 Stéfan van der Walt ste...@sun.ac.za:
I think the message ABI version %%x of C-API is unclear, maybe
simply use ABI version %%x on its own.
The hash file can be loaded in one line with
np.loadtxt('/tmp/dat.dat', usecols=(0, 2), dtype=[('api', 'S10'),
('hash', 'S32')])
The rest
Charles R Harris wrote:
On Mon, May 11, 2009 at 4:49 PM, Peter Wang pw...@enthought.com
mailto:pw...@enthought.com wrote:
Hey guys,
I've got a small C extension that uses isnan() and (in numpy 1.1) had
been importing it from ufuncobject.h. I see that it has now moved
Hi Robert,
Robert wrote:
for use in binary distribution where I need only basics and fast
startup/low memory footprint, I try to isolate the minimal ndarray
type and what I need..
with import numpy or import numpy.core.multiarray almost the
whole numpy package tree is imported, _dotblas
Charles R Harris wrote:
As you may have noticed, I really, really, don't like adding functions
to the API ;)
Me neither :)
Especially unneeded ones or ones that could be done at the python
level. So I think the thing to do here is split the version into two
16 bit parts, then start with
Stéfan van der Walt wrote:
2009/5/10 David Cournapeau courn...@gmail.com:
I worked on some code to detect C API mismatches both for developers
and for users:
http://github.com/cournape/numpy/tree/runtime_feature
Great, thanks for taking care of this!
I think the message ABI
Muhammad Alkarouri wrote:
Date: Tue, 5 May 2009 09:24:53 -0600
From: Charles R Harris charlesr.har...@gmail.com
...
This is almost always an ATLAS problem. Where did your
ATLAS come from and
what distro are you running?
You are probably right. I compiled and installed ATLAS
Muhammad Alkarouri wrote:
--- On Wed, 6/5/09, David Cournapeau da...@ar.media.kyoto-u.ac.jp wrote:
...
What does ldd lapack_lite.so returns (lapack_lite.so is in
numpy/linalg,
in your installed directory) ? It may be that numpy uses
gfortran,
whereas ATLAS is built with g77. gfortran
On Wed, May 6, 2009 at 10:44 PM, Talbot, Gerry gerry.tal...@amd.com wrote:
Does anyone know how to efficiently implement a recurrence relationship in
numpy such as:
y[n] = A*x[n] + B*y[n-1]
That's the direct implement of a linear filter with an infinite
impulse response. That's
Hi,
I spent some more time on making numpy.distutils runnable under python
3. I finally made up to the point where it breaks at C code
compilation, so we can start working on the hard part. The branch is
there for review
http://github.com/cournape/numpy/commits/py3k_bootstrap
The code is quite
901 - 1000 of 2096 matches
Mail list logo
