-
Notifications
You must be signed in to change notification settings - Fork 21
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
Additional construction/coercion methods for cytoframe #348
Comments
@jacobpwagner, sorry for bugging you again. I have been experiencing some issues with current coercion workaround, I seem to be getting very different results depending on how many The first issue occurs when you try to coerce a transformed
Interestingly, the same is not observed when you try to coerce a
I know that you working on this at the moment, but is there a way that I can get consistent results with the current workaround? |
Thanks @DillonHammill . It does appear that something is wrong in handling the annotated parameter ranges, particularly during
|
It also appears to be a problem particular to reading back in via Lines 726 to 730 in 4a6883a
But if we follow that some logic but read back in to another
|
Regarding the range discrepancy between For Whereas for This is similar to the logic @mikejiang , if you have time, a second set of eyes here could be good to determine what the appropriate behavior should be to synchronize both parsers to. It also underscores the need to switch over to having |
First:
It would be good to support R-level construction of
cytoframe
objects just taking a matrix as is possible forflowFrame
. For example:Works
Not yet supported:
The current workaround is to construct the
flowFrame
and then convert it tocytoframe
usingflowFrame_to_cytoframe
, but that is a little inefficient as it goes through an I/O intermediate. Even if that is the quick solution we go with under the hood, the usage ofcytoframe
shouldn't require the user falling back to aflowFrame
.Second:
It would be good to make a
cytoset_to_cytoframe
method along the lines of theflowCore
method for coercing aflowSet
to a singleflowFrame
by doing some consistency checks before binding event rows into a single matrix. This pooling of events is often performed before running dimension reduction or clustering algorithms. You can see the need for this in other packages where users have made their own functions, likeflowSOM::AggregateFlowFrames
. @DillonHammill also gave a good summary of how it would be helpful. This will require some extra care to do consistency checks properly for the resultingcytoframe
and we should discuss how to handle any potential extra/missing channels. Perhaps those consistency checks should just be handled before this bycytoqc
and ifcytoset_to_cytoframe
detects an inconsistency should just stop and direct users tocytoqc
.The current workaround here is a chain of coercions (
cytoset
->flowSet
->flowFrame
->cytoframe
), which is inefficient and a lot to ask of users to hack together each time.The text was updated successfully, but these errors were encountered: