Open michaelwitting opened 3 years ago
What about a rematchSpectra
function that takes a matchedSpectra
and reprocesses everything or adds an additional similarity score based on a different function.?
Hm, the problem with that is that the MatchedSpectra
supports only a single n:m mapping - if you re-match spectra you will most likely get different matching spectra and you will end up with multiple n:m mappings. That will be tricky to handle and I am afraid that it might also get the user confused.
What about a MatchForwardReverseParam
that matches the query based on the forward score (that's an outer join?) and then calculates and reports also the reverse score (that's a right join?) for the matching spectra and also the number of matching peaks / total number of library peaks? We could get thus everything in one call...
Okay, let's go for MatchForwardReverseParam
.
Just to get it right then:
I would then hard-code these joins into the compareSpectra
calls.
Yes, the forward is an outer join and reverse a right join assuming that the library spectrum is the "right" spectrum. Here are some figure explaining this: http://prime.psc.riken.jp/compms/msdial/download/mathematics/MS-DIAL%20FAQ-vs2.pdf (Slide 21)
Thanks. OK, I will work on that.
And what is left for me? ;-)
adding documentation and unit tests for the matchMz
(or annotateMz
?) functions :)
Let's call it better matchMz
, fitting to the MS2 level.
Tools like MS-Dial state the forward and reverse dot product as well as number of matching peaks / total number of library peaks. Thinking about a function such as
matchSpectra
, I'm wondering if we should do the same? This seems to be standard now. @jorainer Any thougths?