-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
bitarray indexing: sync with array + refactor
* Use setindex_shape_check and DimensionMismatch instead of generic errors; this (and a couple of extra minor fixes) makes BitArrays behave like Arrays (again) * Move portions of the indexing code to multidimensional.jl * Restrict signatures so as to avoid to_index and convert, then create very generic methods which do the conversion and the dispatch: this greatly simplifies the logic and removes most of the need for disambiguation. Should also improve code generation.
- Loading branch information
1 parent
793d769
commit 2fb9bad
Showing
3 changed files
with
142 additions
and
285 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
2fb9bad
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@timholy : this is another 140 lines less thanks to cartesian magic! However, there is a performance issue: multi-dimensional indexing used to be inlined (by hand) until 4 dimensions in the previous code, while in this version
@ngenerate
takes care of that. The result is that performance is on par with the previous version up untilCARTESIAN_DIMS+1
, after which it drops horribly and gets much worse than the previous varargs version.Can
CARTESIAN_DIMS
be increased then, like it says in the comment after its definition? Otherwise I'm hesitant to introduce performance regressions, even though it's likely for an uncommon case. I've tested with 4 and everything seems fine.2fb9bad
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool!
Yes, that was the plan. First, I probably need a more generic fix to an unanticipated problem with
@ngenerate
: the problem is that once you switch over to theDict
wrapper, it loses return-type information---return values you specify in the function definition get buried inside thelocal _F_
and don't get propagated out. As a quick hack, I just wrapped usages with another function (as Jeff suggested), but you have to write one such wrapper for each explicitly-generated dimension (plus the one that matters, the generic version). This means that you have to alter more than justCARTESIAN_DIMS
when you make changes.A better fix might be to add a variant that allows you to specify the return args or types to the macro,
@ngenerate ITERSYM RETURNTYPES FUNCTION
. Here's an example (EDITed to concretely specifytypeof(dst)
rather thanAbstractArray{T,N}
):which would add type information to the output of the cached function, e.g.
(When I first started writing this, my idea was to specify
dst
as the return expression and have the macro insert it in appropriate places. We could do that, but I like this better. Ideas frequently improve as you explain them!)Sound reasonable? If so, should we require that people specify the return type? Or should we allow either the two-argument or three-argument version? Making it required would prevent one from using Cartesian in contexts in which return type cannot be specified at compile time, but perhaps that's not a terrible restriction.
2fb9bad
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess since people can write
Any
for the return-type expression, I'm leaning towards supporting just the 3-argument version. That means existing usages would have to be changed.2fb9bad
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with adding a return type with whatever syntax (after all it's an internal API) and with making it mandatory. I'll update this branch and merge it when this happens.
For the future, do you think it will be possible to leverage the inference machinery and add the return type automatically?
2fb9bad
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps, but I think the right way to solve this problem is to get away from having to maintain our own "shadow method table." Not only would that solve the type problem, it would also eliminate the performance problem you saw when you got to
CARTESIAN_DIMS+1
. Something like alatefunction
(#5536) is needed.