As described in the article and requested in recent issue #7, add variants of all the distances that take parameters to define what pairs of (T,Y) to check between the two graphs.
This PR introduces 3 new functions in the python API:
ancestor_aid_selected_pairs
parent_aid_selected_pairs
oset_aid_selected_pairs
(naming TBD)
They take the same arguments as their shorter-named relatives, plus two additional ones:
parent_aid_selected_pairs (
g_true: adjacency matrix
g_guess: adjacency matrix,
treatments: list of nodes, *new*
effects: list of nodes, *new*
edge_direction: string,
) -> (float, int)
The pairs for which mistakes are counted are taken from
(T, Y) $\in$ treatments $\times$ effects
We then redefine parent_aid as a special case of parent_aid_selected_pairs (new addition), where parent_aid will now have the t_y_pairs_to_grade argument set to [all pairs] by default.
In summary, the python interface can now take two lists of T and Y, from which the cartesian product will provide the pairs to grade, while in Rust one can supply a fully custom list of pairs, say [(1,2), (2,3)].
As described in the article and requested in recent issue #7, add variants of all the distances that take parameters to define what pairs of (T,Y) to check between the two graphs.
This PR introduces 3 new functions in the python API:
ancestor_aid_selected_pairs
parent_aid_selected_pairs
oset_aid_selected_pairs
(naming TBD)
They take the same arguments as their shorter-named relatives, plus two additional ones:
The pairs for which mistakes are counted are taken from
(T, Y) $\in$
treatments
$\times$effects
We then redefine
parent_aid
as a special case ofparent_aid_selected_pairs
(new addition), whereparent_aid
will now have thet_y_pairs_to_grade
argument set to[all pairs]
by default.In summary, the python interface can now take two lists of
T
andY
, from which the cartesian product will provide the pairs to grade, while in Rust one can supply a fully custom list of pairs, say [(1,2), (2,3)].