-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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.
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
broadcast should treat types as "scalar-like" #16966
Comments
I don't like this behaviour at all. This will be terribly incompatible with Why not something like
so we can explicitly do |
I don't like using the |
But |
@TotalVerb |
Isn't it better for that to throw an error than to return 3? |
Why would it return |
Because |
But I don't think anybody argued that tuples should be treated as scalars. |
Then what should be treated as a scalar? This is not clear cut. What is a scalar sometimes is not a scalar other times. For instance, are strings scalars? What should Are sets scalars? What of My point is that whether something is a scalar or not is not a property of the type. Any division of types into "scalar" and "tensor" is going to be inaccurate in some cases. In |
Unfortunately, we don't have traits yet, but there's a section of the manual about collections, and everything listed there shouldn't be treated as a scalar: basically, everything that supports the iteration protocol or |
There's a pretty solid argument to be made for making strings scalar and requiring |
Could someone triage this? I.e. assign some labels and maybe a milestone to this? #16986 seems to solve this, but neither one is assigned any label/milestone, so probably both are being missed in any release planning process. |
What label do you propose? I don't think this is release-blocking. |
Definitely not release blocking, I'd say. The current system of labels and milestones used in the repo is a bit of a mystery to me, so hard to tell what it should get assigned, but not having anything seems not ideal for something that is actively being worked on and therefor might go into a 0.5 release or not. |
It would be nice to get this resolved for #16285, because in Julia 0.6 we were planning to make My first inclination is that |
I don't think that we necessarily want |
That seems like a solid distinction to me and well expressed. |
Would it be crazy to propose an alternative to |
I quite like using a binary operator for map in my code (usually a variant of the compose circle). I don't think we need more dot-like syntax. |
I'm just thinking that slightly expanding this broadcasting idea to a few other operators could lead to some really slick notation not just for mapping, but also for doing embarrassingly parallel/multithreaded operations if combined with some ideas from #17887. Running out of characters that would look nice, but a version of |
@ChrisRackauckas, I agree; see the discussion at the end of #16285. The trick is getting the details right. |
Closed by #16986 (@pabloferz), I believe. |
Once #4883 is fixed, this would enable things like:
These would be super handy when one is e.g. converting types of a DataFrame etc.
The text was updated successfully, but these errors were encountered: