On Tue, Jun 25, 2019 at 10:14 AM Todd <toddr...@gmail.com> wrote: > On Tue, Jun 25, 2019 at 11:47 AM Alan Isaac <alan.is...@gmail.com> wrote: > >> On 6/25/2019 11:03 AM, Todd wrote: >> > 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. >> >> >> >> I side with Stephan on this, but when there are opinions on both sides, >> I wonder what the resolution strategy is. I suppose there is a possible >> tension: >> >> 1. Existing practice should be privileged (no change for the sake of >> change). >> 2. Documented user issues need to be addressed. >> > > Note that the behavior wouldn't change. Transposing vectors would do > exactly what it has always done: nothing. But people would be made aware > that the operation they are doing won't actually do anything. > > I completely agree that change for the sake of change is not a good > thing. But we are talking about a no-op here. If someone is intentionally > doing something that does nothing, I would like to think that they could > deal with a warning that can be easily silenced. >
I am strongly opposed to adding warnings for documented and correct behavior that we are not going to change. Warnings are only appropriate in rare cases that demand user's attention, i.e., code that is almost certainly not correct, like division by 0. We have already documented use cases for .T on 1D arrays, such as compatibility with operations also defined on 2D arrays. I also agree with Alan that probably it's too late to change the behavior of .T for arrays with more than 2-dimensions. NumPy could certainly use a more comprehensive policy around backwards compatibility, but we certainly need to meet a *very* high bar to break backwards compatibility. I am skeptical that the slightly cleaner code facilitated by this new definition for .T would be worth it. > > >> So what is an "in the wild" example of where numpy users create errors >> that pass >> silently because a 1-d array transpose did not behave as expected? >> > > Part of the problem with silent errors is that we typically aren't going > to see them, by definition. The only way you could catch a silent error > like that is if someone noticed the results looked different than they > expected, but that can easily be hidden if the error is a corner case that > is averaged out. That is the whole point of having a warning, to make it > not silent. It reminds me of the old Weisert quote, "As far as we know, > our computer has never had an undetected error." > > The problems I typically encounter is when people write their code > assuming that, for example, a trial will have multiple results. It usually > does, but on occasion it doesn't. This sort of thing usually results in an > error, although it is typically an error far removed from where the problem > actually occurs and is therefor extremely hard to debug. I haven't seen > truly completely silent errors, but again I wouldn't expect to. > > We can't really tell how common this sort of thing is until we actively > check for it. Remember how many silent errors in encoding were caught once > python3 starting enforcing proper encoding/decoding handling? People > insisted encoding was being handled properly with python2, but it wasn't > even in massive, mature projects. People just didn't notice the problems > before because they were silent. > > At the very least, the warning could tell people coming from other > languages why the transpose is doing something different than they expect, > as this is not an uncommon issue on stackoverflow. [1] > > >> Why would the unexpected array shape of the result not alert the user if >> it happens? > > > I think counting on the code to produce an error is really dangerous. I > have seen people do a lot of really bizarre things with their code. > > >> In your favor, Mathematica's `Transpose` raises an error when applied to >> 1d arrays, >> and the Mma designs are usually carefully considered. > > > Yes, numpy is really the outlier here in making this a silent no-op. > MATLAB, Julia, R, and SAS all transpose vectors, coercing them to matrices > if needed. Again, I don't think we should change how the transpose works, > it is too late for that. But I do think that people should be warned about > it. > > [1] https://stackoverflow.com/search?q=numpy+transpose+vector (not all of > these are relevant, but there are a bunch on there) > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
