Stream: helpdesk (published)

Topic: Broadcasting generlizability

Chad Scherrer (Mar 07 2021 at 17:48):

I just saw this thread from @Júlio Hoffimann and @Mason Protter :
https://julialang.zulipchat.com/#narrow/stream/274208-helpdesk-%28published%29/topic/broadcast.20without.20length/near/229199757

Starting a new thread here rather than hijack that one :smile:

I have some places that seem like they would conceptually make sense for broadcasting, but I'm not sure about the risk of breaking things.

Abstractly, I think of broadcasting as elementwise operations over different containers. Maybe the first question is whether this is the correct interpretation.

If so,

• We can think of an iterator as a generalization of an array. it1 and it2 may be infinite, but it's still clear what it1 .* it2 means.
• If f and g are functions that take a single Real argument, there's an obvious interpretation of f .* g
• If a and b are distributions or measures, a .* b is the pointwise product of distributions. In terms of the computation, this is very much like what we do when computing a posterior density.

How broadly can we broadcast? How risky is it to extend things like this?

Mason Protter (Mar 07 2021 at 17:57):

I'd agree in all three cases that conceptually broadcast makes sense there. I think at a practical level though, I've heard Matt Bauman express that he thinks it's perhaps a bad idea to get too far away from the current broadcasting semantics because it's useful to have such a uniform interface and meaning

Mason Protter (Mar 07 2021 at 17:58):

That said, only the second of the three really seems problematic to me (since functions f and g can have any number of weird methods)

Mason Protter (Mar 07 2021 at 18:02):

However, If you defined some arrow types in julia (I've called these method wrappers before), you could define e.g.

fm = @method f( ::A, ::B, ::C)
gm = @method g( ::A, ::D)

at which point, I think it might be conceptually meaningful to define

fm .* gm = (a::A, b::B, c::C, d::D) -> fm(a, b, c) * gm(a, d)

Chad Scherrer (Mar 07 2021 at 18:06):

Ooohh, that makes me think of doing something like this on named tuples. Too bad that's off limits

Chad Scherrer (Mar 07 2021 at 18:08):

Which is really weird btw. You can define a wrapper that will act like a named tuple but allow broadcasting etc. So why isn't NamedTuple really just a wrapper that compiles away and has nicer syntax?

Mason Protter (Mar 07 2021 at 18:10):

The language devs couldn't decide on what semantics to assign to broadcast on dicts and named tuples, but didn't want it to hold up 1.0 or whatever, so they made it an explicit error so they could introduce it later in a non-breaking way

Mason Protter (Mar 07 2021 at 18:11):

If broadcast on dicts and named tuples worked, then they wouldn't be able to change the meaning until at least 2.0

Chad Scherrer (Mar 07 2021 at 18:53):

Ok that makes a lot of sense, thanks

Philipp Gabler (Mar 08 2021 at 09:01):

@Chad Scherrer don't you really just want a nice applicative syntax? Or idiom brackets :P

And then, I guess for the dicts/tuple question, it's a similar story why Haskell has separate Applicative instances for [] and Zip.

Last updated: Nov 06 2024 at 04:40 UTC