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
Thanks for keeping easyqpcr alive. I recently stumbled over the issue, that even though I was passing the names of reference_genes to calibration_factors, other genes were actually used as reference. I tracked it down to the internal call to normalize_data where there is the hard-coded assumption, that the first columns contain the reference genes:
Thanks for flagging this up, I probably just overlooked that when adapting the code of the original easyqpcr package into the new function. I will take a look at your suggestion and adapt it if I do not see any problem.
Thanks for keeping easyqpcr alive. I recently stumbled over the issue, that even though I was passing the names of
reference_genes
tocalibration_factors
, other genes were actually used as reference. I tracked it down to the internal call tonormalize_data
where there is the hard-coded assumption, that the first columns contain the reference genes:easyqpcr2/R/calibration_factors.R
Lines 127 to 129 in 4810ba6
This assumption is not communicated in the documentation
easyqpcr2/R/calibration_factors.R
Lines 15 to 16 in 4810ba6
The problem is, that this implementation does not produce errors, but rather works in an unexpected way.
I added this line to
calibration_factors
to actually get the reference genes positions and pass them tonormalize_data
:The text was updated successfully, but these errors were encountered: