Charles R Harris wrote:
On Wed, Jun 25, 2008 at 2:04 PM, Neil Muller
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
On Wed, Jun 25, 2008 at 7:53 PM, Charles R Harris
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
But I wonder if this case isn't supposed to be caught by
Yes, but it is directed at the interpreter, which will raise a
TypeError if needed. But the interpreter doesn't know that some
generic function might return NotImplemented and wouldn't know what to
do if it did. What the user should see when they call something like
right_shift(a,b) and
On Thu, Jun 26, 2008 at 7:25 AM, Charles R Harris
[EMAIL PROTECTED] wrote:
Etch has a problem with memmap.roundtrip
while Lenny does fine, but that looks to be some other problem.
Indeed - I see this is already filed as #828. I'll look at this and
add any comments to that ticket.
--
Neil
Hi all,
We are busy writing several documents that address general NumPy
topics, such as indexing, broadcasting, testing, etc. I would like
for those documents to be available inside of NumPy, so that they
could be accessed as docstrings:
help(np.doc.indexing)
or
In [15]: np.doc.indexing?
2008/6/26 Stéfan van der Walt [EMAIL PROTECTED]:
Hi all,
We are busy writing several documents that address general NumPy
topics, such as indexing, broadcasting, testing, etc. I would like
for those documents to be available inside of NumPy, so that they
could be accessed as docstrings:
Hi all,
I am documenting `recarray`, and have a question:
Is its use still recommended, or has it been superseded by fancy data-types?
Regards
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
Just to clarify, the documentation Stefan refers to is topical
*reference* documentation for the numpy package infrastructure,
conventions, etc. The contemplated .doc module will be a few kB of
distilled reference text. Its contents will be included in the PDF
and HTML reference guides.
It may
Stéfan van der Walt wrote:
Hi all,
I am documenting `recarray`, and have a question:
Is its use still recommended, or has it been superseded by fancy data-types?
Regards
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
Stéfan van der Walt wrote:
Hi all,
I am documenting `recarray`, and have a question:
Is its use still recommended, or has it been superseded by fancy data-types?
I rarely recommend it's use (but some people do like attribute access to
the fields).It is wrong, however, to say that
Hi Travis,
On Thu, Jun 26, 2008 at 1:50 AM, Travis E. Oliphant [EMAIL PROTECTED]
wrote:
Yes, but it is directed at the interpreter, which will raise a
TypeError if needed. But the interpreter doesn't know that some
generic function might return NotImplemented and wouldn't know what to
Travis E. Oliphant wrote:
Stéfan van der Walt wrote:
Hi all,
I am documenting `recarray`, and have a question:
Is its use still recommended, or has it been superseded by fancy data-types?
I rarely recommend it's use (but some people do like attribute access to
the fields).It is
On Thu, Jun 26, 2008 at 11:38 AM, Travis E. Oliphant
[EMAIL PROTECTED] wrote:
Stéfan van der Walt wrote:
Hi all,
I am documenting `recarray`, and have a question:
Is its use still recommended, or has it been superseded by fancy data-types?
I rarely recommend it's use (but some people do
So it has a numeric value?
Yes, it's just a floating point number. It's not a very elegant thing,
but it does allow some ability to specify an ordering.
-Travis
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
Would someone kindly provide links to references for the fancy data types
superseding the recarrays? Having come from an R-Project background,
manipulating the latter takes time to become acclimated to when building
data.frame like objects.
TIA,
--
Vince Fulco
Hi Alan,
Decorators weren't introduced until Python2.4. I'm not sure what version we
require now, that information should probably be added to a DEPENDENCY file,
or maybe the README. Anyway, if we still support Python2.3 we can't use
decorators.
Chuck
On Thu, Jun 26, 2008 at 10:37 AM, Charles R Harris
[EMAIL PROTECTED] wrote:
Decorators weren't introduced until Python2.4. I'm not sure what version we
require now, that information should probably be added to a DEPENDENCY file,
or maybe the README. Anyway, if we still support Python2.3 we
On Thursday 26 June 2008 13:37:19 Charles R Harris wrote:
Hi Alan,
Decorators weren't introduced until Python2.4. I'm not sure what version we
require now, that information should probably be added to a DEPENDENCY
file, or maybe the README. Anyway, if we still support Python2.3 we can't
use
On Thu, Jun 26, 2008 at 1:37 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
Decorators weren't introduced until Python2.4. I'm not sure what version we
require now, that information should probably be added to a DEPENDENCY file,
or maybe the README. Anyway, if we still support Python2.3 we can't
On Thu, Jun 26, 2008 at 1:51 PM, Jarrod Millman [EMAIL PROTECTED] wrote:
Starting with NumPy 1.2 and SciPy 0.7 we will require Python 2.4 or
greater. I will make sure to update the documentation later today, if
no one gets to it before me.
In that case I will leave the decorators in
On Thu, Jun 26, 2008 at 11:51 AM, Jarrod Millman [EMAIL PROTECTED]
wrote:
On Thu, Jun 26, 2008 at 10:37 AM, Charles R Harris
[EMAIL PROTECTED] wrote:
Decorators weren't introduced until Python2.4. I'm not sure what version
we
require now, that information should probably be added to a
On Thu, Jun 26, 2008 at 11:48:06AM -0500, John Hunter wrote:
I personally think they are the best thing since sliced bread, and
everyone here who uses them becomes immediately addicted to them. I
would like to see better support for them, especially making the attrs
exposed to dir so tab
On Thu, Jun 26, 2008 at 3:34 PM, Gael Varoquaux
[EMAIL PROTECTED] wrote:
On Thu, Jun 26, 2008 at 11:48:06AM -0500, John Hunter wrote:
I personally think they are the best thing since sliced bread, and
everyone here who uses them becomes immediately addicted to them. I
would like to see
On Thu, Jun 26, 2008 at 15:13, Dan Yamins [EMAIL PROTECTED] wrote:
On Thu, Jun 26, 2008 at 3:34 PM, Gael Varoquaux
[EMAIL PROTECTED] wrote:
On Thu, Jun 26, 2008 at 11:48:06AM -0500, John Hunter wrote:
I personally think they are the best thing since sliced bread, and
everyone here who
Let's be clear, there are two very closely related things: recarrays
and record arrays. Record arrays are just ndarrays with a complicated
dtype. E.g.
In [1]: from numpy import *
In [2]: ones(3, dtype=dtype([('foo', int), ('bar', float)]))
Out[2]:
array([(1, 1.0), (1, 1.0), (1, 1.0)],
In [12]: r2.foo
Out[12]: array([1, 1, 1])
One downside of this is that the attribute access feature slows down
all field accesses, even the r['foo'] form, because it sticks a bunch
of pure Python code in the middle. Much code won't notice this, but if
you end up having to iterate over an
Does that clarify the discussion for you?
Yes, thanks very much, this is very helpful. (I think I was confused
by the fact that, AFAICT, the Guide to Numpy only mentions recarray --
as distinct from Record arrays -- in one somewhat cryptic line.) But
I guess that the numpy
I understand all your comments and thank you for making this distinction
explicit. I can see why recarray can slow code down, but I find attribute
lookup make code much more readable, and interactive work fantastic (tab
completion). For many of my applications I do have a strong use case for
these
On Thu, Jun 26, 2008 at 21:24, Gael Varoquaux
[EMAIL PROTECTED] wrote:
I understand all your comments and thank you for making this distinction
explicit. I can see why recarray can slow code down, but I find attribute
lookup make code much more readable, and interactive work fantastic (tab
On Thu, Jun 26, 2008 at 09:36:38PM -0500, Robert Kern wrote:
On Thu, Jun 26, 2008 at 21:24, Gael Varoquaux
[EMAIL PROTECTED] wrote:
I understand all your comments and thank you for making this distinction
explicit. I can see why recarray can slow code down, but I find attribute
lookup make
On Thu, Jun 26, 2008 at 1:25 PM, Robert Kern [EMAIL PROTECTED] wrote:
One downside of this is that the attribute access feature slows down
all field accesses, even the r['foo'] form, because it sticks a bunch
of pure Python code in the middle. Much code won't notice this, but if
you end up
We are delighted to announce that the Python Software Foundation has
answered our call and is providing sponsoring to the SciPy08 conference.
We will use this money to sponsor the registration fees and travel for up
to 10 college or graduate students to attend the conference. The PSF did
not
31 matches
Mail list logo
