I am looking for feedback on the PEP. Of particular interest is the specification of multidimensional indexing that I've outlined. I think it is mostly the same as numarray (I'd love some feedback to be sure about that), except for the fact that X[K] where K is a a single integer index array can do 1-d indexing similar to MATLAB. The equivalent numarray indexing is available as X[K,]. Now that I've specified what is to happen, I think it won't be very difficult to code. I would also like some help on resolving the type issue. Is it important to have hierarchial classes defined (probably in Python) that can be used to check and/or specify type or are functions that check for various properties, fine. Right now x.type is specified as an attribute but the attribute could be replaced by a method. What to return is the biggest question. I've never had a problem with just the typecode characters although aliases (like Int16 or Short) which might be more meaningful are nice. Are shadow-classes important in this case? To me they look a little like extra bulk with no gain. I'd love to be educated as to why it is worth the extra effort to have a bunch of instances lying around. I don't feel very strongly about this though, so if somebody else does, I'm willing to go for it. I've designed Numeric3 so that it is not difficult to change how typecodes are specified on the Python level. We can really accommodate whatever. <Opening can ....> What is the opinion of everybody? -Travis
I would also like some help on resolving the type issue. Is it important to have hierarchial classes defined (probably in Python) that can be used to check and/or specify type or are functions that check for various properties, fine. Right now x.type is specified as an attribute but the attribute could be replaced by a method. What to return is the biggest question.
I've never had a problem with just the typecode characters although aliases (like Int16 or Short) which might be more meaningful are nice. Are shadow-classes important in this case? To me they look a little like extra bulk with no gain. I'd love to be educated as to why it is worth the extra effort to have a bunch of instances lying around. I don't feel very strongly about this though, so if somebody else does, I'm willing to go for it.
I've designed Numeric3 so that it is not difficult to change how typecodes are specified on the Python level. We can really accommodate whatever.
I am used to the numarray convention of using Int16 and so on, which to me are more meaningful and far more easy to remember then typecode characters. These could be aliases for character codes, which for most purposes would be fine for me. The only practical problem that comes to mind now is that if you print a type, you would get its character code, which I would find inconvenient as I generally don't use them. By using a python class you can use any string representation you like. But I suppose you could just provide a function/method to return a string representation for an alias to solve that. Peter
Peter Verveer wrote:
I would also like some help on resolving the type issue. Is it important to have hierarchial classes defined (probably in Python) that can be used to check and/or specify type or are functions that check for various properties, fine. Right now x.type is specified as an attribute but the attribute could be replaced by a method. What to return is the biggest question.
I've never had a problem with just the typecode characters although aliases (like Int16 or Short) which might be more meaningful are nice. Are shadow-classes important in this case? To me they look a little like extra bulk with no gain. I'd love to be educated as to why it is worth the extra effort to have a bunch of instances lying around. I don't feel very strongly about this though, so if somebody else does, I'm willing to go for it.
I've designed Numeric3 so that it is not difficult to change how typecodes are specified on the Python level. We can really accommodate whatever.
I am used to the numarray convention of using Int16 and so on, which to me are more meaningful and far more easy to remember then typecode characters. These could be aliases for character codes, which for most purposes would be fine for me. The only practical problem that comes to mind now is that if you print a type, you would get its character code, which I would find inconvenient as I generally don't use them. By using a python class you can use any string representation you like. But I suppose you could just provide a function/method to return a string representation for an alias to solve that.
Peter
I agree, the use of numerictypes is the better way to go. By all means provide a tool of some sort to permit onversion from or to the C codes. Colin W.
Travis Oliphant <oliphant@ee.byu.edu>:
I am looking for feedback on the PEP. Of particular interest is the specification of multidimensional indexing that I've outlined. I think it is mostly the same as numarray (I'd love some feedback to be sure about that), except for the fact that X[K] where K is a a single integer index array can do 1-d indexing similar to MATLAB. The equivalent numarray indexing is available as X[K,]. Now that I've specified what is to happen, I think it won't be very difficult to code.
Sorry if I'm a bit quick to respond here (haven't read the PEP yet; I seem to have lost the URL) but ... is this related to the following issue (which I struggled with for a while back in 2002)? http://sourceforge.net/mailarchive/message.php?msg_id=2700193 IMO, special-casing (if that's what you're proposing) is a Bad Think(tm), as general code will then have to add special-casing to avoid tripping over it... (But I may just be confused here :) - M -- Magnus Lie Hetland Fallen flower I see / Returning to its branch http://hetland.org Ah! a butterfly. [Arakida Moritake]
Magnus Lie Hetland <magnus@hetland.org>:
Bad Think(tm)
... or Thing, as the case may be ;) -- Magnus Lie Hetland Fallen flower I see / Returning to its branch http://hetland.org Ah! a butterfly. [Arakida Moritake]
Travis Oliphant wrote:
I am looking for feedback on the PEP. Of particular interest is the specification of multidimensional indexing that I've outlined. I think it is mostly the same as numarray (I'd love some feedback to be sure about that), except for the fact that X[K] where K is a a single integer index array can do 1-d indexing similar to MATLAB. The equivalent numarray indexing is available as X[K,]. Now that I've specified what is to happen, I think it won't be very difficult to code.
Your indexing implementation appears reasonable.
I would also like some help on resolving the type issue. Is it important to have hierarchial classes defined (probably in Python) that can be used to check and/or specify type or are functions that check for various properties, fine. Right now x.type is specified as an attribute but the attribute could be replaced by a method. What to return is the biggest question.
I don't see the need for hierarchical type classes, though it might ease the comparison with Python types.
I've never had a problem with just the typecode characters although aliases (like Int16 or Short) which might be more meaningful are nice. Are shadow-classes important in this case? To me they look a little like extra bulk with no gain. I'd love to be educated as to why it is worth the extra effort to have a bunch of instances lying around. I don't feel very strongly about this though, so if somebody else does, I'm willing to go for it.
I prefer Int16, UInt16, Float32, Float64, etc. for specifying types. They are unambiguous and the scheme is easily extendable. I also don't mind character code aliases for named types as long as they are a shorthand for the them and are not used routinely when doing a repr. -- Paul -- Paul Barrett, PhD Space Telescope Science Institute Phone: 410-338-4475 ESS/Science Software Branch FAX: 410-338-4767 Baltimore, MD 21218
A Dijous 17 Febrer 2005 14:56, Paul Barrett va escriure:
I prefer Int16, UInt16, Float32, Float64, etc. for specifying types. They are unambiguous and the scheme is easily extendable. I also don't mind character code aliases for named types as long as they are a shorthand for the them and are not used routinely when doing a repr.
I completely agree with that point of view too. --
qo< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data ""
Francesc Altet wrote:
A Dijous 17 Febrer 2005 14:56, Paul Barrett va escriure:
I prefer Int16, UInt16, Float32, Float64, etc. for specifying types. They are unambiguous and the scheme is easily extendable. I also don't mind character code aliases for named types as long as they are a shorthand for the them and are not used routinely when doing a repr.
I completely agree with that point of view too.
I also agree. Bob
Paul Barrett <barrett@stsci.edu> writes:
I prefer Int16, UInt16, Float32, Float64, etc. for specifying types.
The C based types have their uses: if you want to call external libraries that use double or int from Python, you will want to work with arrays of double or int without having to care how many bits they happen to be on the current platform. -- Timo Korvola <URL:http://www.iki.fi/tkorvola>
On 17 Feb 2005, at 17:53, Timo Korvola wrote:
Paul Barrett <barrett@stsci.edu> writes:
I prefer Int16, UInt16, Float32, Float64, etc. for specifying types.
The C based types have their uses: if you want to call external libraries that use double or int from Python, you will want to work with arrays of double or int without having to care how many bits they happen to be on the current platform.
Agreed, I find them very useful for such cases. Normally I use the exact specifications, but I agree that the C based types should be around. Fortunately that should be easy to support.
A Dijous 17 Febrer 2005 17:56, Peter Verveer va escriure:
On 17 Feb 2005, at 17:53, Timo Korvola wrote: Agreed, I find them very useful for such cases. Normally I use the exact specifications, but I agree that the C based types should be around. Fortunately that should be easy to support.
Yes, I think so. Why not .type for Python types (and numarray compatibility) and .typecode for C types (and Numeric compatibility)?. numarray supports both right now without problems. Besides, in numarray.records module, you may find the following map: numfmt = {'i1':num.Int8, 'u1':num.UInt8, 'i2':num.Int16, 'u2':num.UInt16, 'i4':num.Int32, 'u4':num.UInt32, 'i8':num.Int64, 'u8':num.UInt64, 'f4':num.Float32, 'f8':num.Float64, 'c8':num.Complex32, 'c16':num.Complex64, 'b1':num.Bool} which I find very useful and intuitive, but I guess it is incompatible with current Numeric convention (that I find quite confusing, anyway). Cheers, --
qo< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data ""
Travis Oliphant <oliphant@ee.byu.edu> writes:
except for the fact that X[K] where K is a a single integer index array can do 1-d indexing similar to MATLAB.
I find the current Numarray behaviour more logical. Is 1-D indexing really useful enough to require a shorter and less clear notation than X.flat[K]? Another one that I don't like is capping the indices. Is it useful or just a potential source of obscure errors? Throwing an IndexError for out of range indices would seem safer. Perhaps only one ellipsis should be allowed for clarity? Is it useful to allow more if they are only equivalent to colons? Integers scalars are not on the list where you describe how different types are interpreted in advanced indexing. I suppose the intention is to treat them as rank 0 arrays, broadcastable to any shape. The rank of a basic index expression can only be zero if all dimensions are indexed and all the indices are integers. Are you really suggesting that a rank 0 array rather than a scalar be returned in that case? -- Timo Korvola <URL:http://www.iki.fi/tkorvola>
Timo Korvola wrote:
Travis Oliphant <oliphant@ee.byu.edu> writes:
except for the fact that X[K] where K is a a single integer index array can do 1-d indexing similar to MATLAB.
[snip, snip]
Perhaps only one ellipsis should be allowed for clarity? Is it useful to allow more if they are only equivalent to colons?
This is the case anyway, since the ellipsis operator is greedy and swallows up all unspecified indices. Any later ellipsis operators should be ignored, otherwise this situation is ambiguous. -- Paul -- Paul Barrett, PhD Space Telescope Science Institute Phone: 410-338-4475 ESS/Science Software Branch FAX: 410-338-4767 Baltimore, MD 21218
Paul Barrett <barrett@stsci.edu> writes:
Any later ellipsis operators should be ignored, otherwise this situation is ambiguous.
The PEP says they'll turn into colons, which is not the same as being ignored. It only describes advanced indexing though, which is very different from basic indexing. In advanced indexing an ellipsis would pick diagonal entries, e.g., a[NewAxis, ...][[0], ...] would return the diagonal of a. -- Timo Korvola <URL:http://www.iki.fi/tkorvola>
Timo Korvola wrote:
Paul Barrett <barrett@stsci.edu> writes:
Any later ellipsis operators should be ignored, otherwise this situation is ambiguous.
The PEP says they'll turn into colons, which is not the same as being ignored.
This is the current default behavior for Numeric standard slicing, so I see this as a continuation of previous behavior. I guess it should be more accurately stated, however, because two ellipses right next to each other will always be the same as one ellipse. Only if they are separated by something else will another ellipse be interpreted as a single colon. I'm happy to raise an error instead if people have not been using this "feature" -Travis
I'm generally going to refrain from making comments since it usually is obvious what we prefer. But there may be exceptions (perhaps a reminder of past arguments, a desire to change numarray behavior, or clarify what the issue is). On Feb 17, 2005, at 2:25 AM, Travis Oliphant wrote:
I am looking for feedback on the PEP. Of particular interest is the specification of multidimensional indexing that I've outlined. I think it is mostly the same as numarray (I'd love some feedback to be sure about that), except for the fact that X[K] where K is a a single integer index array can do 1-d indexing similar to MATLAB. The equivalent numarray indexing is available as X[K,]. Now that I've specified what is to happen, I think it won't be very difficult to code.
Could you clarify this with an example? I'm not quite sure what alternatives you are addressing.
I would also like some help on resolving the type issue. Is it important to have hierarchial classes defined (probably in Python) that can be used to check and/or specify type or are functions that check for various properties, fine. Right now x.type is specified as an attribute but the attribute could be replaced by a method. What to return is the biggest question.
I'll just note that the hierarchial approach allows simpler tests for kinds of types (e.g., is the type an integer type) rather than doing something like ntype in [Int16, Int8,...]. Thanks, Perry
In article <421446E3.7080202@ee.byu.edu>, Travis Oliphant <oliphant@ee.byu.edu> wrote:
I've never had a problem with just the typecode characters although aliases (like Int16 or Short) which might be more meaningful are nice. Are shadow-classes important in this case? To me they look a little like extra bulk with no gain. I'd love to be educated as to why it is worth the extra effort to have a bunch of instances lying around.
Instances can give you useful information. For example: - the number of bytes needed to represent a value - the min and max values for that type (numarray doesn't do this yet, but I really hope it'll be added someday). I personally dislike character codes because they are uninformative and because they meaningless without the documentation. -- Russell
On Feb 17, 2005, at 11:02 PM, Russell E. Owen wrote:
In article <421446E3.7080202@ee.byu.edu>, Travis Oliphant <oliphant@ee.byu.edu> wrote:
I've never had a problem with just the typecode characters although aliases (like Int16 or Short) which might be more meaningful are nice. Are shadow-classes important in this case? To me they look a little like extra bulk with no gain. I'd love to be educated as to why it is worth the extra effort to have a bunch of instances lying around.
Instances can give you useful information. For example: - the number of bytes needed to represent a value - the min and max values for that type (numarray doesn't do this yet, but I really hope it'll be added someday).
+1 on this! This would be very useful...
Russell E. Owen wrote:
In article <421446E3.7080202@ee.byu.edu>, Travis Oliphant <oliphant@ee.byu.edu> wrote:
I've never had a problem with just the typecode characters although aliases (like Int16 or Short) which might be more meaningful are nice. Are shadow-classes important in this case? To me they look a little like extra bulk with no gain. I'd love to be educated as to why it is worth the extra effort to have a bunch of instances lying around.
Instances can give you useful information. For example: - the number of bytes needed to represent a value
import numarray.numarraycore as _n a= _n.arange(9, shape= (3, 3)) print 'bytes per element:', a.itemsize() bytes per element: 4
Alternatively:
a._type.bytes 4
- the min and max values for that type (numarray doesn't do this yet, but I really hope it'll be added someday).
This could come from the type instance but it's not too difficult to determine for a given type.
I personally dislike character codes because they are uninformative and because they meaningless without the documentation.
(+1) Colin W.
participants (11)
-
Bob Klimek -
Colin J. Williams -
Francesc Altet -
Magnus Lie Hetland -
Paul Barrett -
Perry Greenfield -
Peter Verveer -
Peter Verveer -
Russell E. Owen -
Timo Korvola -
Travis Oliphant