Broadcasting tuple functions

[TotalVerb]

After reading several recent questions about divrem and sincos (not in Base) broadcasting on arrays, I think the current situation could be improved. To summarize, the issue arises when trying to compute sin.(A), cos.(A) (where A is a vector) in an efficient way. (minmax, extrema, divrem, fldmod, fldmod1, reim, are similar)

The approach with tmp = sincos.(A); first.(tmp), last.(tmp) is unsatisfactory because it requires an intermediate allocation.

The approach with sin.(A), cos.(A) is unsatisfactory because there may be efficiency gains from computing sin and cos at once. I suspect some of the desire for an unzip function is caused by this problem, which has no convenient solution at the moment, aside from writing out the loop. Thinking about this problem, I have a few proposals.

Proposal A

It may make sense to allow

(sin, cos).(A)

or

broadcast((sin, cos), A)

which returns sin.(A), cos.(A) but perhaps computed more efficiently. (In other words, an "unzipped broadcast".)

However this raises the question about whether sincos(x) and divrem(x, y) themselves might better be called (sin, cos)(x)...

Proposal B

If this syntax is too revolutionary, an alternative is to offer unzip (#13942), along with a way to make the inner broadcast lazy. That is, perhaps we could have

unzip(sincos@.(A))

which expands to

unzip(Broadcast(sincos, A))

where Broadcast is a minimal iterable object which calls broadcast upon collect, but unzip on it can be specialized to avoid the intermediate allocation.

Here I'm proposing @. as an idiom for a lazy broadcast; this has a reasonably nice parallel to @[...] for lazy indexing (i.e. viewing). This approach has the advantage that lazy broadcasts have themselves been a commonly requested feature.

(Now, unzip might itself be reasonably expected to be lazy, so we might wish to require collect(unzip(sincos@.(A))).)

Proposal C

Ideally sin.(A), cos.(A) would be as efficient as computing sincos.(A). It may be possible to intercept this pattern in lowering, and lower the construction of tuples that are broadcast over the same symbol arguments to Base._tuple_broadcast((sin, cos), A) which by default falls back to broadcast(sin, A), broadcast(cos, A), but allows specialization. I don't particularly like this kind of solution, because it does break referential transparency.

[TotalVerb]

Personally I am a fan of proposal B, not least because the other features it would introduce (unzip and lazy Broadcast) are ones that I would want independently, and it is quite nice that they work well in tandem.

[p-zubieta]

Currently you can do

julia> (t::Tuple{F,G}){F,G}(x) = (t[1](x), t[2](x))

julia> (sin, cos)(0)
(0.0,1.0)

julia> (sin, cos).([-1, 0, 1]) # broadcast((sin, cos), [-1,0,1])
3-element Array{Tuple{Float64,Float64},1}:
 (-0.841471,0.540302)
 (0.0,1.0)           
 (0.841471,0.540302)

[TotalVerb]

Right, but that's not the result you'd want. The point of this is to return a tuple of arrays instead of an array of tuples.

[p-zubieta]

Oh, right, I missed the intention of the OP. So the example I gave above is probably a reason not to choose the Proposal A approach.

[StefanKarpinski]

I have to confess I kind of like the idea of tuples being callable by calling each of their components on the given arguments. But I suspect others may not care for that behavior and would prefer that an operator have the effect of "tupling" functions, i.e.

funprod(f::Function, g::Function) = (args...)->(f(args...), g(args...)

Part of the reason this is appealing is that there doesn't seem to be anything else that calling a tuple could sensibly mean and the function which returns the tuple of the result of calling each element of the tuple on a given set of arguments is the correct product in the category of functions.

[spalato]

I agree there should be an efficient and convenient solution for this problem. Some function return multiple values.
I have come up with a solution that is faster than first.(v) and friends. It does not avoid the allocation of an intermediary array of tuples (this is beyond my skills), but makes a single pass.
See: https://github.com/spalato/Destruct.jl
Feel free to steal.

[stevengj]

I like Proposal A, (sin, cos).(A), especially because it requires no modifications to the Julia language, and in fact it could be fully implemented in an external package ("TupleCast"?).

[tpapp]

It would be great to have a syntax which can "unzip" tuples from a single function, eg like sincos in the example. Some calculations return tuples because the results calculated share computation.

[stevengj]

I'm not convinced you need a "syntax" (i.e. language changes) for this.

For example, unzip(sincos).(x) can work today with appropriate library support (unzip(f) would return a special functor object with its own broadcast method), and it is a lot clearer to me than unzip(sincos@.(A)). Similarly for (sin, cos).(A).

It would be great if someone worked on a "TupleCast" package for this sort of thing. It's a fair amount of work only because broadcast is probably the most complicated function in Julia.

[StefanKarpinski]

Of course, if "tuplecasting" is sufficiently successful, it might get inducted into Base, but it's better to experiment with this sort of thing outside of Base first where it won't get set in stone too quickly.