Dotp vs Rdotp confusion

support
Dotp vs Rdotp confusion jfoe  2019-01-25
 

Dear skyline team,

I have read up on dotp vs rdotp.
For some reason though, the rdotp is almost always much higher in my assays.

I have attached a picture of my issue.
The top row is for the analyte peptide.
The bottom row for the heavy reference.
The Library entries in both rows should be the same.

Why is the rdotp so much better than the dotp for the analyte?
This doesn't make sense to me because the reference seems to be basically identical to the library.

This is my understanding so far:

dotp - between product peak areas and the corresponding intensities in a library spectrum
rdotp - between analyte peak areas and reference standard peak areas (e.g. light to heavy)

What I would conclude then is that if for any given peptide and its heavy reference peptide:
Both peptides use the same library entry for the dotp comparison.
If the dotp of heavy standard to library is 1, then dotp = rdotp.

Your help would be much appreciated!

 
 
Brendan MacLean responded:  2019-01-25

Doh! Nice catch. The reason is just that rdotp is a true dot-product (https://en.wikipedia.org/wiki/Dot_product), which is how dotp and idotp started out, but they are now spectrum contrast angles (https://www.ncbi.nlm.nih.gov/pubmed/24623587), as has been mentioned before on this support board, thanks to the work of Umut Toprak and Ludovic Gillet.

In Skyline, the difference is contained in two functions Statistics.Angle() and Statistics.NormalizedContrastAngleSqrt(). Actually, I think dotp and idotp were originally calculated using Statistics.AngleSqrt(). Anyway, I believe they had both moved to NormalizedContrastAngleSqrt() before rdotp was implemented but I didn't code review rdotp closely enough, and it always seemed to make sense that rdotp values should be very close to 1.

As you note, the Angle() method will inflate the values compared to NormalizedContrastAngleSqrt() and make them systematically closer to 1 and also less linearly related to differences (as described in the paper).

Obviously, we should fix this so that all of our dotp values are calculated with the same function.

Thanks for pointing it out.

--Brendan