Menu
▾
▴
numpy-discussion
|
From: Travis O. <oli...@ee...> - 2006-10-11 18:41:15
|
Hi all, Py3K is undergoing active development. This gives us an opportunity to discuss more significant changes to the language that might improve the experience of NumPy users. We should form a list and start commenting on the py3k mailing lists about what changes would be most helpful for our community. Please provide examples of changes to Python that you think might help us. A couple on my short list 1) Adding a *few* new infix operators. a) an extra multiplication operator to distinguish between element-by-element and dot b) extending 'and' and 'or' to allow element-by-element logical operations or adding && and || 2) Lowering the precedence of & so that a > 8 & a < 10 works as you would expect. |
|
From: Christopher B. <Chr...@no...> - 2006-10-11 19:07:50
|
Travis Oliphant wrote:
> A couple on my short list
>
> 1) Adding a *few* new infix operators.
>
> a) an extra multiplication operator to distinguish between
> element-by-element and dot
> b) extending 'and' and 'or' to allow element-by-element logical
> operations or adding && and ||
>
> 2) Lowering the precedence of & so that a > 8 & a < 10 works as you
> would expect.
Maybe this goes without saying, but:
3) Inclusion of an nd-array type in the standard lib!
(or at the very least, an nd-array protocol)
-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...
|
|
From: Travis O. <oli...@ee...> - 2006-10-11 19:15:35
|
Christopher Barker wrote: >Travis Oliphant wrote: > > >>A couple on my short list >> >>1) Adding a *few* new infix operators. >> >> a) an extra multiplication operator to distinguish between >>element-by-element and dot >> b) extending 'and' and 'or' to allow element-by-element logical >>operations or adding && and || >> >>2) Lowering the precedence of & so that a > 8 & a < 10 works as you >>would expect. >> >> > >Maybe this goes without saying, but: > >3) Inclusion of an nd-array type in the standard lib! > >(or at the very least, an nd-array protocol) > > Work on an nd-array protocol to extend the buffer protocol is occurring right now. It think this will be better in the end then a standard nd-array type. I think a multi-dimensional object array would at least be a nice step. There are enough differences between lists and 1-d arrays though, that I'm not sure the accepted multi-dimensional object array would just be the NumPy version. -Travis |
|
From: Christopher B. <Chr...@no...> - 2006-10-11 21:34:10
|
Travis Oliphant wrote:
>> 3) Inclusion of an nd-array type in the standard lib!
>> (or at the very least, an nd-array protocol)
>>
> Work on an nd-array protocol to extend the buffer protocol is occurring
> right now. It think this will be better in the end then a standard
> nd-array type.
Well, yes, if you have to choose just one. I'd like to see both.
> I think a multi-dimensional object array would at least be a nice step.
Me too. n-d slicing is so handy.
> There are enough differences between lists and 1-d arrays though, that
> I'm not sure the accepted multi-dimensional object array would just be
> the NumPy version.
I guess the question is whether the goal is an n-d list or an n-d array.
The key difference that I see is that numpy arrays are not re-sizable.
But I have to wonder how practical it is to make an nd-array re-sizable,
and, indeed, how that would work. I'm not sure what the n-d version of
append() would be.
Numpy provides three things that I think are key:
1) An n-d array data structure. These are very useful for lots of things
where an multi-dimensional data structure just makes sense. For these
cases, you need the object array type (class?), and n-d slicing.
2) array arithmetic: I'm a big fan of list comprehensions, but:
A = [x * 2 for x in B]
really is a LOT klunkier, and far less clear, than:
A = 2 * B
or even worse:
A = []
for x in B:
A.append(2*x)
While array arithmetic is often seen primarily as a performance
advantage (which, of course, it is) I also think it is a real boon to
clear, error-free coding, and Python could use that.
3) A bunch of other really "mathy" or "scientific" functions:
(looking in the numpy book here)
polynomial functions
set operations (hmm -- there is a Python set type)
bessel functions
smoothing windows
fft
llinalg
etc.
etc.
These really do belong in numpy (scipy?), rather than the standard lib.
However this turn out, thanks for keeping numpy in the py3k loop.
-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...
|
|
From: Charles R H. <cha...@gm...> - 2006-10-11 20:04:21
|
On 10/11/06, Travis Oliphant <oli...@ee...> wrote: > > > Hi all, > > Py3K is undergoing active development. This gives us an opportunity to > discuss more significant changes to the language that might improve the > experience of NumPy users. > > We should form a list and start commenting on the py3k mailing lists > about what changes would be most helpful for our community. > > Please provide examples of changes to Python that you think might help us. > > A couple on my short list > > 1) Adding a *few* new infix operators. > > a) an extra multiplication operator to distinguish between > element-by-element and dot > b) extending 'and' and 'or' to allow element-by-element logical > operations or adding && and || > > 2) Lowering the precedence of & so that a > 8 & a < 10 works as you > would expect. Yes on the extra operators. No on changing the precedence of &, that would just confuse the heck out of all us c/c++ programmers; && and || would be good. Yes to something that improves on the buffer interface, although it is certainly usable right now. Speaking long term, what about data types? The basic 80 bit extended precision float now occurs in 80, 96, and 128 bit versions depending on alignment. So what happens when quad precision, which will probably be in the next IEEE standard, comes down the pike and is 128 bits long? The length of a float will no longer be sufficient to distinguish the various types. Chuck |
|
From: A. M. A. <per...@gm...> - 2006-10-11 21:37:43
|
On 11/10/06, Charles R Harris <cha...@gm...> wrote: > Speaking long term, what about data types? The basic 80 bit extended > precision float now occurs in 80, 96, and 128 bit versions depending on > alignment. So what happens when quad precision, which will probably be in > the next IEEE standard, comes down the pike and is 128 bits long? The length > of a float will no longer be sufficient to distinguish the various types. This doesn't require python 3K; it can happn in numpy with no language support. But perhaps python 3K can be viewed as a chance to ditch backwards-compatibility baggage? (cough, Numeric compatibility, cough) Would it be of interest to have numeric datatypes integrated with python datatypes? How about IEEE floats in python proper, at least? It can be rather confusing when doing a calculation yields different results for arrays than for ordinary scalars... A. M. Archibald |
|
From: Christopher B. <Chr...@no...> - 2006-10-11 21:53:07
|
A. M. Archibald wrote:
> IEEE floats in python proper
+1
-CHB
--
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...
|
|
From: Eric F. <ef...@ha...> - 2006-10-11 22:47:03
|
Charles R Harris wrote: [...] > b) extending 'and' and 'or' to allow element-by-element logical > operations or adding && and || > > 2) Lowering the precedence of & so that a > 8 & a < 10 works as you > would expect. > > > Yes on the extra operators. No on changing the precedence of &, that > would just confuse the heck out of all us c/c++ programmers; && and || > would be good. Travis's suggestion 2 is consistent with c/c++, where precedence increases from logical to bitwise to relational. (e.g., http://www.cs.niu.edu/~duffin/csci241/precedence.html). Python precedence now increases from logical to relational to bitwise, so it is inconsistent with c/c++. (http://docs.python.org/ref/summary.html#l2h-456) Eric |
|
From: Rob H. <he...@ta...> - 2006-10-12 15:52:34
|
On Oct 11, 2006, at 1:41 PM, Travis Oliphant wrote: > a) an extra multiplication operator to distinguish between > element-by-element and dot One of the things I like about numpy is that element-by-element multiplication is default. Really, most of what I do is element by element, punctuated by a few matrix multiplications (or whatever other matrix operations) at the end. If I had a penny for every '.' I put in front of an operator in MATLAB, I would buy us all new computers -- expensive ones even. I hope that, if there is another multiplication operator like .*, that this will be shorthand for dot(A, B), and not for elem-by-elem multiplication. -Rob ---- Rob Hetland, Associate Professor Dept. of Oceanography, Texas A&M University http://pong.tamu.edu/~rob phone: 979-458-0096, fax: 979-845-6331 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X