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 discussion and
there are reasons to prefer the other practice (numpy as N, scipy as
S, pylab
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.
--
Robert Kern
I have come to believe that the whole world is an enigma, a harmless
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 discussion
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 namespaces done
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
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 namespaces and
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)
less so
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:
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 i made the
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
own modules)
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 discussion and
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.lib
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 on these
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
I hope we do NOT
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 numpy as np
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,
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
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 namespace
[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
--- 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 easy
to
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).
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
isinstance() can take a tuple of classes/types as its second argument:
In [1]: isinstance?
Type: builtin_function_or_method
Base Class: type 'builtin_function_or_method'
String Form:built-in function isinstance
Namespace: Python builtin
Docstring:
isinstance(object,
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 this case is a python
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
Charles R Harris wrote:
On Thu, Apr 10, 2008 at 12:38 PM, Charles Doutriaux
[EMAIL PROTECTED] mailto:[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)
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:
-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 à
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 is a good
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 to try
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:
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
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 others
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 assume),
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
___
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 :-)
Having it as
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'
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
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 much on
Google
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 docsearch
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
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).
Is
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
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
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
makes
the
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 types
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?
No. I should
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 have the same
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
Cool. I
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
[EMAIL
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
[EMAIL
51 matches
Mail list logo
