Constrain acset hom search to specified subsets

[kris-brown]

This constraint allows one to say, e.g. when searching for maps from the path graph with two edges into some big graph, that V2 must be sent to either vertex 2, 5, or 6 in the codomain, and that E1 must be sent to edge 3 or 7 in the codomain, etc. I.e. we have the option to restrict valid assignments to an arbitrary subset of the codomain for each part in the domain.

This is a required feature for my implementation of incremental hom search.

This is technically a generalization of the initial keyword argument, which would be valid assigning a singleton set to some part of the domain. However, the way that case is treated (immediately beginning hom search with that assignment) is very different from the general case (a check when making an assignment arbitrarily deep in the tree), so it's helpful to be able to declare these separately.

[epatters]

Thanks Kris! Since in the end the implementation just adds an extra predicate to check, it might be cleaner and slightly more flexible to call the keyword argument predicates and have it take a dict of dicts of arbitrary predicates (boolean-valued Julia functions). Then to recover the current behavior, you pass the lambda x -> x ∈ my_set. What do you think?

[kris-brown]

Yeah I like this idea a lot!

[kris-brown]

Hm on second thought, can we think of any properties other than the simple subset relation that make sense? It seems like you'll always be able to determine the relevant subset before you run the hom search. There's no useful data at runtime (even if you were to throw the current BacktrackingState into the predicate, you have no idea what order the parts are being traversed in) so it's hard to think of a reasonable predicate).

[epatters]

I agree that in practice this will at most save you a coercion to a set since the input data is finitary, but it might still be nice to not insist on a single data type. Your call.

[kris-brown]

It feels nicer whenever we can get away with passing around data rather than functions, and I figured the coercion to Set is a good thing since we enforce O(1) lookup (rather than predicate= i -> i in [1,3,4]). That said I do feel like the word predicate is more clear than valid, even for just giving a subset.

[kris-brown]

The Set coercion is allowing the user to pass in any AbstractVector at least, right? Or they could write a Set(::MyStruct) method.

[epatters]

I'm on board with changing the keyword arg to predicate and keeping the rest the same: it's forward-proof in case requiring a Set is later found to be too constraining.