Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Define broadcast[!] in Base, and import/extend in module Broadcast? #18462

Closed
Sacha0 opened this issue Sep 12, 2016 · 5 comments
Closed

Define broadcast[!] in Base, and import/extend in module Broadcast? #18462

Sacha0 opened this issue Sep 12, 2016 · 5 comments
Labels
broadcast Applying a function over a collection

Comments

@Sacha0
Copy link
Member

Sacha0 commented Sep 12, 2016

The module Broadcast defines and exports broadcast[!], and Base importalls Broadcast in sysimg.jl. This arrangement makes defining broadcast[!] methods prior to that point in sysimg.jl impossible (as importall'ing Broadcast then throws an existing-identifier-conflict warning for / does not import broadcast[!] from Broadcast). Simultaneously, Broadcast's import in sysimg.jl can only happen so early (and only later than some existing vectorized function definitions that should transition to compact broadcast syntax, which is how I ran into this).

Instead, should Base define broadcast[!], and Broadcast import/extend broadcast[!] from Base? Better solutions? Thanks and best!
@yuyichao
Copy link
Contributor

Use case? I think we can certainly do so if there's need for it.

@Sacha0
Copy link
Member Author

Sacha0 commented Sep 12, 2016

Use case?

I ran into this while transitioning vectorized float methods to compact broadcast syntax. Those float methods live in float.jl, which sysimg.jl includes prior to where broadcast.jl can be included / Broadcast imported.

@Sacha0
Copy link
Member Author

Sacha0 commented Sep 12, 2016

What would be the best approach? Is naively including function broadcast[!] end directly in Base and early in the sysimg.jl hierarchy the correct approach? If so, does an appropriate location for such definitions exist? Thanks!

@kshyatt kshyatt added the broadcast Applying a function over a collection label Sep 13, 2016
This was referenced Sep 13, 2016
Closed
Closed
Closed
@stevengj
Copy link
Member

#17623 implements exactly this, so it should close this issue eventually if we don't do it sooner.

@stevengj
Copy link
Member

(Though it doesn't implement broadcast! in Base.)

@Sacha0 Sacha0 mentioned this issue Dec 13, 2016
Merged
10 tasks
stevengj added a commit to stevengj/julia that referenced this issue Dec 13, 2016
@stevengj
define broadcast! earlier (fixes JuliaLang#18462)
9984deb
stevengj added a commit to stevengj/julia that referenced this issue Dec 14, 2016
@stevengj
define broadcast! earlier (fixes JuliaLang#18462)
446fd1a
stevengj added a commit to stevengj/julia that referenced this issue Dec 18, 2016
@stevengj
treat dot operators as dot calls, e.g. x .+ y --> (+).(x,y)
2c4e353 
syntax deprecation for .op method definitions, and removed these deprecations from Base

use range + 1, not range .+ 1, to make sure we call the specialized + method that produces a range (not an array)

add depwarn for using .+ etc as function objects

support dotted pipe operators

eliminate most broadcast(::typeof(func), ...) methods, since fusion makes them ~useless; make broadcast produce a BitArray if a Bool array is expected

test for .op loop fusion

docs for new broadcasting dot-operator behavior

define broadcast! earlier (fixes JuliaLang#18462)

use specialized code for non-fusing array ± scalar, for performance

work around slight slowdown in Diagonal due to broadcast vs. broadcast_elwise_op

closes JuliaLang#11053
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
broadcast Applying a function over a collection
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@yuyichao @kshyatt @stevengj @Sacha0