On Aug 2, 2015 7:30 AM, "Sturla Molden" <sturla.mol...@gmail.com> wrote:
>
> On 02/08/15 15:55, Kang Wang wrote:
>
> > Can anyone provide any insight/help?
>
> There is no "default order". There was before, but now all operators
> control the order of their return arrays from the order of their input
> array.
This is... overoptimistic. I would not rely on this in code that I wrote.
It's true that many numpy operations do preserve the input order. But there
are also many operations that don't. And which are which often changes
between releases. (Not on purpose usually, but it's an easy bug to
introduce. And sometimes it is done intentionally, e.g. to make functions
faster. It sucks to have to make a function slower for everyone because
someone somewhere is depending on memory layout default details.) And there
are operations where it's not even clear what preserving order means
(indexing a C array with a Fortran array, add(C, fortran), ...), and even
lots of operations that intrinsically break contiguity/ordering (transpose,
diagonal, slicing, swapaxes, ...), so you will end up with mixed orderings
one way or another in any non-trivial program.
Instead, it's better to explicitly specify order= just at the places where
you care. That way your code is *locally* correct (you can check it will
work by just reading the one function). The alternative is to try and
enforce a *global* property on your program ("everyone everywhere is very
careful to only use contiguity-preserving operations", where "everyone"
includes third party libraries like numpy and others). In software design,
local invariants invariants are always better than global invariants -- the
most well known example is local variables versus global variables, but the
principle is much broader.
-n
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
