[Numpy-discussion] Ransom Proposals
ndarray at mac.com
Sat Mar 25 09:54:01 CST 2006
On 3/24/06, Tim Hochberg <tim.hochberg at cox.net> wrote:
> Now that the fortran keyword is dead, I'll take time off from rejoicing,
> to briefly go over other proposals that were involved in that thread
> lest they get lost in the shuffle.
Many thanks for the effort. That thread actually started as
"ndarray.fill and ma.array.filled", but it quickly went off the
original topic and forked at your annalistic "(mumble mumble reshape
> * reshape -- The origination of that whole, enormous thread was with
> reshape and what its return behaviour should be. Currently it returns a
> view if possible, otherwise it returns a copy. That's evil behaviour. I
> believe that it should either always return a copy or return a view if
> possible and otherwise raise an exception. I think I actually prefer the
> later, although it's probably a more disruptive change, since its more
> flexible when combined with asarray and friends. One possible
> compromise would be to have numpy.reshape always copy, while
> array.reshape always returns a view.
Could you, please provide some examples of the current behavior that
you find undesired and how yuo would fix it? I believe the
inconsistency is that x.reshape(shape) is x depends on shape. This is
easy to fix. Do you also suggest that x.reshape(...).__array_data__
is x.__array_data__ should be False?
> * ascontiguous -- In private email Chris Barker mentioned that the name
> ascontiguous was confusing, or at least not to his taste and suggested
> "something like" ascontiguous_array. I don't like that one, but it might
> worth considering something that matches asarray and asanyarray.
> ascontigarray looks okay to me, but it's quite possible that I've
> staring at this too long and that's just cryptic.
+0 (+1 for "ascontiguousarray")
> * ndmin -- I still think ndmin should be spun off to a separate
> function. It's trivial to implement a fuction, call it paddims for lack
> of a better name (asatleastndimensionarray seems kind of long and
> cryptic!). It should have minimal performance since no data gets copied,
> and if it makes a difference I would be willing to implement it in C in
> need be so that that performance impact was minimized.
> def paddims(a, n):
> "return a view of 'a' with at least 'n' dimensions"
> dims = a.shape
> b = a.view()
> b.shape = (1,)*(n - len(dims)) + dims
> return b
+1 (Boolean parameter is almost always a sign that a function is overloaded.)
> * copy -- Yes, I understand that the copy flag is probably not going to
> change for backward compatibility reasons if nothing else, but there was
> one last point I wanted to make about the copy flag.
I am all for eliminating boolean parameters no matter what the
consequences are. For me foo(bool, ...) is always a sign that it
should be refactored to foo(...) an bar(...), with shared code
possibly going to _baz(...).
More information about the Numpy-discussion