On Tue, Jun 25, 2019 at 10:42 AM Stephan Hoyer <sho...@gmail.com> wrote:
> On Tue, Jun 25, 2019 at 7:20 AM Todd <toddr...@gmail.com> wrote: > >> On Tue, Jun 25, 2019 at 9:35 AM Juan Nunez-Iglesias <jni.s...@gmail.com> >> wrote: >> >>> On Mon, 24 Jun 2019, at 11:25 PM, Marten van Kerkwijk wrote: >>> >>> Just to be sure: for a 1-d array, you'd both consider `.T` giving a >>> shape of `(n, 1)` the right behaviour? I.e., it should still change from >>> what it is now - which is to leave the shape at `(n,)`. >>> >>> >>> Just to chime in as a user: v.T should continue to be a silent no-op for >>> 1D arrays. NumPy makes it arbitrary whether a 1D array is viewed as a row >>> or column vector, but we often want to write .T to match the notation in a >>> paper we're implementing. >>> >> >> Why should it be silent? This is a source of bugs. At least in my >> experience, generally when people write v.T it is a mistake. Either they >> are coming from another language that works differently, or they failed to >> properly check their function arguments. And if you are doing it on >> purpose, you are doing something you know is a no-op for essentially >> documentation purposes, and I would think that is the sort of thing you >> need to make as explicit as possible. "Errors should never pass silently. >> Unless explicitly silenced." >> > > Writing v.T is also sensible if you're writing code that could apply > equally well to either a single vector or a stack of vectors. This mirrors > the behavior of @, which also allows either single vectors or stacks of > vectors (matrices) with the same syntax. > Fair enough. But although there are valid reasons to do a divide by zero, it still causes a warning because it is a problem often enough that people should be made aware of it. I think this is a similar scenario.
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion