26 weeks, 4 days, 2 hours and 9 minutes ago, Zdeněk Hurák asked why atleast_3d acts the way it does: http://article.gmane.org/gmane.comp.python.numeric.general/4382/match=atleas...
He doesn't seem to have gotten any answers. And now I'm wondering the same thing. Anyone have any idea?
--bb
Bill Baxter wrote:
26 weeks, 4 days, 2 hours and 9 minutes ago, Zdeněk Hurák asked why atleast_3d acts the way it does: http://article.gmane.org/gmane.comp.python.numeric.general/4382/match=atleas...
He doesn't seem to have gotten any answers. And now I'm wondering the same thing. Anyone have any idea?
This function came from scipy and was written by somebody at Enthought. I was hoping they would respond. The behavior of atleast_3d does make sense in the context of atleast_2d and thinking of 3-d arrays as "stacks" of 2-d arrays where the stacks are in the last dimension.
atleast_2d converts 1-d arrays to 1xN arrays
atleast_3d converts 1-d arrays to 1xNx1 arrays so that they can be "stacked" in the last dimension. I agree that this isn't consistent with the general notion of "pre-pending" 1's to increase the dimensionality of the array.
However, array(a, copy=False, ndmin=3) will always produce arrays with a 1 at the begining. So at_least3d is convenient if you like to think of 3-d arrays of stacks of 2-d arrays where the last axis is the "stacking" dimension.
-Travis
Travis Oliphant wrote:
Bill Baxter wrote:
26 weeks, 4 days, 2 hours and 9 minutes ago, Zdeněk Hurák asked why atleast_3d acts the way it does: http://article.gmane.org/gmane.comp.python.numeric.general/4382/match=atleas...
He doesn't seem to have gotten any answers. And now I'm wondering the same thing. Anyone have any idea?
This function came from scipy and was written by somebody at Enthought. I was hoping they would respond.
That would have either been from Eric or Travis V way back in the day. Both are out of the office today. The "3D arrays as stacks of 2D arrays" is probably as good an explanation as any. Much of Numeric (e.g. the axis dot() reduces over) was predicated on that kind of logic. There is probably some kind of consistency argument with dstack() and atleast_2d(), i.e.
In [46]: a = arange(5)
In [47]: atleast_3d(a) Out[47]: array([[[0], [1], [2], [3], [4]]])
In [48]: dstack([a, a]) Out[48]: array([[[0, 0], [1, 1], [2, 2], [3, 3], [4, 4]]])
In [49]: dstack(map(atleast_2d, [a, a])) Out[49]: array([[[0, 0], [1, 1], [2, 2], [3, 3], [4, 4]]])
In [50]: dstack(map(atleast_3d, [a, a])) Out[50]: array([[[0, 0], [1, 1], [2, 2], [3, 3], [4, 4]]])
That's the problem with consistency arguments; there are so many things one could be consistent with!
On Friday 22 September 2006 12:57, Travis Oliphant wrote:
Bill Baxter wrote:
26 weeks, 4 days, 2 hours and 9 minutes ago, Zdeněk Hurák asked why atleast_3d acts the way it does: http://article.gmane.org/gmane.comp.python.numeric.general/4382/match=atle ast+3d
He doesn't seem to have gotten any answers. And now I'm wondering the same thing. Anyone have any idea?
This function came from scipy and was written by somebody at Enthought. I was hoping they would respond. The behavior of atleast_3d does make sense in the context of atleast_2d and thinking of 3-d arrays as "stacks" of 2-d arrays where the stacks are in the last dimension.
atleast_2d converts 1-d arrays to 1xN arrays
atleast_3d converts 1-d arrays to 1xNx1 arrays so that they can be "stacked" in the last dimension. I agree that this isn't consistent with the general notion of "pre-pending" 1's to increase the dimensionality of the array.
However, array(a, copy=False, ndmin=3) will always produce arrays with a 1 at the begining. So at_least3d is convenient if you like to think of 3-d arrays of stacks of 2-d arrays where the last axis is the "stacking" dimension.
I'm working with "stacks of 2d arrays" -- but I was always under the impression that -- since the last axis is the "fastest" -- "stacks of <something>" should stack in the first dimension -- not the last --so that the members of the stack still remain contiguous is memory.
Is there a general consensus on how one should look at this ? Or are there multiple incompatible view -- maybe coming from different fields -- ?
-Sebastian
Thanks for the explanations, folks, I thought that might be the case.
On 9/23/06, Sebastian Haase haase@msg.ucsf.edu wrote:
I'm working with "stacks of 2d arrays" -- but I was always under the impression that -- since the last axis is the "fastest" -- "stacks of <something>" should stack in the first dimension -- not the last --so that the members of the stack still remain contiguous is memory.
I also don't see why you'd want to stack matrices along the last axis in numpy. C-style memory order is one reason not to, but printing as well seems to favor stacking matrices along the first (0th) axis instead of the last.
Is there a general consensus on how one should look at this ? Or are there multiple incompatible view -- maybe coming from different fields -- ?
I've beed stacking along the first axis myself. Perhaps the original folks who implemented atleast_3d were coming from Matlab, where stacking is generally done along the last axis. But everything in Matlab is Fortran order under the hood so it makes sense there.
Anyway, glad to know it was just the implementer's idiosyncracy rather than some deep secret of the universe that I wasn't aware of.
I sometimes wonder what sort of overhead is induced by numpy using primarily C-style while many of the underlying algorithms we use are in Fortran. I suspect f2py has to do a lot of copying to get things in the right order for making the calls to Fortran.
--bb
participants (4)
-
Bill Baxter -
Robert Kern -
Sebastian Haase -
Travis Oliphant