[Numpy-discussion] Profiling line-by-line

[David Grant]

Is there any way to do line-by-line profiling in Python? The profiling results can tell me how much time is spent in all functions, but within a given function I can't get any idea of how much time was spent on each line. For example, in the example below, I can see that 
graphWidth.py is taking all the time, but there are many lines of code in graphWidth.py that aren't function calls, and I have no way of knowing which lines are the bottlenecks. I'm using hotspot currently, by the way.
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
10.2150.2150.2210.221 graphWidth.py:6(graphWidth)   270.0010.0000.0030.000
 oldnumeric.py:472(all)   260.0020.0000.0020.000 oldnumeric.py:410(sum)
   260.0010.0000.0020.000 oldnumeric.py:163(_wrapit)
   260.0010.0000.0010.000 oldnumeric.py:283(argmin)   260.0000.0000.0000.000
 numeric.py:111(asarray)00.000 0.000  profile:0(profiler)Thanks,-- 
David Grant 
-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Atlas and dual core

[Stephen Walton]

Keith Goodman wrote:

>Is there much speed to be gained by compiling atlas for a dual core system?
>  
>
I imagine the answer is yes.  However, Clint Whaley literally just today 
announced the first release of a beta version of ATLAS whose 
configuration utility actually supports Core Duo, although probably only 
under OSX.  Check Clint's message at

http://sourceforge.net/mailarchive/forum.php?thread_id=25989825&forum_id=426

By the way, everyone should also read the immediately previous message, 
posted a few weeks earlier by Clint.  gcc 4.x gives significantly worse 
floating point performance than gcc 3.x on most x86 platforms.  
Something to be aware of if you're benchmarking.  He's communicated 
about the problem to the gcc developers, but is, ah, less than confident 
they'll fix the problem.

Steve


-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] Pretty printing an array: no ellipses?

[Webb Sprague]

I am not sure where to look for this, sorry if it is RTFM or JPS
("just plain stupid"):

Is there a way to set a default to print the entire array, rather than
an ellipses version of it?  If not, why doesn't
pprint.pformat(numpy.random.normal(0,1,(100, 100)), width=1000) at
least give me something off the screen?

Thx!

-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Performance of defmatrix.py:103(__array_finalize__)

[Kevin Jacobs <[EMAIL PROTECTED]>]

On 7/19/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
Are you now using SVN NumPy, or are we still looking at NumPy 0.9.8 numbers?Sorry -- SVN updated as of about two hours ago.Thanks,-Kevin
-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Performance of defmatrix.py:103(__array_finalize__)

[Travis Oliphant]

Kevin Jacobs <[EMAIL PROTECTED]> wrote:

> On 7/19/06, *Travis Oliphant* <[EMAIL PROTECTED] 
> > wrote:
>
> Kevin Jacobs <[EMAIL PROTECTED]
> > wrote:
> > On 7/19/06, *Kevin Jacobs <[EMAIL PROTECTED]
> 
> >  >>* <[EMAIL PROTECTED]
> 
> > >>
> wrote:
> >
> > Is it expected that the following script would spend over
> half of
> > the total execution time in
> defmatrix.py:103(__array_finalize__)?
> >
> >
> > Confirmed that a similar overhead exists for arrays, though not as
> > extreme.  My application requires the ability to assign random
> > elements, so any speed ups here will result be quite significant.
> >
> There is an optimization for this kind of assignment in current NumPy
> SVN which "should" avoid the array creation over-head.
>
>
>
> There still seems to be a huge performance penalty with using a matrix 
> to set elements.  Consider this code where X is initially a matrix:


Are you now using SVN NumPy, or are we still looking at NumPy 0.9.8 numbers?

-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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Improved creation of object arrays

[Travis Oliphant]

Travis Oliphant wrote:
> I made a small change to the array creation function so that if you 
> explicitly specify dtype=object, then the logic for determining the 
> shape of the array is changed.
>
> The new logic for constructing dtype=object arrays from Python sequences 
> is that the shape is determined by nested lists (and only lists).  The 
> nesting must be consistent or else the elements of the last conforming 
> lists are assumed to be objects.
>   

Update:  

Now lists and tuples are both allowed for determining nested lists (that 
was needed for record arrays).

