[Python-ideas] Python multi-dimensional array constructor
Chris Barker
chris.barker at noaa.gov
Wed Oct 19 19:48:04 EDT 2016
a few thoughts:
On Wed, Oct 19, 2016 at 12:08 PM, Todd <toddrjen at gmail.com> wrote:
> I have been thinking about how to go about having a multidimensional array
> constructor in python. I know that Python doesn't have a built-in
> multidimensional array class and won't for the foreseeable future.
>
no but it does have buffers and memoryviews and the extended buffer
protocol supports "strided" data -- i.e. multi-dimensional arrays. So it
would be nice to have SOME simple ndarray object in the standard library
that would wrap such buffers -- it would be nice for working with image
data, interacting with numpy arrays, etc.
The "trick" is that once you have the container, you want some
functionality -- so you add indexing and slicing -- natch. Then maybe some
simple math? then.... eventually, you are trying to put all of numpy into
the stdlib, and we already know we don't want to do that.
Though I still think a simple container that only supports indexing and
slicing would be lovely.
That all being said:
a = [| 0, 1, 2 || 3, 4, 5 |]
>
I really don't see the advantage of that over:
a = [[0, 1, 2],[3, 4, 5]]
really I don't -- and I'm a heavy numpy user, so I write a lot of those!
If there is a problem with the current options (and I'm not convinced there
is) it's that it in'st a literal for multidimensional array, but rather a
literal for a bunch of nested lists -- the list themselves are created, and
so are all the "boxed" values in the array -- only to be pulled out and
unboxed to be put in the array.
However, this is only for literals -- if your data are large, then they are
not going to be in literals, but rather read form a file or something, so
this is really not much of a limitation.
However, if you really don't like it, then you can pass a string to
aconfsturctor function instead:
a = arr_from_string(" | 0, 1, 2 || 3, 4, 5 | ")
yeah, you need to type the extra quotes, but that's not much.
NOTE: I'm pretty sure numpy has something like this already, for folks that
like the MATLAB style -- though I can't find it at the moment.
b = [| 0, 1, 2 |
> | 3, 4, 5 |]
>
b = [[ 0, 1, 2 ],
[ 3, 4, 5 ]]
You can also create a 2D row array by combining the two:
>
> a = [|| 0, 1, 2 ||]
>
a = [[ 0, 1, 2 ]] or is it: [[[ 0, 1, 2 ]]]
(I can't tell, so maybe your syntax is not so clear???
> For higher dimensions, you can just put more lines together:
>
> a = [||| 0, 1, 2 || 3, 4, 5 ||| 6, 7, 8 || 9, 10, 11 |||]
>
> b = [||| 0, 1, 2
> || 3, 4, 5
> ||| 6, 7, 8
> || 9, 10, 11
> |||]
>
I have no idea what that means!
> c = [||| 0, 1, 2 |
> | 3, 4, 5 |
> |
> | 6, 7, 8 |
> | 9, 10, 11 |||]
>
>
> A 3D row vector would just be:
>
> a = [||| 0, 1, 2 |||]
>
> A 3d column vector would be:
>
> a = [||| 0 || 1 || 2 |||]
>
> b = [||| 0
> || 1
> || 2
> |||]
>
> A 3D depth vector would be:
>
> a = [||| 0 ||| 1 ||| 2 |||]
>
> b = [||| 0
> ||| 1
> ||| 2
> |||]
>
nor these....
> At least in my opinion, this sort of approach really shines when making
> higher-dimensional arrays. These would all be equivalent (the | at the
> beginning and end are just to make it easier to align indentation, they
> aren't required):
>
> a = [|||| 48, 11, 141, 13, -60, -37, 58, -52, -29, 134
> || -6, 96, -66, 137, -59, -147, -118, -104, -123, -7
> ||| -103, 50, -89, -12, 28, -12, 119, -131, -73, 21
> || -58, 105, 25, -138, -106, -118, -29, -49, -63, -56
> |||| -43, -34, 101, -115, 41, 121, 3, -117, 101, -145
> || 100, -128, 76, 128, -113, -90, 52, -91, -72, -15
> ||| 22, -65, -118, 134, -58, 55, -73, -118, -53, -60
> || -85, -136, 83, -66, -35, -117, -71, 115, -56, 133
> ||||]
>
it does seem that you are saving some typing when you have high-dim arrays,
but I really dont see the readability here.
>
> I think both of the new examples are considerably clearer than the current
> approach.
>
not to me :-(
but anyway, the way to more this kind of thing forward is to use it as a
new format in an existing lib (like numpy, by passing it as a big string.
IF folks like it and start using it, then there is room for a conversation.
But I doubt (and I wouldn't support) that anyone would put a literal into
python for an object that doesn't exist in python...
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20161019/f666aa0b/attachment.html>
More information about the Python-ideas
mailing list