Fix docs explaining broadcasting, or change behaviour of min.(1,f)

[dlfivefifty]

The docs state unequivocally that:

More generally, f.(args…) is actually equivalent to broadcast(f, args…)

But, as discussed in

https://discourse.julialang.org/t/should-min-1-f-be-broadcasting-as-broadcast-x-min-1-x-f/5554/14

min.(1,f) is actually equivalent to broadcast(x->min(1,x), f). So either this behaviour should change, or the docs need to be rephrased to, say,

More generally, f.(args…) is typically equivalent to broadcast(f, args…)

[stevengj]

See also #22053 and #18202.

[dlfivefifty]

#22053 seems to hit the screw on its head: for non-Base types, one often wants to use dot-notation to indicate a functional calculus operation deriving from Hadamard .* multiplication (instead of / in addition to standard * multiplication... in the case of ApproxFun, Hadamard and standard * are the same operation), and these type of optimizations make this impossible when it's only implementable for a subset of functions.

My personal suggested solution: only apply these optimizations to Base types, so that other types can still override dot-notation as they desire too. How to handle fusing for other types would be a separate issue (personally, I'd be fine to always auto-fuse and leave it to the user to be careful if they want the special overrides).

[stevengj]

Being restricted to Base types is precisely what we wanted to avoid.

[dlfivefifty]

I'm talking about the treatment of constant literals, not fusing in general

[stevengj]

In what use case would the treatment of constant literals be a problem but general fusing wouldn't? (In you ApproxFun example, where you want to have special-case code for the min of a Fun and a constant, general fusing would defeat your approach also.)

The general philosophy is that . means fusing semantics, and if you don't want this then you should use some other operator. There are plenty to choose from. (Nevertheless, we are planning a way to optionally disable fusing etc. for user-defined types.)

[dlfivefifty]

The issue is not with fusing, its with fusing where the semantics suggest that there should be no fusing at all. It's secretly and misleadingly creating a new function and compiling even though the code as written min.(1,f) is asking it to call `broadcast(min,1,f)

[stevengj]

If you write sin.(min.(α,f)) your specialized method won't be called either. So what practical problem does eliminating the literal-inlining optimization actually solve?

(Sure, the documentation could be clarified.)

[dlfivefifty]

You do if you call

sin(min.(a, g))

The issue it solves is that min(a, g) should not act Point wise according to the docs.

[StefanKarpinski]

It does trouble me that the lowering of broadcast is so seemingly ad hoc. It certainly makes it very hard to explain and I'm a bit worried that it's not terribly future proof. The ideal way to do this is to have broadcast's lowering be fairly simple and uniform and let constant propagation and specialization take care of the rest. However, we don't currently have that level of optimization technology here. Of course, it's not wrong to have some complicated lowering rule as long as we document it and are consistent – it's just kind of messy and hard to reason about.

[yuyichao]

future proof

I think the future proof way is to document clearly that any transformation allowed for Base broadcast are allowed. People that somehow really want to use broadcast as the API can always, well, call broadcast directly.

[StefanKarpinski]

See my last sentence which addressed exactly that – you're not wrong, it's just nasty. It's not generally a terribly good argument for a language design issue since you can use it to justify any design good or bad by saying "well, that's what it's documented to do".

[yuyichao]

I know. I just want to present a slightly different kind of "future proof".

To expand a bit more, I see the dot syntax as an syntax sugar for (de)vectorization rather than a strict mapping to broadcast (after all, it originated from the vectorization issue). Since for calling broadcast you can already just, well call broadcast, I think we don't have to tie another syntax too strictly to boardcast and it is reasonable that we leave more room for future optimization to the dot syntax that won't be possible with broadcast itself.

One example of such an optimization would be for, e.g. sin.(array_1xn) .* cos(array_nx1) one can get (almost) n times speedup by reducing the number of sin/cos evaluation. Of course such optimization is hard and I'm not sure how that can be implemented now. However, I think it's possible to do if we can make use of syntactic information and will be much harder if we have to optimize it as a single boardcast call. It'll be nice if we don't make such an optimization impossible.

[dlfivefifty]

Here's another more serious inconsistency due to this:

julia> (1:3) .+ 1
3-element Array{Int64,1}:
 2
 3
 4

julia> x = 1; (1:3) .+ x
2:4

[dlfivefifty]

Perhaps this could be done in Julia code instead of when parsing? Something like:

@inline broadcast(f, v::Array, k::Number) = broadcast(x->f(x,k), v)

though I don't know if that would inline the constants correctly.