The shapes still have to match for a new dimension to be "detected"

-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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Performance of defmatrix.py:103(__array_finalize__)

[Travis Oliphant]

Kevin Jacobs <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Is it expected that the following script would spend over half of the 
> total execution time in defmatrix.py:103(__array_finalize__)?
>
> from numpy import matrix
>
> m=matrix( (1,1) )
> for i in range(100):
>   m[0,0] = 0.
>
>
> Python version is 2.5b1, NumPy 0.9.8.
>
> More importantly, is there a way to avoid this overhead?
This over-head should be removed in latest SVN NumPy.  Basically, at 
each point in the loop the 0. is being converted to a matrix.  You could 
probably avoid the over-head by doing the conversion first to a 0-d array.

val = array(0.)
m = matrix( (1,1) )
for i in range(1):
 m[0,0] = val



-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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Performance of defmatrix.py:103(__array_finalize__)

[Kevin Jacobs <[EMAIL PROTECTED]>]

On 7/19/06, Kevin Jacobs <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote:
Is it expected that the following script would spend over half of the total execution time in 
defmatrix.py:103(__array_finalize__)?Confirmed that a similar overhead exists for arrays, though not as extreme.  My application requires the ability to assign random elements, so any speed ups here will result be quite significant.
Thanks,-Kevin
-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] astype() causes segmentation fault when converting from string

[Travis Oliphant]

Yves Frederix wrote:
> Hi,
>
> The latest svn version of numpy seems to be causing a segmentation fault
> when converting an array containing strings to floats using .astype().
> It only seems to happen when converting 'from' strings. Casting between
> numerical types and 'to' strings is no problem.
>
>  :yves $ python -c "import numpy as N; print N.__version__; a =
> N.asarray('2'); a.astype(float);print 'OK';"
>  0.9.9.2844
>  Segmentation fault
>
>   
A bad attempt at allowing other threads to run is at fault.  We can't 
release the GIL for casting to and/or from strings

This should be fixed now.

-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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] confirm 98d7f7f15c27f5122181163442d621a0b506d01c

[Johannes Loehnert]

On Wednesday 19 July 2006 14:41, 
[EMAIL PROTECTED] wrote:
> Your membership in the mailing list Numpy-discussion has been disabled
> due to excessive bounces The last bounce received from you was dated
> 19-Jul-2006.  You will not get any more messages from this list until
> you re-enable your membership.  You will receive 3 more reminders like
> this before your membership in the list is deleted.
>
> To re-enable your membership, you can simply respond to this message
> (leaving the Subject: line intact), or visit the confirmation page at
>
>
> https://lists.sourceforge.net/lists/confirm/numpy-discussion/98d7f7f15c27f5
>122181163442d621a0b506d01c
>
>
> You can also visit your membership page at
>
>
> https://lists.sourceforge.net/lists/options/numpy-discussion/a.u.r.e.l.i.a.
>n%40gmx.net
>
>
> On your membership page, you can change various delivery options such
> as your email address and whether you get digests or not.  As a
> reminder, your membership password is
>
> numpylist
>
> If you have any questions or problems, you can contact the list owner
> at
>
> [EMAIL PROTECTED]

-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] Performance of defmatrix.py:103(__array_finalize__)

[Kevin Jacobs <[EMAIL PROTECTED]>]

Hi all,Is it expected that the following script would spend over half of the total execution time in defmatrix.py:103(__array_finalize__)?from numpy import matrixm=matrix( (1,1) )for i in range(100):
  m[0,0] = 0.Python version is 2.5b1, NumPy 0.9.8.More importantly, is there a way to avoid this overhead?Thanks,-Kevin Jacobs
-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] astype() causes segmentation fault when converting from string

[Yves Frederix]

Hi,

The latest svn version of numpy seems to be causing a segmentation fault
when converting an array containing strings to floats using .astype().
It only seems to happen when converting 'from' strings. Casting between
numerical types and 'to' strings is no problem.

 :yves $ python -c "import numpy as N; print N.__version__; a =
N.asarray('2'); a.astype(float);print 'OK';"
 0.9.9.2844
 Segmentation fault

An older version of numpy (the one I used before this upgrade) works
perfectly though:

 :yves $ python -c "import numpy as N; print N.__version__; a =
