You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, there's a bit of asymmetry in terms of the way that query and result tracks behave with respect to their bounds. A result track extent is "greedy" in the sense that it will be extended to include genes belonging to families considered matchable, while query track(s) have fixed boundaries based on the neighborhood parameter. This can lead to some potentially misleading results, suggestive of copy number variation on the edges of tracks (as in an example which I thought I had open in one of many browser tabs, but it's not coming to hand- will update this issue if I find it or an equivalent example later). It seems as though the new architecture might facilitate this since the query tracks should be easily extendable without needing to make this a server-side decision?
The text was updated successfully, but these errors were encountered:
Is this the same as issue #77? If so, you've been waiting a long time for this feature!
I think this is tricky because it's sort of a chicken-and-egg thing; query tracks would be extended in the context of their cluster but the family content of the extended tracks could change the clustering. I suppose if we used a two pass strategy (as you describe in the other issue) we could just cluster again.
Perhaps the thing to do is come up with a few examples where this feature would be useful. As is, I don't feel like I'm completely grasping it. That said, I can't help but think about graphs for this problem.
Yes, it's related to #77 but differs slightly (perhaps insignificantly) in that #77 pertains only to the query tracks and their relationships, whereas this one pertains to the relationship between queries and result tracks. This isn't urgent, I was just getting it into an issue before I forgot about it. But, I will definitely try to re-find my example or come up with a new one.
Currently, there's a bit of asymmetry in terms of the way that query and result tracks behave with respect to their bounds. A result track extent is "greedy" in the sense that it will be extended to include genes belonging to families considered matchable, while query track(s) have fixed boundaries based on the neighborhood parameter. This can lead to some potentially misleading results, suggestive of copy number variation on the edges of tracks (as in an example which I thought I had open in one of many browser tabs, but it's not coming to hand- will update this issue if I find it or an equivalent example later). It seems as though the new architecture might facilitate this since the query tracks should be easily extendable without needing to make this a server-side decision?
The text was updated successfully, but these errors were encountered: