problem with the recent change in the way rdotp is calculated Antoine  2022-09-01 09:25

Hello Skyline team,

The recent change in the way the rdotp is calculated since Skyline v21.2 Released on 1/4/2022 causes us big troubles with data integrity.
We already published papers that used this value as a filter for the identification of the endogenous peptides. We are currently in a process of a publication and we cannot upload the Skyline files on a public repository because the rdotp values are not the same between the manuscript and the skyline file.

Could you at best re-introduce the original rdotp in skyline, or at least provide a way to convert the new values to the old values? This is really problematic for publication.



Nick Shulman responded:  2022-09-01 10:38
The formula to convert between the old dot product value and the new dot product value is:
newDotProduct = 1 - arccos(oldDotProduct)*2/pi
and the inverse formula is:
oldDotProduct = cos((1 - newDotProduct)*pi/2)

If you need to install an old version of Skyline you can find them after clicking the "Archive" link on the "unplugged" installer page:

In older versions of Skyline, the ratio dot product was the simple normalized dot product of two vectors (A dot B) / (|A| * |B|).
In Skyline 21.2, we switched so that the above formula is applied, in order to be consistent with all of the other dot products in Skyline.

Does this help?
I could imagine that we might be able to add additional columns to the Document Grid which would allow you to see the ratio dot product calculated the old way, or maybe there could be a document setting somewhere. I don't think any feature like that could be added to Skyline soon enough to be of use to you now.
-- Nick
Antoine responded:  2022-09-02 00:59
Thank you Nick,

It helps, I can convert the values.

If I may comment, I think it is not the best idea to change the calculation and keep the same variable name, at least for consistency with the already published datasets.
So the possibility to have the 2 calculations in the document grid and report would be valuable.
Best regards
Antoine responded:  2022-09-06 06:42

I don't get the right results with the formula.
I attached an example in Excel, I also provided the individual area of the transitions.

Nick Shulman responded:  2022-09-06 08:21
Can you send me your Skyline document?

In Skyline you can use the menu item:
File > Share
to create a .zip file containing your Skyline document and supporting files.

If that .zip file is less than 50MB you can attach it to this support request.
You can upload larger files here:

-- Nick
Antoine responded:  2022-09-07 02:02
Hi Nick,

It was saved with skyline v21.1.0.278 the rdotp or light to heavy dotp is : 0.9983

When opened with Skyline v21.2.0.568, it gives me 0.9813
Nick Shulman responded:  2022-09-07 08:25
Oops. I was mistaken. There is no formula to convert between the old ratio dot product and the new ratio dot product.
The new dot product is calculated using the square roots of the transition peak areas, whereas the old dot product used the actual transition peak areas.

One thing that you could potentially do is add an annotation which will store the old dot product value. That annotation would apply to "Precursor Results". You would use the Document Grid in an older version of Skyline to copy the old dot product values from their value column into the new annotation column. Then, when someone opens your document using a new version of Skyline, there would be an annotation in there which showed what the ratio dot product value used to be.

We also could potentially add a new column to the Document Grid which would show you the original dot product value. I would have to ask around to see whether it is feasible to add a column like that.

Sorry about leading you down the wrong path. I completely missed seeing the square root function call when I was looking at the new dot product code.

The new dot product code comes from this method called "NormalizedAngleSqrt":
and the old dot product code came from this method "Angle":
-- Nick
Brendan MacLean responded:  2022-09-08 13:17
If I may weigh in, the way the old rdotp value was calculated was a mistake. It was overly optimistic and different from the other dotp values in Skyline ("dotp" and "idotp"), which already switched to NormalizedAngleSqrt() in Skyline v1.4 (from AngleSqrt() in v1.3) in late 2012.

Here is a paper that was the basis for the way we now calculate "dotp" values in Skyline (which are actually "Normalized Spectrum Contrast Angles"):

In 2012, we had recently introduced MS1 filtering (chromatogram extraction) and users were finding AngleSqrt() did not seem to provide sufficiently different values between a highly matching isotope distribution and one that did not match so well. Even before that, the author of the original BiblioSpec paper (, Barbara Frewen, insisted that using the square root normalization was critical to making useful comparisons between spectral intensities.

So, just now realizing that the RatioValue implementation used simply Angle() on the intensities makes it seem even more broken than I had believed.

I did put off making this change for exactly the reason you highlight. People were using the original value, as broken, overoptimistic, and inconsistent as it was from every other place in our code where Skyline professes to have a "dotp" value.

As in 2012, I finally just made the change. Definitely, sorry it has caused you pain, but the old name "rdotp" carried with it assumptions that were not actually true, i.e. that it was the same spectrum comparison function as "dotp" and "idotp".

I hope we can help you recover. You always have the option of simply reporting the version of Skyline you used, and I am sure that version will produce the rdotp values you are reporting.

Thanks for taking the time to post to this support board and share your feedback.

Antoine responded:  2022-09-09 01:56
Thank you Brendan for the insight.

It is always a good move to improve the peak picking and filtering algorithms of Skyline.
I confirm that the version 21.1 of Skyline reports properly the old rdotp values.

I found that with a threshold set high enough (0.98), the old rdotp did actually a pretty good job to remove false positives (i.e. noise) and to detect most peaks with interfered transitions. It has a good synergy with others metrics like RT, mass error, etc... for filtering PRM datasets.

I will have to set a good acceptance threshold with the new rdotp for my future datasets.