N.asarray('2'); a.astype(float);print 'OK';"
 0.9.9.2655
 OK

Cheers,
YVES

-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] r_, c_, hstack, and vstack with 1-d arrays

[Bill Baxter]

On 7/19/06, Sven Schreiber <[EMAIL PROTECTED]> wrote:
> Bill Baxter schrieb:
> > For 1-d inputs I think r_ should act like vstack, and c_ should act
> > like column_stack.
> > Currently r_ and c_ both act like hstack for 1-d inputs.
>
> Well Bill, as I said before, you should have stayed with matrices ;-)

:-D

> Seriously, I think all the quirks you mentioned recently are now gone.

Yeh, probably so.  The main one remaining for me is that matrix can't
take more than 2-D data.  So if I decide to go, say, from storing a
single polygon (N points x 2 coords), to a set of deformed versions of
the polygon (M deformations x N points x 2 coords), then suddenly I
have to switch a bunch of matrix types back to array types, and find
and fix all the small differences between the two, and deal with two
different types in my code (array and matrix) instead of one type
everywhere (array).  Or maybe I have to use a Python list of matrix.

Maybe it wouldn't be as bad as I imagine.  I haven't actually gone
through such a conversion with matrices.  It just seems like it would
probably be more pain than it is to add an extra dimension without
changing data type.


> I mean what you're experiencing now ist just logical from the point of
> view that rows and columns are 2d concepts, so a 1d array just isn't enough.

True, but other parts of Numpy handle that ambiguity more gracefully.
Like dot(), or column_stack.


> Having said that, however, here are some more constructive comments:
>
> First, I think using c_ is not recommended, it doesn't even appear in
> the book. But I have no idea why that is so, I'm using it also (with
> matrices), so I think it's valid to question that deprecation. Indeed it
> seems natural to make it act like column_stack for 1d arrays!?

Hmm, yeh, what is the status on r_ and c_?   My understanding was that
they were just new/experimental, and thus not documented in the book.
 I think they're quite handy, so I hope they're not going away.  There
was a discussion previously about changing the names to something a
little more attractive, but I've gotten pretty used to the names now.

> Second, changing r_ would obviously break some people's codes. Two
> workarounds: You switch to matrices (sorry, couldn't resist), or you use
> vstack (trivial, sorry again).

Well, if they are new, probably not that much code.

> > Also isn't it odd that there's a column_stack, but no row_stack?  I
> > guess that's because row_stack would just be an alias for vstack, but
> > still.

> I agree that for the poor non-matrix-users it would be good to have a
> pair of names that obviously belong together, instead of the current
> vstack/column_stack situation; with matrices you have the choice of
> r_/c_ or vstack/hstack that do exactly what you want (as you know).

--bill

-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] r_, c_, hstack, and vstack with 1-d arrays

[Sven Schreiber]

Bill Baxter schrieb:
> For 1-d inputs I think r_ should act like vstack, and c_ should act
> like column_stack.
> Currently r_ and c_ both act like hstack for 1-d inputs.

Well Bill, as I said before, you should have stayed with matrices ;-)
Seriously, I think all the quirks you mentioned recently are now gone.

I mean what you're experiencing now ist just logical from the point of
view that rows and columns are 2d concepts, so a 1d array just isn't enough.

Having said that, however, here are some more constructive comments:

First, I think using c_ is not recommended, it doesn't even appear in
the book. But I have no idea why that is so, I'm using it also (with
matrices), so I think it's valid to question that deprecation. Indeed it
seems natural to make it act like column_stack for 1d arrays!?

Second, changing r_ would obviously break some people's codes. Two
workarounds: You switch to matrices (sorry, couldn't resist), or you use
vstack (trivial, sorry again).


> 
> Also isn't it odd that there's a column_stack, but no row_stack?  I
> guess that's because row_stack would just be an alias for vstack, but
> still.
> 

I agree that for the poor non-matrix-users it would be good to have a
pair of names that obviously belong together, instead of the current
vstack/column_stack situation; with matrices you have the choice of
r_/c_ or vstack/hstack that do exactly what you want (as you know).

Good luck,
Sven

-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] RandomArray module

[Sebastian Żurek]

Thanks a lot Francescm, Bruce and Robert!
Your response was all the essentials I wanted to know.
As soon as I'll be back from my vacations time
I'll try numpys PRNG.

Sebastian




-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] r_, c_, hstack, and vstack with 1-d arrays

[Bill Baxter]

For 1-d inputs I think r_ should act like vstack, and c_ should act
like column_stack.
Currently r_ and c_ both act like hstack for 1-d inputs.

Background:
I keep getting bitten by the fact that this doesn't work:

>>> a = array([1,2,3])
>>> b = array([[1,2,3],[2,3,4]])
>>> c = array([4,5,6])
>>> r_[b,c]
**error**

and that this doesn't return a 2x3
>>> d = r_[a,c]
array([1, 2, 3, 4, 5, 6])

To get what I want I need something like :
>>> r_[[a],[c]]
array([[1, 2, 3],
   [4, 5, 6]])
And to get them columnwise I need the likes of:
>>> c_[a[:,newaxis], c[:,newaxis]]
array([[1, 4],
 [2, 5],
 [3, 6]])

It seems like the r_ (which I think of as a "row concatenator") should
assume that 1-d arrays are rows (like vstack does), and the c_
("column concatenator") should assume 1-d arrays are columns (like
column_stack does).

Then you'd have:
>>> r_[a,c]
array([[1, 2, 3],
 [4, 5, 6]])
>>> c_[a,c]
array([[1, 4],
 [2, 5],
 [3, 6]])

At any rate, r_'s behavior is currently different from vstack wrt 1-d
arrays, and identitcal to c_ and hstack.

Vstack, hstack, and column_stack give the following:
>>> vstack([a,c])
array([[1, 2, 3],
 [4, 5, 6]])
>>> hstack([a,c])
array([1, 2, 3, 4, 5, 6])
>>> column_stack([a,c])
array([[1, 4],
 [2, 5],
 [3, 6]])

Also isn't it odd that there's a column_stack, but no row_stack?  I
guess that's because row_stack would just be an alias for vstack, but
still.

--bb

-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] Allocating discontiguous arrays

[Albert Strasheim]

Hello all

In some situations, I have to work with very large matrices. My Windows
machine has 3 GB RAM, so I would expect to be able to use most of my
process's address space for my matrix.

Unfortunately, with matrices much larger than 700 or 800 MB, one starts
running into heap fragmentation problems: even though there's 2 GB available
to your process, it isn't available in one contiguous block.

To see this, you can try the following code which tries to allocate a ~1792
MB 2-d array or a list of 1-d arrays that add up to the same size:

import numpy as N
fdtype = N.dtype('http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] Improved creation of object arrays

[Travis Oliphant]

I made a small change to the array creation function so that if you 
explicitly specify dtype=object, then the logic for determining the 
shape of the array is changed.

The new logic for constructing dtype=object arrays from Python sequences 
is that the shape is determined by nested lists (and only lists).  The 
nesting must be consistent or else the elements of the last conforming 
lists are assumed to be objects.

Here are some examples:

array([[1,2],3,4],dtype=object)  returns a 1-d array of shape (3,)

array([[1,2],[3,4]],dtype=object)  returns a 2-d array of shape (2,2)

array([(1,2),(3,4)],dtype=object) returns a 1-d array of shape (2,)

array([],dtype=object) returns a 0-d array of shape ()

array([[],[],[]],dtype=object) returns a 1-d array of shape (3,)

array([[3,4],[5,6],None],dtype=object) returns a 1-d array of shape (3,)


You have to actually specify dtype=object to get this, otherwise the old 
code-path will be taken.


-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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

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

[Peter Verveer]

I am the author of nd_image. In my opinion the package should remain  
in SciPy, where it indeed belongs. The only reason it was in numarray  
is that there was no such thing as SciPy for numarray.

Although it is relatively bug-free and has a reasonable amount of  
image processing functions, it could stand a lot of improvement.  
Including it in a base NumPy package would be a mistake, as it is not  
a fully optimized and finished package.

nd_image should install easily as a separate package, hence it could  
be included in SciPy while maintaining the possibility for standalone  
usage.

Peter

>
> 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
> Numpy-discussion@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion


-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion