Julia: Make 3x broadcasting

Created on 8 Dec 2016  路  16Comments  路  Source: JuliaLang/julia

One of the really nice things about julia is the way you can write expressions in ways that look like regular math (eg x=3y+5z). This currently gets turned into x=3*y+5*z. This is great when y and z are scalar, but when they are array's, it would make more sense for this to be translated to x=3.*y+5.*z. This would allow everything to be fused, and in general look nicer.

Most helpful comment

I think we opted not to do this. The @. macro means that you can write @. 3x+5y and it will change it to 3 .* x .+ 5 .* y for you.

All 16 comments

This isn't legal.

what does that mean?

And we pick the dot syntax exactly because we don't want to and cannot do this. (Not at parser level and hard in optimization)

what other way is there to interpret number*array?

You don't know that it's number * array.

There are a lot of times when you do. I am only asking for an optimization when the number is a literal in the code and the variable is in a function and has type info known.

You never know this at syntax level which is when the "translation" (lowering) happens. Therefore, it's a very hard optimization in inference that doesn't worth doing anymore.

And I said it's not worth doing since it's harder to implement, less reliable (effectively bring back the issue of having a set of blessed vectorized functions and not being able to extend the set) and we (will soon) have a more reliable alternative and doing this will encourage people to write code in the wrong way.

For the context of @oscardssmith's question, please see https://github.com/JuliaLang/julia/issues/13603#issuecomment-265780149 where @stevengj states

For the specific case of numeric literal juxtaposition ala 3x, it would be possible to parse that as 3 .* x rather than 3 * x. I actually experimented with that in #17623 but reverted it to be conservative. It is still something that we can consider, but I would make it separate from #17623.

does something bad happen if we broadcast multiplication onto scalars? If not, it seems to me that we could just say 3x=broadcast(*,3,x) (no matter what x is), which would fix the problem.

It always works like that and it has nothing to do with fusion.

@yuyichao, the basic question here is whether 3x is parsed as 3*x (the current behavior, non-fusing) or 3 .* x (possible behavior, would be fusing after #17623). See the patch and discussion at https://github.com/JuliaLang/julia/pull/17623/commits/3638e9301e1fba203358ea0b05d64af7523d3f57

Also new broadcast methods for sparse et al. Should remove most of the objections raised then.

... OK. sure. I'm not really sure if it's a good idea (it is indeed a distinct syntax but it's less explicit that the user actually want broadcasting/fusion) but that should be possible to implement.

The mentioning of "array vs scalar" at all in the original post was very confusing....

I think we opted not to do this. The @. macro means that you can write @. 3x+5y and it will change it to 3 .* x .+ 5 .* y for you.

I agree that this makes little sense, especially in light of the decision to make linear algebra the default.

Was this page helpful?
0 / 5 - 0 ratings