Ha, so some of the tests depended on the old behaviour of silently making array of things. I'll fix the tests...

@pytorchbot retest this please

A much more elaborate way might be to make the array priority of new tensors configurable (easy) and possibly even give calculation results the max of the inputs (quite invasive).

Thanks for the note @ssnl. I'll unapprove for now until I understand it better.

Ha, so some of the tests depended on the old behaviour of silently making array of things.

@t-vi Do you know exactly what happened here?

So we passed a tensor to scipy.stat.binom.
Previously, that would be cast to an array whenever a binary operator with an array was used.
Now things become tensors in these cases - except when we define the op, as is the case for "&".
So some check failed because it passed an array to scipy and that tried "array & tensor".

Now if you look at https://github.com/scipy/scipy/blob/master/scipy/stats/_distn_infrastructure.py, you see that most functions use asarray on their inputs. Apparently we managed to hit one that doesn't. However, it seems that that not using asarray is considered a scipy bug - the latest commit is from June and changes that for a particular instance with a comment indicating that it is considered a bugfix.

So in the the spectrum of "mixing non-tensor and tensor" you could have these options

• depend on who's left and right of a binary op (current behaviour - but highly inconsistent),
• always yield to the other, (setting a strongly negative array_priority),
• return a tensor for scalar + tensor but an array for array + tensor (setting a slightly negative array priority),
• always return a tensor (setting a positive array priority - this is what this patch does).

That means that functions who didn't use asarray and relied on some binary op doing an implicit conversion and actually need an array now fail.

So in summary, I'm not terribly worried about the backwards compatibility - it was more than fragile before - if scipy decided to do a * b instead of b * a somewhere, code would suddenly fail. In fact, I think any consistent behaviour would be better, setting a positive array_priority just is PyTorch vanity. ;)