fix fallback for scaling blas number with array #17739
Conversation
| @@ -18,6 +20,8 @@ function scale!{T<:BlasFloat}(X::Array{T}, s::T) | |||
| X | |||
| end | |||
|
|
|||
| scale!{T<:BlasFloat}(s::T, X::Array{T}) = scale!(X, s) | |||
There was a problem hiding this comment.
why does this method exist? really strange to be sometimes mutating the second input, but usually the first
There was a problem hiding this comment.
Perhaps to be symmetric like multiplication?
There was a problem hiding this comment.
Because multiplication is not always commutative.
There was a problem hiding this comment.
I also thought it was weird. I guess it is there for non commutative numbers in the general case.
Edit: Beaten to the punch
There was a problem hiding this comment.
mutating methods need to be consistent about what they're mutating.
There was a problem hiding this comment.
No they don't. We don't agree here and for those of us who use this method, it doesn't cause trouble.
There was a problem hiding this comment.
It's mutating the array, whichever argument that is.
There was a problem hiding this comment.
Added to #16772. Being explicit with 3 arguments seems like a much more predictable API when you're writing generic code that has to deal with various combinations of input types.
|
Apple seemed to got stuck on something unrelated. Since this should be fairly uncontroversial I'm gonna click the scary button for the first time. 🎉 |
Also adds a fast path for special case of zero and one.
#17716 (comment)