numpy-discussion — Discussion list for all users of Numerical Python

Re: [Numpy-discussion] What to do about numarray extension modules?

[Christopher B. <Chr...@no...>]

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 installation thing is HUGE! I now I still don't use any 
of SciPy because I can't get it all built. Is it yet possible to build 
SciPy on Fedora core 4 without lots of painful machinations?

When numpy was called SciPy.core, there was a lot of talk about how 
SciPy needed to be broken up into individual packages, particularly the 
Fortran and non-Fortran ones separated. It was a good idea then, and it 
still is.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [Numpy-discussion] numarray bug: dot product between 2x2 and 3x2x3 on Mac different from PC

[Todd M. <jm...@st...>]

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() is standalone, easy to install, and basically 
works.   This dot() does however have the type coercion wart where Int32 
dotted with Float32 silently loses precision.   

2. A more optimized dot(), ported from Numeric,   depends on an external 
BLAS.  This makes it faster but also generally harder to install.  This 
optimized dot() has the higher dimensional array bug you discovered.   
For arrays of rank > 2,  it's totally broken.  Since Mac OS-X has a 
standard BLAS,  it uses the optimized dot() by default and exposes the 
bug.   The optimized dot() is easy to turn off in cfg_packages.py by 
commenting out the lines:

# if os.path.exists('/System/Library/Frameworks/vecLib.framework'):
#         USE_LAPACK = True

Since numarray is being phased out and neither issue is a serious 
problem for STScI,  we're not planning to fix them.   If it's causing 
someone major hardship let us know and we'll reconsider.

Todd

Re: [Numpy-discussion] What to do about numarray extension modules?

[Travis O. <oli...@ee...>]

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 talking about the following numarray functions (please let me know 
if I'm missing anything).

* all of nd_image --- currently this is in scipy (as ndimage) and can 
already be built and installed as a separate package --- we need
                                     to work out distribution, though.

* all of image/
           combine.py
                     median
                     average
                     minimum
                     threshold
           _image.py
                     translate


* from Convolve/
            iraf_frame.py
            lineshape.py
            Convolve.py/
                   correlate2d
                   convolve2d
                   boxcar
                              


For now, I will port the image and Convolve packages and place them in 
the scipy/sandbox area.  From there we can figure out what to do with them.


-Travis

Re: [Numpy-discussion] [SciPy-user] updated Ubuntu Dapper packages for numpy, matplotlib, and scipy online

[Michael W. <wil...@as...>]

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 from a different machine
before posting. Thanks for the quick reply.

>>for the same reason. Does anyone know where they've gone and if
>>they're coming back?
>>
>I'm planning on keeping them around for a while -- at least until
>numpy, scipy, and matplotlib get integrated into my flavor-of-the-year
>Debian/Ubuntu release in a sufficiently up-to-date version.

Great. I've installed them now, and the seem to be working fine. Thanks
very much!

Cheers,
-- Mike

Re: [Numpy-discussion] What to do about numarray extension modules?

[Travis O. <oli...@ee...>]

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  will
>> be using these modules.
>>
>> 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.
>
>
> At that at the time (some years ago now), that wasn't an option for  
> us for the modules that we contributed since we couldn't use Numeric.  
> I'm glad that it's now possible to integrate these with numpy, but it  
> doesn't do much good now to lament that it didn't happen that way in  
> the past.


Of course.   I was just thinking aloud again.   That's the beauty of 
"organic" growth :-)  It does have it's own charm. 

-Travis

Re: [Numpy-discussion] What to do about numarray extension modules?

[Victoria G. L. <la...@st...>]

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 *compelling* argument to move 
them out, I would leave them in.

(From the numarray-user point of view, it would be "moving them out" 
even though they aren't there yet.)

Personally I wouldn't think that "numpy is big enough already" or "it 
fits better in scipy" to be compelling reasons. So, +1 to include them 
in numpy.


That said, personally I would argue that convolve is qualitatively 
different from image and ndimage. Convolution is a common mathematical 
operation on arrays; thus I think it belongs in numpy.


If any or all of them are not included in numpy, I would strongly prefer 
a small separate package than to put them in scipy. I try to minimize 
dependencies in my code; I really don't want to suddenly depend on all 
of scipy just so I can do a convolution!

Vicki Laidler

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 they should not have been placed in 
>Numarray to begin with as the fit better as modules in SciPy.
>
>But, given the situation.  Should we bring them over to NumPy?  Or, 
>perhaps provide a small package that contain these modules separately?
>
>With the numarray c_api that is now available in NumPy, these can be 
>easily ported.  It would be nice to have decided this by 1.0beta release 
>at the end of the week.
>
>Discussion please...
>
>-Travis
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>Numpy-discussion mailing list
>Num...@li...
>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>  
>

Re: [Numpy-discussion] Beta release on Thursday

[Travis O. <oli...@ee...>]

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: module compiled against version 90709 of C-API but
>this version of numpy is 9090d
>
>  
>
Make sure to do a clean build:  i.e.

rm -fr build
python setup.py install

Unfortunately, the dependency tracking does not re-build the 
sub-packages of numpy by itself when there is a header-file change.

>And TODO.txt looks pretty outdated, maybe to avoid a wrong impression
>and confusion when a lot of new people turn to numpy because of 1.0
>status this should be changed (or removed?).
>  
>

Good idea.


-Travis

Re: [Numpy-discussion] What to do about numarray extension modules?

[Pierre B. de R. <Pie...@so...>]

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 prefer a transitional "special place". I remember that 
> there was a discussion maybe a year ago of making SciPy so modular that 
> (some?) sub-packages would be installable completely independent anyway - 
> that would be the best :-)
>
> -Sebastian Haase
>
> On Tuesday 18 July 2006 12:09, 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.
>>>
>>> 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.
>>>
>>> But, given the situation.  Should we bring them over to NumPy?  Or,
>>> perhaps provide a small package that contain these modules separately?
>>>       
>> 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.
>>     
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>   

Re: [Numpy-discussion] What to do about numarray extension modules?

[Perry G. <pe...@st...>]

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.
>
> 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.

At that at the time (some years ago now), that wasn't an option for  
us for the modules that we contributed since we couldn't use Numeric.  
I'm glad that it's now possible to integrate these with numpy, but it  
doesn't do much good now to lament that it didn't happen that way in  
the past.

Perry

[Numpy-discussion] A bunch of tickets

[Filip W. <fi...@ft...>]

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 improperly created from numpy.poly1d objects:
http://projects.scipy.org/scipy/numpy/ticket/185

Can't create matrix of dtype=object directly from list (problem of ndarray.__new__):
http://projects.scipy.org/scipy/numpy/ticket/186

Subclassing does not always work for numpy.matrix:
http://projects.scipy.org/scipy/numpy/ticket/187

best,
Filip

Re: [Numpy-discussion] Beta release on Thursday

[Sven S. <sve...@gm...>]

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.__version__
'0.9.9.2840'


And TODO.txt looks pretty outdated, maybe to avoid a wrong impression
and confusion when a lot of new people turn to numpy because of 1.0
status this should be changed (or removed?).

Cheers,
Sven

Re: [Numpy-discussion] What to do about numarray extension modules?

[Perry G. <pe...@st...>]

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 coming from numarray  
>>> that will
>>> be using these modules.
>>>
>>> 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.
>>>
>>> But, given the situation.  Should we bring them over to NumPy?  Or,
>>> perhaps provide a small package that contain these modules  
>>> separately?
>>>
>>
>> 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.
>>
>>
> I think I like this idea as well.     I don't really want to grow  
> NumPy.
> But, I'm curious what the current numarray users think.
>
Our view, briefly, is that until it is easy to install scipy, or that  
scipy supports  modular installs, that we need one or the other to  
support our distributions. The first choice (bundling with numpy)  
would be more convenient for us, but is not necessary should they be  
available separately. So, in short, either is fine with us.

Perry

Re: [Numpy-discussion] What to do about numarray extension modules?

[Nick F. <nv...@MI...>]

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

Re: [Numpy-discussion] What to do about numarray extension modules?

[Sebastian H. <ha...@ms...>]

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 modular that 
(some?) sub-packages would be installable completely independent anyway - 
that would be the best :-)

-Sebastian Haase

On Tuesday 18 July 2006 12:09, 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.
> >
> > 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.
> >
> > But, given the situation.  Should we bring them over to NumPy?  Or,
> > perhaps provide a small package that contain these modules separately?
>
> 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.

[Numpy-discussion] A bunch of tickets

[Filip W. <fil...@gm...>]

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://projects.scipy.org/scipy/numpy/ticket/186

Subclassing does not always work for numpy.matrix:
http://projects.scipy.org/scipy/numpy/ticket/187

best,
Filip

Re: [Numpy-discussion] What to do about numarray extension modules?

[Travis O. <oli...@ie...>]

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.
>>
>> 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.
>>
>> But, given the situation.  Should we bring them over to NumPy?  Or, 
>> perhaps provide a small package that contain these modules separately?
>>     
>
> 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.
>
>   
I think I like this idea as well.     I don't really want to grow NumPy. 
But, I'm curious what the current numarray users think.

-Travis

Re: [Numpy-discussion] What to do about numarray extension modules?

[Robert K. <rob...@gm...>]

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 they should not have been placed in 
> Numarray to begin with as the fit better as modules in SciPy.
> 
> But, given the situation.  Should we bring them over to NumPy?  Or, 
> perhaps provide a small package that contain these modules separately?

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.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

[Numpy-discussion] What to do about numarray extension modules?

[Travis O. <oli...@ie...>]

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 in 
Numarray to begin with as the fit better as modules in SciPy.

But, given the situation.  Should we bring them over to NumPy?  Or, 
perhaps provide a small package that contain these modules separately?

With the numarray c_api that is now available in NumPy, these can be 
easily ported.  It would be nice to have decided this by 1.0beta release 
at the end of the week.

Discussion please...

-Travis

Re: [Numpy-discussion] updated Ubuntu Dapper packages for numpy, matplotlib, and scipy online

[Andrew S. <str...@as...>]

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 recent SVN checkout and should thus be regarded
>>>>as "bleeding edge". The repository has a new URL:
>>>>http://debs.astraw.com/dapper/ I intend to keep this repository online
>>>>for an extended duration. If you want to put this repository in your
>>>>sources list, you need to add the following lines to
>>>>/etc/apt/sources.list::
>>>>deb http://debs.astraw.com/ dapper/
>>>>deb-src http://debs.astraw.com/ dapper/
>>>>    
>>>>
>>    
>>
>>
>>I am unable to access these repositories (which sound very useful, and
>>for which I am grateful to Andrew!). apt-get update gives
>>
>>    "Failed to fetch http://debs.astraw.com/dapper/Release.gpg Could not
>>    resolve ‘debs.astraw.com’"
>>
>>  
>>
>  
>
Hmm, that looks like DNS error. My repository is still up and online...
debs.astraw.com is actually a "CNAME" record, which aliases another
domain name. The canonical domain name uses a dynamic DNS to point to a
dynamically assigned IP addresses. Your system (probably in your DNS
name resolution) must be having some issue with some of that.
Unfortunately, you can't just plug in the IP address, because I'm using
Apache virtual hosting to serve a website at "debs.astraw.com"
differently from other websites.

Anyhow, here's what I get, hopefully it will help you fix your DNS issue.

$ host debs.astraw.com
debs.astraw.com is an alias for astraw-office.kicks-ass.net.
astraw-office.kicks-ass.net has address 131.215.28.162
debs.astraw.com is an alias for astraw-office.kicks-ass.net.
debs.astraw.com is an alias for astraw-office.kicks-ass.net.



>>I am also unable to access the repositories listed on the website:
>>
>>    deb http://sefton.astraw.com/ubuntu/ dapper/
>>    deb-src http://sefton.astraw.com/ubuntu/ dapper/
>>  
>>
>  
>

Eek, I replaced that with the new one location and some more info.


>>for the same reason. Does anyone know where they've gone and if they're
>>coming back?
>>
>>  
>>
>  
>
I'm planning on keeping them around for a while -- at least until numpy,
scipy, and matplotlib get integrated into my flavor-of-the-year
Debian/Ubuntu release in a sufficiently up-to-date version.

Re: [Numpy-discussion] A Different Arithmetic Error: +=

[Sasha <nd...@ma...>]

On 7/18/06, Alan G Isaac <ai...@am...> 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)
<type 'numpy.ndarray'>

This is just the design choice made by numpy.

I don't see the need for an error.  Augmented assignment is a
sufficiently advanced
feature that those who use it can be expected to know what it does.
Loosing imaginary part maybe a more compelling reason for an error
than loosing precision, but it would be clearly wrong to have
different types behave differently.  Silent downcasting from float to
int is actually a useful feature.

Re: [Numpy-discussion] fast way of doing "cross-multiplications" ?

[Fernando P. <fpe...@gm...>]

On 7/18/06, Tim Hochberg <tim...@co...> 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
> > in and try to make it work on a fast PC...(or use parallel processes)
> >
> > (is "sum" different than "add.reduce"?)
> >
> > thanks again to both Bill Baxter and Perry Greenfield for their fast
> > (and helpful!) answers.
> >
> 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 in numpy, but you
> may want to take a look into this kind of more sophisticated/complicated
> approach if brute forcing the calculation doesn't work.

Indeed, FMM is the best known method that can turn this O(n^2) problem
into O(n*log(n)).  As Tim indicates, there is no easy way out of this
one.  Incidentally, there is a talk about FMM on the scipy'06
schedule, in case you are going to attend.

An alternative approach to FMM (conceptually similar in some ways) is
described here:

http://amath.colorado.edu/faculty/fperez/talks/0604_sanum_mwadap.pdf

Unfortunately this isn't exactly a half-hour optimization effort, as
the required machinery is pretty heavy duty.  And yes, this has all
been done in python and runs on current numpy/scipy (though it has
Fortran, C and C++ sprinkled as needed).

Cheers,

f

Re: [Numpy-discussion] fast way of doing "cross-multiplications" ?

[Robert K. <rob...@gm...>]

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 in numpy, but you 
> may want to take a look into this kind of more sophisticated/complicated 
> approach if brute forcing the calculation doesn't work.

<teaser>
Idesbald Van den Bosch will be giving a talk at SciPy'06 on implementing FMM and 
the multilevel fast multipole algorithm (MLFMA) using SciPy and weave.

http://www.scipy.org/SciPy2006
</teaser>

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

Re: [Numpy-discussion] updated Ubuntu Dapper packages for numpy, matplotlib, and scipy online

[Michael W. <wil...@as...>]

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". The repository has a new URL:
>http://debs.astraw.com/dapper/ I intend to keep this repository online
>for an extended duration. If you want to put this repository in your
>sources list, you need to add the following lines to
>/etc/apt/sources.list::
> deb http://debs.astraw.com/ dapper/
> deb-src http://debs.astraw.com/ dapper/

I am unable to access these repositories (which sound very useful, and
for which I am grateful to Andrew!). apt-get update gives

    "Failed to fetch http://debs.astraw.com/dapper/Release.gpg Could not
    resolve =E2=80=98debs.astraw.com=E2=80=99"

I am also unable to access the repositories listed on the website:

    deb http://sefton.astraw.com/ubuntu/ dapper/
    deb-src http://sefton.astraw.com/ubuntu/ dapper/

for the same reason. Does anyone know where they've gone and if they're
coming back?

Cheers,
--
Michael Williams
Rudolph Peierls Centre for Theoretical Physics
University of Oxford

Re: [Numpy-discussion] fast way of doing "cross-multiplications" ?

[Sasha <nd...@ma...>]

On 7/18/06, Eric Emsellem <ems...@ob...> 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 "from numpy import add, zeros, sum; x = zeros(10)" "sum(x)"
100000 loops, best of 3: 5.53 usec per loop
> python -m timeit -s "from numpy import add, zeros, sum; x = zeros(10)" "add.reduce(x)"
100000 loops, best of 3: 2.71 usec per loop

In the new code, I would recommend using the ndarray.sum method
instead of either of the two.


BTW, is this an optimization opportunity: compare

> python -m timeit -s "from numpy import add, zeros, sum; x = zeros(10); r=add.reduce" "r(x)"
100000 loops, best of 3: 2.55 usec per loop

and

> python -m timeit -s "from numpy import zeros; x = zeros(10)" "x.sum()"
100000 loops, best of 3: 3.88 usec per loop

?

Re: [Numpy-discussion] Cannot build numpy svn on Windows

[Thomas H. <th...@py...>]

Albert Strasheim schrieb:
> Hello all
> 
>> -----Original Message-----
>> From: num...@li... [mailto:numpy-
>> dis...@li...] On Behalf Of Keith Goodman
>> Sent: 18 July 2006 15:55
>> To: Thomas Heller
>> Cc: num...@li...
>> Subject: Re: [Numpy-discussion] Cannot build numpy svn on Windows
>> 
>> On 7/18/06, Thomas Heller <th...@py...> 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.
> 
> This might be due to some changes Travis made.
> 
> http://projects.scipy.org/scipy/numpy/changeset/2833
> 
> I was able to build r2834 on Windows without problems. Are you still seeing
> this error?

No, I can build now.  Travis fixed it immediately, probably with
the change that you refer to above.

Thomas