On Jul 18, 2006, at 9:16 PM, Robert Kern wrote:
> Josh Marshall wrote:
>> so it seems like the entire purpose of PackageLoader is to make life
>> difficult for me, just to save a few lines of typing. :) Seriously,
>> can a numpy developer tell me why PackageLoader is necessary?
>
> I can't think
Travis Oliphant wrote:
> Robert Kern wrote:
>> Josh Marshall wrote:
>>
>>> so it seems like the entire purpose of PackageLoader is to make life
>>> difficult for me, just to save a few lines of typing. :) Seriously,
>>> can a numpy developer tell me why PackageLoader is necessary?
>>>
>
Robert Kern wrote:
> Josh Marshall wrote:
>
>> so it seems like the entire purpose of PackageLoader is to make life
>> difficult for me, just to save a few lines of typing. :) Seriously,
>> can a numpy developer tell me why PackageLoader is necessary?
>>
>
> I can't think of a good reas
Josh Marshall wrote:
> so it seems like the entire purpose of PackageLoader is to make life
> difficult for me, just to save a few lines of typing. :) Seriously,
> can a numpy developer tell me why PackageLoader is necessary?
I can't think of a good reason why it's used in __init__.py the way
Hi,
Having to use Fortran again, I had a look at f2py ..
I looks really great !! Everything seems to run out of the box !!
Thanks a lot !
I think I tried
intend(inout)and then fed in an array object that really
was an numarray as opposed to a numpy array.
I was surprised that the array did
On Jul 18, 2006, at 7:26 PM, Josh Marshall wrote:
> Thanks for the fix Bob.
>
> Unfortunately Matplotlib does not work with zipped data files,
> after all that. So, we'll leave the recipes as is, as they work for
> now.
>
> I suspect the way forward is to get numpy/Matplotlib/scipy working
Thanks for the fix Bob.
Unfortunately Matplotlib does not work with zipped data files, after
all that. So, we'll leave the recipes as is, as they work for now.
I suspect the way forward is to get numpy/Matplotlib/scipy working
with setuptools and using pkg_resources to manage the data files.
On Jul 18, 2006, at 5:32 PM, Josh Marshall wrote:
> Thanks for the info on how the various recipes work, Bob. Very
> helpful.
>
> On 19/07/2006, at 9:28 AM, Bob Ippolito wrote:
>> The recipe mechanism doesn't allow for it because it doesn't
>> generally make sense. There are very few packages t
Sebastian Haase wrote:
>Hi,
>(Thanks to Travis and Todd for answering my last "dot"-question)
>
>I'm trying to adjust my numarray based code to also run with numpy.
>It seems that a (maybe the only left) problem is that numarray had
>arr.rank giving the value of len(arr.shape)
>while in numpy thi
Hi,
(Thanks to Travis and Todd for answering my last "dot"-question)
I'm trying to adjust my numarray based code to also run with numpy.
It seems that a (maybe the only left) problem is that numarray had
arr.rank giving the value of len(arr.shape)
while in numpy this is now called
arr.ndim
Is t
Thanks for the info on how the various recipes work, Bob. Very helpful.
On 19/07/2006, at 9:28 AM, Bob Ippolito wrote:
> The recipe mechanism doesn't allow for it because it doesn't
> generally make sense. There are very few packages that can find
> their resources in an alternative manner. I'
Robert Kern wrote:
> I'm definitely -1 on putting them in numpy. numpy is large enough as it is.
> I'm
> -0 on making a standalone package. The time would be better spent on making
> sure
> that scipy subpackages can be downloaded, built and installed individually.
+1
The whole SciPy installa
Sebastian Haase wrote:
> OK - understood. Combining int32 with float64 proves to be less
> cumbersome ...
>
> Why are numarray and numpy giving different answers ?
>
I have a little insight as to what is going on here but no fix.
numarray has two versions of dot():
1. The original dot()
Victoria G. Laidler wrote:
> I'm a numarray user that relies on convolve.
Thanks for voicing your opinion.
We should be clear about what we are talking about.
1) There is already a convolve in NumPy (it's the same one that was in
Numeric). It seems the one in numarray is compatible.
I'm tal
On Tue, Jul 18, 2006 at 11:45:32AM -0700, Andrew Straw wrote:
>>I am unable to access these repositories (which sound very useful, and
>>for which I am grateful to Andrew!).
>
>Hmm, that looks like DNS error. My repository is still up and online...
It is indeed a DNS error. I should have tested f
Perry Greenfield wrote:
>
> On Jul 18, 2006, at 2:50 PM, Travis Oliphant wrote:
>
>>
>> I'd like to get suggestions about what to do about the remaining
>> numarray extension modules that are not addressed in NumPy (convolve,
>> image, nd_image). There will be people coming from numarray that w
I'm a numarray user that relies on convolve.
I would hope that one of the criteria by which to make such decisions is
"make the transition for numarray and numeric users as painless as
possible". Changing namespaces and introducing additional dependencies
is not painless. Thus unless there is a
Sven Schreiber wrote:
>Travis Oliphant schrieb:
>
>
>>I'd like to make release 1.0beta on Thursday. Please submit bug-reports
>>and fixes before then.
>>
>>
>>
>
>Just two things I noticed:
>
>
Thanks for commenting
>
>
import numpy as n
>import dft -> failed: m
Sebastian Haase wrote:
> I'm using nd_image extensively. Considering that SciPy seem to install much
> easier these days than I remember I would be just happy to put them in to
> SciPy.
>
Well, what is the content of nd_image and image, compared to scipy.ndimage ?
> Some numarray people pref
On Jul 18, 2006, at 2:50 PM, Travis Oliphant wrote:
>
> I'd like to get suggestions about what to do about the remaining
> numarray extension modules that are not addressed in NumPy (convolve,
> image, nd_image). There will be people coming from numarray that
> will
> be using these modules.
Hi,
I have posted this mail from my google account a while ago, but
it obviously was blocked by sourceforge. What about that proposal of
moving numpy-discussion to scipy host?
Anyway, I have been recently working with arrays of objects and noticed
some problems. Here are the tickets:
Array impr
Travis Oliphant schrieb:
> I'd like to make release 1.0beta on Thursday. Please submit bug-reports
> and fixes before then.
>
Just two things I noticed:
>>> import numpy as n
import dft -> failed: module compiled against version 90709 of C-API but
this version of numpy is 9090d
>>> n.__versio
On Jul 18, 2006, at 3:22 PM, Travis Oliphant wrote:
> Robert Kern wrote:
>> Travis Oliphant wrote:
>>
>>> I'd like to get suggestions about what to do about the remaining
>>> numarray extension modules that are not addressed in NumPy
>>> (convolve,
>>> image, nd_image). There will be people c
Travis wrote:
> Of course, my opinion is that they should not have been placed in
> Numarray to begin with as the fit better as modules in SciPy.
Can we not put them into SciPy now?
Nick
-
Take Surveys. Earn Cash. Influenc
I'm using nd_image extensively. Considering that SciPy seem to install much
easier these days than I remember I would be just happy to put them in to
SciPy.
Some numarray people prefer a transitional "special place". I remember that
there was a discussion maybe a year ago of making SciPy so m
Hi,
I have been recently working with arrays of objects and noticed some
problems. Here are the tickets:
Array improperly created from numpy.poly1d object:
http://projects.scipy.org/scipy/numpy/ticket/185
Can't create matrix of dtype=object directly from list (problem of
ndarray.__new__):
http:/
Robert Kern wrote:
> Travis Oliphant wrote:
>
>> I'd like to get suggestions about what to do about the remaining
>> numarray extension modules that are not addressed in NumPy (convolve,
>> image, nd_image). There will be people coming from numarray that will
>> be using these modules.
>>
>
Travis Oliphant wrote:
> I'd like to get suggestions about what to do about the remaining
> numarray extension modules that are not addressed in NumPy (convolve,
> image, nd_image). There will be people coming from numarray that will
> be using these modules.
>
> Of course, my opinion is that
I'd like to get suggestions about what to do about the remaining
numarray extension modules that are not addressed in NumPy (convolve,
image, nd_image). There will be people coming from numarray that will
be using these modules.
Of course, my opinion is that they should not have been placed
Michael Williams wrote:
>>Hi Andrew (and others),
>>
>>On Mon, Jun 19, 2006 at 09:32:44AM -0700, Andrew Straw wrote:
>>
>>
>
>
I have updated the apt repository I maintain for Ubuntu's Dapper, which
now includes:
numpy
matplotlib
scipy
Each package is from a
On 7/18/06, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> it cannot upcast, as the '+=' operation will use only the
> memory initially allocated for a.
Not true:
>>> x = [2,3]
>>> x += array(2)
>>> type(x)
This is just the design choice made by numpy.
I don't see the need for an error. Augmented
On 7/18/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> Eric Emsellem wrote:
> > thanks for the tips. (indeed your "add.reduce" is correct: I just wrote
> > this down too quickly, in the script I have a "sum" included).
> >
> > And yes you are right for the memory issue, so I may just keep the loop
>
Tim Hochberg wrote:
> I just wanted to add that there are faster, but considerably complicated
> ways to attack this class of problems. The one I've looked at in the
> past was the fast multipole method and I believe there are others. I'm
> not sure whether these can be implemented efficiently i
Hi Andrew (and others),
On Mon, Jun 19, 2006 at 09:32:44AM -0700, Andrew Straw wrote:
>I have updated the apt repository I maintain for Ubuntu's Dapper, which
>now includes:
>
>numpy
>matplotlib
>scipy
>
>Each package is from a recent SVN checkout and should thus be regarded
>as "bleeding edge". T
On 7/18/06, Eric Emsellem <[EMAIL PROTECTED]> wrote:
[...]
> (is "sum" different than "add.reduce"?)
"sum" is a wrapper around ndarray.sum method, while add.reduce is a
ufunc method. At the C level they are the same, but "sum" may be a
little slower for the small arrays.
> python -m timeit -s "f
Albert Strasheim schrieb:
> Hello all
>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:numpy-
>> [EMAIL PROTECTED] On Behalf Of Keith Goodman
>> Sent: 18 July 2006 15:55
>> To: Thomas Heller
>> Cc: numpy-discussion@lists.sourceforge.net
>> Subject: Re: [Numpy-discussion] Cannot b
Eric Emsellem wrote:
> thanks for the tips. (indeed your "add.reduce" is correct: I just wrote
> this down too quickly, in the script I have a "sum" included).
>
> And yes you are right for the memory issue, so I may just keep the loop
> in and try to make it work on a fast PC...(or use parallel pr
Hello all
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:numpy-
> [EMAIL PROTECTED] On Behalf Of Keith Goodman
> Sent: 18 July 2006 15:55
> To: Thomas Heller
> Cc: numpy-discussion@lists.sourceforge.net
> Subject: Re: [Numpy-discussion] Cannot build numpy svn on Windows
>
> On 7/1
thanks for the tips. (indeed your "add.reduce" is correct: I just wrote
this down too quickly, in the script I have a "sum" included).
And yes you are right for the memory issue, so I may just keep the loop
in and try to make it work on a fast PC...(or use parallel processes)
(is "sum" different
On Jul 18, 2006, at 10:23 AM, Eric Emsellem wrote:
> Hi,
>
> I have a specific quantity to derive from an array, and I am at the
> moment unable to do it for a too large array because it just takes too
> long! So I am looking for an advice on how to efficiently compute
> such a
> quantity:
>
>
Maybe this will help -- it computes the squared distances between a
bunch of points:
def dist2(x,c):
"""
Calculates squared distance between two sets of points.
n2 = dist2(x, c)
D = DIST2(X, C) takes two matrices of vectors and calculates the
squared Euclidean distance between
Hi,
I have a specific quantity to derive from an array, and I am at the
moment unable to do it for a too large array because it just takes too
long! So I am looking for an advice on how to efficiently compute such a
quantity:
I have 3 arrays of N floats (x[...], y[..], z[..]) and I wish to do:
r
On 7/18/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
> When I change this line in the generated config.h file:
>
> #define NPY_ALLOW_THREADS WITH_THREAD
>
> to this one:
>
> #define NPY_ALLOW_THREADS 1
>
> then I can build.
What part of numpy is threaded?
I suggest
lexsort
itertools.groupby of the indices
take
I think it would be really great if numpy had the first two as a
function or something like that. It is really useful to be able to
take an array and bucket it and apply further numpy operations like
accumulation functions.
On 7/18/06, Ste
Hi,
Does anyone have any suggestions for summarising data in numpy?
The quick description is that I want to do something like the SQL statement:
SELECT sum(field1), sum(field2) FROM table GROUP BY field3;
The more accurate description is that my data is stored in PyTables HDF
format, with
Nick Fotopoulos wrote:
> I've been looking over the wiki and am not sure where the best place
> would be for such a snippet. Would it go with the numpy examples
> under vectorize or perhaps in a cookbook somewhere?
Yes. It seems to me like a cookbook example. In the utopian future, when
ther
Sebastian Haase wrote:
> On Monday 17 July 2006 12:38, Travis Oliphant wrote:
>
> Any idea on my main question ?
> What is the dot product of a 2x2 and 3x2x3 supposed to look like ?
> Why are numarray and numpy giving different answers ??
>
I'm pretty sure the dot-product in Numeric (and I g
Building numpy from svn on Windows with Python 2.4.3 fails:
c:\svn\numpy\numpy\core\include\numpy\arrayobject.h(986) : fatal error C1017:
invalid integer constant expression
When I change this line in the generated config.h file:
#define NPY_ALLOW_THREADS WITH_THREAD
to this one:
#define NPY_
On Mon, 17 Jul 2006, John Lawless apparently wrote:
from scipy import *
a = array((1.2))
a += 1.3j
a
> array(1.2)
> Shouldn't this generate either an error or an up-cast, rather than
> silently discarding the imaginary part?
As I understand it:
it cannot upcast, as the '+=' ope
> I also placed in hooks so you can replace the scalarmath (for int,
> float, and complex) with the Python version of math (this works because
> the int, float, and complex scalars are sub-classes of the corresponding
> Python object).
Just for completeness some more tests using pythonmath/scalar
50 matches
Mail list logo
