Re: [Numpy-discussion] vander() docstring

On Thu, Apr 10, 2008 at 10:57 PM, Charles R Harris <[EMAIL PROTECTED]> wrote: > Turns out it matches the matlab definition. Maybe we just need another > function: vandermonde -1 It's needless duplication. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enig

Re: [Numpy-discussion] vander() docstring

On Wed, Apr 9, 2008 at 11:07 AM, Stéfan van der Walt <[EMAIL PROTECTED]> wrote: > On 09/04/2008, Andreas Klöckner <[EMAIL PROTECTED]> wrote: > > On Mittwoch 26 März 2008, Charles R Harris wrote: > > > The docstring is incorrect. The Vandermonde matrix produced is > compatible > > > with numpy po

Re: [Numpy-discussion] #734: interactive docstring search (lookfor)

On Thu, Apr 10, 2008 at 4:44 PM, Robert Kern <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 6:43 PM, Christopher Barker > <[EMAIL PROTECTED]> wrote: > > Is there anything numpy/scypi specific about it? I > > d like to use this kind of thing with other packages, in which case it > > def

Re: [Numpy-discussion] problem with float64's str()

On Thu, Apr 10, 2008 at 8:01 PM, Robert Kern <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 8:58 PM, Charles R Harris > <[EMAIL PROTECTED]> wrote: > > I'm open to suggestions. > > I have nothing better to offer than what you've done. Thank you! > OK, but it looks like I need to implement ou

Re: [Numpy-discussion] problem with float64's str()

On Thu, Apr 10, 2008 at 8:58 PM, Charles R Harris <[EMAIL PROTECTED]> wrote: > I'm open to suggestions. I have nothing better to offer than what you've done. Thank you! -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own m

Re: [Numpy-discussion] problem with float64's str()

On Thu, Apr 10, 2008 at 7:06 PM, Robert Kern <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 7:57 PM, Charles R Harris > <[EMAIL PROTECTED]> wrote: > > > > On Thu, Apr 10, 2008 at 6:38 PM, Robert Kern <[EMAIL PROTECTED]> > wrote: > > > > > > On Thu, Apr 10, 2008 at 7:31 PM, Charles R Harris >

Re: [Numpy-discussion] problem with float64's str()

On Thu, Apr 10, 2008 at 7:06 PM, Robert Kern <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 7:57 PM, Charles R Harris > <[EMAIL PROTECTED]> wrote: > > > > On Thu, Apr 10, 2008 at 6:38 PM, Robert Kern <[EMAIL PROTECTED]> > wrote: > > > > > > On Thu, Apr 10, 2008 at 7:31 PM, Charles R Harris >

Re: [Numpy-discussion] #734: interactive docstring search (lookfor)

Pauli Virtanen wrote: > Travis E. Oliphant kirjoitti: > >> Pauli Virtanen wrote: >> > [clip] > >>> I think this is a good idea: full-namespace docstring search à la Matlab >>> lookfor. I wrote a quick implementation for numpy here: >>> http://scipy.org/scipy/numpy/ticket/734 >>> >>>

Re: [Numpy-discussion] problem with float64's str()

On Thu, Apr 10, 2008 at 7:57 PM, Charles R Harris <[EMAIL PROTECTED]> wrote: > > On Thu, Apr 10, 2008 at 6:38 PM, Robert Kern <[EMAIL PROTECTED]> wrote: > > > > On Thu, Apr 10, 2008 at 7:31 PM, Charles R Harris > > <[EMAIL PROTECTED]> wrote: > > > > That said, str(float_numpy_scalar) really should

Re: [Numpy-discussion] problem with float64's str()

On Thu, Apr 10, 2008 at 6:38 PM, Robert Kern <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 7:31 PM, Charles R Harris > <[EMAIL PROTECTED]> wrote: > > > That said, str(float_numpy_scalar) really should have the same rules > > > as str(some_python_float). > > > > For all different precisions?

Re: [Numpy-discussion] problem with float64's str()

On Thu, Apr 10, 2008 at 7:31 PM, Charles R Harris <[EMAIL PROTECTED]> wrote: > > That said, str(float_numpy_scalar) really should have the same rules > > as str(some_python_float). > > For all different precisions? No. I should have said str(float64_numpy_scalar). I am content to leave the other t

Re: [Numpy-discussion] problem with float64's str()

On Fri, Apr 4, 2008 at 1:47 PM, Robert Kern <[EMAIL PROTECTED]> wrote: > On Fri, Apr 4, 2008 at 9:56 AM, Will Lee <[EMAIL PROTECTED]> wrote: > > I understand the implication for the floating point comparison and the > need > > for allclose. However, I think in a doctest context, this behavior > m

Re: [Numpy-discussion] problem with float64's str()

Thanks for all the comments about this issue. Do you know if there's a ticket that's open for this? Is this an easy fix before the 1.0.5 release? Thanks, Will On Fri, Apr 4, 2008 at 3:40 PM, Timothy Hochberg <[EMAIL PROTECTED]> wrote: > > > On Fri, Apr 4, 2008 at 12:47 PM, Robert Kern <[EMAIL

Re: [Numpy-discussion] #734: interactive docstring search (lookfor)

On Thu, Apr 10, 2008 at 6:43 PM, Christopher Barker <[EMAIL PROTECTED]> wrote: > Is there anything numpy/scypi specific about it? I > d like to use this kind of thing with other packages, in which case it > definitely does not belong in numpy or scipy. Basically, it's a configuration issue, I t

Re: [Numpy-discussion] #734: interactive docstring search (lookfor)

Travis E. Oliphant wrote: >> I think this is a good idea: full-namespace docstring search à la Matlab >> lookfor. I wrote a quick implementation for numpy here: >> http://scipy.org/scipy/numpy/ticket/734 cool! > I'm happy to move this functionality into numpy (but it might be better > in IPython

Re: [Numpy-discussion] meaning of accumulation/normalisation

On Thu, Apr 10, 2008 at 4:18 PM, wilson <[EMAIL PROTECTED]> wrote: > hi > i came across some image processing code in java and tried to > duplicate the operation on an ndarray.the array is supposed to contain > pixel values of a gryscale image generated by the program. however the > code does some

Re: [Numpy-discussion] #734: interactive docstring search (lookfor)

On Thu, Apr 10, 2008 at 3:29 PM, Joris De Ridder <[EMAIL PROTECTED]> wrote: > > On 10 Apr 2008, at 23:23, Travis E. Oliphant wrote: > > > Cool. I started scipy.misc.info a long time ago to try and do > > this. I > > didn't advertise it well enough ;-) > > Yep, I also started to write my own

Re: [Numpy-discussion] #734: interactive docstring search (lookfor)

Fernando Perez kirjoitti: > On Thu, Apr 10, 2008 at 3:08 PM, Hoyt Koepke <[EMAIL PROTECTED]> wrote: >>> In [1]: import numpy >> > >> > In [2]: numpy.info('eigvals') >> > *** Found in numpy.linalg *** >> > eigvals(a) >> >> Fair enough Don't know why I missed that, prob relied too

Re: [Numpy-discussion] #734: interactive docstring search (lookfor)

On 10 Apr 2008, at 23:23, Travis E. Oliphant wrote: > Cool. I started scipy.misc.info a long time ago to try and do > this. I > didn't advertise it well enough ;-) Yep, I also started to write my own docsearch tool but neglected to advertise it. On 10 Apr 2008, at 23:58, Gael Varoquaux

[Numpy-discussion] meaning of accumulation/normalisation

hi i came across some image processing code in java and tried to duplicate the operation on an ndarray.the array is supposed to contain pixel values of a gryscale image generated by the program. however the code does some accumulation operation as below to obtain a value 'norm' ul=array(([],[.

Re: [Numpy-discussion] #734: interactive docstring search (lookfor)

On Thu, Apr 10, 2008 at 3:08 PM, Hoyt Koepke <[EMAIL PROTECTED]> wrote: > > In [1]: import numpy > > > > In [2]: numpy.info('eigvals') > > *** Found in numpy.linalg *** > > eigvals(a) > > Fair enough Don't know why I missed that, prob relied too much on > Google search :-) > >

Re: [Numpy-discussion] #734: interactive docstring search (lookfor)

> In [1]: import numpy > > In [2]: numpy.info('eigvals') > *** Found in numpy.linalg *** > eigvals(a) Fair enough Don't know why I missed that, prob relied too much on Google search :-) Having it as part of iPython does make sense. --Hoyt ___

Re: [Numpy-discussion] #734: interactive docstring search (lookfor)

On Thu, Apr 10, 2008 at 02:54:48PM -0700, Hoyt Koepke wrote: > My personal 2 cents is that we should put it in the most easy-to-find > place. I wish I had the propsed lookfor function at my fingertips > when I started to learn numpy/scipy a year ago, coming from matlab. > Like many others (I assum

Re: [Numpy-discussion] #734: interactive docstring search (lookfor)

On Thu, Apr 10, 2008 at 4:54 PM, Hoyt Koepke <[EMAIL PROTECTED]> wrote: > My personal 2 cents is that we should put it in the most easy-to-find > place. I wish I had the propsed lookfor function at my fingertips > when I started to learn numpy/scipy a year ago, coming from matlab. > Like many o

Re: [Numpy-discussion] #734: interactive docstring search (lookfor)

My personal 2 cents is that we should put it in the most easy-to-find place. I wish I had the propsed lookfor function at my fingertips when I started to learn numpy/scipy a year ago, coming from matlab. Like many others (I assume), I just jumped in and learned what numpy could do by trial and err

Re: [Numpy-discussion] commutative allclose

On Thu, Apr 10, 2008 at 1:56 PM, Tom Johnson <[EMAIL PROTECTED]> wrote: > Should allclose() be commutative, so as to prevent the following: > > >>> x = 1.1001 > >>> allclose(x,1), allclose(1,x) > (False, True) > > There is some discussion here which provides two possible solutions: > > > http

Re: [Numpy-discussion] #734: interactive docstring search (lookfor)

Travis E. Oliphant kirjoitti: > Pauli Virtanen wrote: [clip] >> I think this is a good idea: full-namespace docstring search à la Matlab >> lookfor. I wrote a quick implementation for numpy here: >> http://scipy.org/scipy/numpy/ticket/734 >> > > Cool. I started scipy.misc.info a long time ago

Re: [Numpy-discussion] #734: interactive docstring search (lookfor)

Pauli Virtanen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Steven H. Rogers wrote: > >> There's definitely a place for docsearch from the shell. There's >> opportunity for context sensitive search that Sphinx generated docs >> couldn't easily duplicate. >> > > I think this

[Numpy-discussion] #734: interactive docstring search (lookfor)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steven H. Rogers wrote: > There's definitely a place for docsearch from the shell. There's > opportunity for context sensitive search that Sphinx generated docs > couldn't easily duplicate. I think this is a good idea: full-namespace docstring search

[Numpy-discussion] commutative allclose

Should allclose() be commutative, so as to prevent the following: >>> x = 1.1001 >>> allclose(x,1), allclose(1,x) (False, True) There is some discussion here which provides two possible solutions: http://www.boost.org/doc/libs/1_35_0/libs/test/doc/components/test_tools/floating_point_compar

Re: [Numpy-discussion] float32 is not a float ?

Charles R Harris wrote: > > > On Thu, Apr 10, 2008 at 12:38 PM, Charles Doutriaux > <[EMAIL PROTECTED] > wrote: > > Hello, > > I guess this maybe "normal" but it breaks a lot of thing when > conterting > from Numeric > > >>> a=numpy.ones(5,dtype=numpy

[Numpy-discussion] [ANN] EuroSciPy Registration now open

Greetings, I'm pleased to announce that the registration for the first-annual EuroSciPy Conference is now open. http://scipy.org/EuroSciPy2008 Please take advantage of the early-bird rate and register soon. We'd love to have an early idea of attendance so that we can scale the venue appro

Re: [Numpy-discussion] float32 is not a float ?

On Thu, Apr 10, 2008 at 12:38 PM, Charles Doutriaux <[EMAIL PROTECTED]> wrote: > Hello, > > I guess this maybe "normal" but it breaks a lot of thing when conterting > from Numeric > > >>> a=numpy.ones(5,dtype=numpy.float32) > >>> isinstance(a[0],float) > False > >>> It looks like float in thi

Re: [Numpy-discussion] float32 is not a float ?

isinstance() can take a tuple of classes/types as its second argument: In [1]: isinstance? Type: builtin_function_or_method Base Class: String Form: Namespace: Python builtin Docstring: isinstance(object, class-or-type-or-tuple) -> bool Return whether an object i

Re: [Numpy-discussion] Infinity definitions

Travis E. Oliphant wrote: > Bruce Southey wrote: > >> Hi, >> Since we are discussing namespace and standardization, I am curious in >> why there are multiple definitions for defining infinity in numpy when >> perhaps there should be two (one for positive infinity and one for >> negative infin

Re: [Numpy-discussion] float32 is not a float ?

Hi Charles On 10/04/2008, Charles Doutriaux <[EMAIL PROTECTED]> wrote: > >>> a=numpy.ones(5,dtype=numpy.float32) > >>> isinstance(a[0],float) I'd recommend using issubdtype instead: np.issubdtype(a[0],float) Regards Stéfan ___ Numpy-discussion mai

Re: [Numpy-discussion] Infinity definitions

On 10/04/2008, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > Bruce Southey wrote: > > Hi, > > Since we are discussing namespace and standardization, I am curious in > > why there are multiple definitions for defining infinity in numpy when > > perhaps there should be two (one for positive inf

Re: [Numpy-discussion] Numpy-discussion Digest, Vol 19, Issue, 44

Hi, > I receive the NumPy and SciPy digests because the amount of traffic > on the lists is so high and my time to keep up with them is so limited > (there is probably a way to filter emails in Thunderbird that would > work, but I still have to figure that out). Why not just create a filter that

Re: [Numpy-discussion] Numpy-discussion Digest, Vol 19, Issue, 44

James, Thank you for that very helpful set of suggestions. I think the main thing is to keep the subject heading so that we can parse which conversation the response is targeted to. Also, not including the entire digest in the response is useful as well. We don't want to push occasional po

[Numpy-discussion] float32 is not a float ?

Hello, I guess this maybe "normal" but it breaks a lot of thing when conterting from Numeric >>> a=numpy.ones(5,dtype=numpy.float32) >>> isinstance(a[0],float) False >>> float64 works... I can see why one could argue for returning False, but then the converter might be too zealous things t

Re: [Numpy-discussion] Making NumPy accessible to everyone (or no-one) (was Numpy-discussion Digest, Vol 19, Issue 44)

Lou Pecora wrote: > That's the point of the flexibility of import ... as Yes, it is. > Trying to lock in namespaces as np or N or whatever is > a BAD idea. Allow the flexibility. I don't think anyone is trying to lock anyone into anything. > But locking people into a standard, > even an infor

[Numpy-discussion] boolean indexing of rank-0 arrays and scalars - ticket #721

Hi, Ticket #721 is titled "0-dimensional boolean arrays should work as masks for array scalars". It is not quite clear to me what the right behaviour is. We are generally trying to make zero-dimensional arrays behave the same as array scalars, but I'm not sure how that should work in this case:

Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)

Gael Varoquaux wrote: > On Thu, Apr 10, 2008 at 10:15:31AM -0500, Travis E. Oliphant wrote: > > >>> I'm toying with the idea of having our students install SAGE this >>> year. This would give them a great framework for interactive >>> experimentation. I am worried, however, that it would keep

Re: [Numpy-discussion] Numpy-discussion Digest, Vol 19, Issue, 44

Hi Robert et al., > Please do not respond to digest messages. If you want to respond to > messages, subscribe to receive messages individually. Respond to the > just messages you are interested in and keep the Subject lines intact. Just a suggestion, which I hope doesn't annoy anyone :-). I rece

Re: [Numpy-discussion] Infinity definitions

Bruce Southey wrote: > Hi, > Since we are discussing namespace and standardization, I am curious in > why there are multiple definitions for defining infinity in numpy when > perhaps there should be two (one for positive infinity and one for > negative infinity). I really do understand that othe

Re: [Numpy-discussion] Making NumPy accessible to everyone (or no-one) (was Numpy-discussion Digest, Vol 19, Issue 44)

Lou, On 10/04/2008, Lou Pecora <[EMAIL PROTECTED]> wrote: > But locking people into a standard, > even an informal one is, as someone else said, acting > a bit too much like accountants. Stop, please! This is just the recommended standard for code inside of numpy and scipy. You are, of cours

[Numpy-discussion] Win32 installer: please test it

Hello, David Cournapeau has prepared a new win32 installer, which is aimed at solving the recurring problem of non working atlas on different sets of CPU. This installer simply checks which cpu you have, and installs the appropriate numpy accordingly (without atlas if your cpu is not supported). W

Re: [Numpy-discussion] Making NumPy accessible to everyone (or no-one) (was Numpy-discussion Digest, Vol 19, Issue 44)

--- Alexander Michael <[EMAIL PROTECTED]> wrote: > Hey! I use np *all the time* as an abbreviation for > "number of points". I don't > really see what the problem is with using > numpy.whatever in library code and > published scripts and whatever you want in one-off > throw-away scripts. It's eas

Re: [Numpy-discussion] numpy namespaces

[renaming thread due to digest reply...] Joe Harrington wrote: lots of good points... > What concerns me about the discussion is that we are still not > thinking like communications and thought-process experts, we are > thinking like categorizers and accountants. Well, yes and no. I'm thinking

[Numpy-discussion] Where to put financial functions...

renamed as this was a Digest response.. Travis E. Oliphant wrote: > I appreciate that. It is rewarding to have time invested be regarded > usefully by others. Very well regarded! > They are a small enough addition, that I don't think it > matters terribly much what we do with them. I think

Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)

On Thu, Apr 10, 2008 at 10:15:31AM -0500, Travis E. Oliphant wrote: > > I'm toying with the idea of having our students install SAGE this > > year. This would give them a great framework for interactive > > experimentation. I am worried, however, that it would keep them from > > learning how to

Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)

Stéfan van der Walt wrote: > Hi Chris > > On 09/04/2008, Christopher Barker <[EMAIL PROTECTED]> wrote: > >> I have yet to advocate that the Matlab users in my group (The Scientists >> that happen to need a bit of programming, but have no interest in it) >> start using Python, but, frankly, "i

Re: [Numpy-discussion] Simple financial functions for NumPy

> > Right now it looks like there is a mix of attitudes, about the > > financial > > functions. They are a small enough addition, that I don't think it > > matters terribly much what we do with them. So, it seems to me that > > keeping them in numpy.lib and following the rule for that names

[Numpy-discussion] Infinity definitions

Hi, Since we are discussing namespace and standardization, I am curious in why there are multiple definitions for defining infinity in numpy when perhaps there should be two (one for positive infinity and one for negative infinity). I really do understand that other people have use of these def

Re: [Numpy-discussion] Making NumPy accessible to everyone (or no-one) (was Numpy-discussion Digest, Vol 19, Issue 44)

Thanks Joe for the excellent post. It mirrors my experience with Python and Numpy very eloquently, and I think it presents a good argument against the excessive use of namespaces. I'm not so worried about N. vs np. though - I use the same method Matthew Brett suggests. If I'm going to use, say, sin

Re: [Numpy-discussion] Making NumPy accessible to everyone (or no-one) (was Numpy-discussion Digest, Vol 19, Issue 44)

On 10/04/2008, Alexander Michael <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 6:55 AM, Stéfan van der Walt <[EMAIL PROTECTED]> > wrote: > > Hi Joe, all > > > > On 10/04/2008, Joe Harrington <[EMAIL PROTECTED]> wrote: > > > > Absolutely. Let's please standardize on: > > > > import

Re: [Numpy-discussion] Making NumPy accessible to everyone (or no-one) (was Numpy-discussion Digest, Vol 19, Issue 44)

Alexander Michael wrote: > On Thu, Apr 10, 2008 at 6:55 AM, Stéfan van der Walt <[EMAIL PROTECTED]> > wrote: > >> Hi Joe, all >> >> On 10/04/2008, Joe Harrington <[EMAIL PROTECTED]> wrote: >> > > Absolutely. Let's please standardize on: >> > > import numpy as np >> > > import scipy as sp

Re: [Numpy-discussion] Making NumPy accessible to everyone (or no-one) (was Numpy-discussion Digest, Vol 19, Issue 44)

On Thu, Apr 10, 2008 at 6:55 AM, Stéfan van der Walt <[EMAIL PROTECTED]> wrote: > Hi Joe, all > > On 10/04/2008, Joe Harrington <[EMAIL PROTECTED]> wrote: > > > Absolutely. Let's please standardize on: > > > import numpy as np > > > import scipy as sp > > > > I hope we do NOT standardize

Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)

On 10 Apr 2008, at 05:21, Travis E. Oliphant wrote: > Right now it looks like there is a mix of attitudes, about the > financial > functions. They are a small enough addition, that I don't think it > matters terribly much what we do with them. So, it seems to me that > keeping them in numpy.

[Numpy-discussion] Making NumPy accessible to everyone (or no-one) (was Numpy-discussion Digest, Vol 19, Issue 44)

Hi Joe, all On 10/04/2008, Joe Harrington <[EMAIL PROTECTED]> wrote: > > Absolutely. Let's please standardize on: > > import numpy as np > > import scipy as sp > > I hope we do NOT standardize on these abbreviations. While a few may > have discussed it at a sprint, it hasn't seen broad discu

Re: [Numpy-discussion] Numpy-discussion Digest, Vol 19, Issue 44

On Thu, Apr 10, 2008 at 2:31 AM, Sebastian Haase <[EMAIL PROTECTED]> wrote: > I hope I won't we excluded from further discussions if I would prefer > to stick with my "single capital" approach for my "every day modules". > I already have a default, "import numpy as N" (and some others of my > o

Re: [Numpy-discussion] multiply array

 Le vendredi 04 avril 2008 à 00:28 -0700, wilson a écrit : > > #of shape (1,6) > > eval=array([[3.,3.2,1.,1.1,5.,0.5]]) > > > > eval.shape=(-1,) > > please not the correction..i need to multiply first row of egimgs with > 3.0 ,second row with 3.2,last(sixth) row with 0.5 ..For that > purpose

Re: [Numpy-discussion] NumPy 1.0.5 final blockers

On Wed, Apr 9, 2008 at 5:28 AM, Jarrod Millman <[EMAIL PROTECTED]> wrote: > On Wed, Apr 9, 2008 at 4:04 AM, Jarrod Millman <[EMAIL PROTECTED]> wrote: > > The NumPy 1.0.5 release is fast approaching! There are currently 109 > > closed tickets and just 19 open ones: > > http://projects.scipy.o

Re: [Numpy-discussion] Numpy-discussion Digest, Vol 19, Issue 44

Am Donnerstag, 10. April 2008 11:05:35 schrieb Matthew Brett: > type thing. Upper case also draws the eye to the capital letter, so > > print N.sin(a) > > pulls the eye to the N, so you have to disengage and remind yourself > that it's the sin(a) that is important, whereas: > > print np.sin(a) > >

Re: [Numpy-discussion] Numpy-discussion Digest, Vol 19, Issue 44

On Thu, Apr 10, 2008 at 11:05 AM, Matthew Brett <[EMAIL PROTECTED]> wrote: > Hi Joe, > > I do see your point - and agree that typing and cruft make code harder > to write and read, to some extent. But I think the point is - and I'm > increasingly finding this - that a judicious use of namespace

Re: [Numpy-discussion] Numpy-discussion Digest, Vol 19, Issue 44

Hi Joe, I do see your point - and agree that typing and cruft make code harder to write and read, to some extent. But I think the point is - and I'm increasingly finding this - that a judicious use of namespaces and 'from' statements makes the code much easier to read, as in import numpy as np f

Re: [Numpy-discussion] Numpy-discussion Digest, Vol 19, Issue 44

On Thu, Apr 10, 2008 at 02:21:05AM -0400, Joe Harrington wrote: > I'll go so far as to suggest that if scipy must > have multiple packages within it, we could have them each be their own > top-level package, and drop the "scipy." (or "S.", or "sp.") prefix > entirely. Sound like C-type namespace

Re: [Numpy-discussion] Numpy-discussion Digest, Vol 19, Issue 44

On Wed, Apr 9, 2008 at 11:21 PM, Joe Harrington <[EMAIL PROTECTED]> wrote: > > Absolutely. Let's please standardize on: > > import numpy as np > > import scipy as sp > > I hope we do NOT standardize on these abbreviations. While a few may > have discussed it at a sprint, it hasn't seen broad