-
-
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
broadcasting over arrays of small unions #27106
Comments
This mixes two different issues:
The former is chosen using Whether inference should be more precise is a completely different question, which fortunately can be changed at any point without breaking code: it's just a matter of finding the best threshold for performance. |
Isn't Line 643 in 1b92f51
determining the element type of the result? Edit: Oh, that's only when the returnt ype is concrete? |
AFAIK inference is supposed to be used only when the result is empty. But indeed the result of |
@nalimilan is absolutely right! This is a perfect example of the problem with |
Where do you see or observe this? We only use the return type if it is concrete or if the result is empty. We are still doing it poorly in the sparse broadcast code, but that's the only place I'm aware broadcast does this incorrectly. Lines 762 to 766 in 1b92f51
|
@KristofferC noticed when the number of elements in the union goes over two, inference falls back to Any.
Working with vectors, matrices and arrays of elements typed as a Union of 2, 3, or 4 leaf types has become very fast thanks to much work. The fact that, at the moment, broadcasting fails to autogenerate arrays that match the source's type (array of 3 or 4 unioned leaf types) leaves a lot of low hanging fruit on the vine.
For example, a data vectors designed to handle
Float64
andInt64
values (perhaps with sort of source) which support missing values requiresUnion{Missing, Int64, Float64}
. All the machinery seems present.The text was updated successfully, but these errors were encountered: