Answers.Body: <p>Cube root transformation is another way to deal with zeros without dropping them.</p>
  
  <pre><code>var^(1/3)
  </code></pre>
  
  <p><strong>EDIT</strong> as Michael pointed out, square root transformation is another--perhaps more common--transformation that leaves zeros as zeros.</p>
  
  <pre><code>sqrt(var)
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-04-18T03:05:19.007Z
Answers.Text: Whilst I don't disagree, normally a square root transformation is used
Answers.UserDisplayName: M__
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-04-17T23:44:48.660Z
Answers.LastActivityDate: 2020-04-18T03:42:07.023Z
Answers.LastEditDate: 2020-04-18T03:42:07.023Z
Answers.UserDisplayName: Obim
Body: <p>I have a <code>data.frame</code> with results from a CRISPR screen.</p>
  
  <p>I want to calculate the % enrichment of a variable of interest <code>var</code> from baseline to treatment group.</p>
  
  <p>Here is the distribution of <code>var</code> in linear:
  <a href="https://i.sstatic.net/cDOXS.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/cDOXS.png" alt="enter image description here"></a></p>
  
  <p>I can do scale <code>var</code> with log transformation
  <a href="https://i.sstatic.net/tzXXW.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/tzXXW.png" alt="enter image description here"></a></p>
  
  <p>But many rows with <code>var</code> = 0 will be lost.
  Moreover, I cannot compare % enrichment by dividing <code>treatmentgroup::var</code> to <code>Control/baseline::var</code> because I will run into the problem of dividing by zero.</p>
  
  <p>I've seen people circumvent this problem by adding a small value ex)0.01 to the entire column of <code>var</code>.
  But I'm wondering if there's a better way of circumventing this problem. For example, a simple transformation that can deal with zeros and negative values.</p>
  
  <p>Appreciate any input!</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-02-26T20:19:10.733Z
Comments.Text: The basic premise that I understand is this: There should not be a zero in your denominator. Zeros in the numerator can be circumvented by pseudocounts, but zero in the denominator indicates some sort of problem in the logic. Also, why are you working on CPMs directly? Why not use a differential expression tool?
Comments.UserDisplayName: Ram RS
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-02-27T04:02:46.507Z
Comments.Text: @RamRS
  Many thanks for the input - I'm a first year graduate student and have never worked with crispr screens. Right now I'm kind of brute forcing and see what I can get. Have you personally worked with any differential expression tool with one that you recommend trying out? And is MAGeCK one of those tools? Thanks so much again, appreciate any guidance!
Comments.UserDisplayName: geom_na
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-02-27T16:47:34.773Z
Comments.Text: I have worked with DESeq2 but I'm not sure if and how it would apply to CRISPR. Does current research in the field use count data for comparison? How does it account for library depth and other experimental factors?
Comments.UserDisplayName: Ram RS
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-02-28T14:47:44.770Z
Comments.Text: @Nomad420 you may want to give a try to MAGeCK as you have mentioned. It accepts count data as input and will make your life easier.
Comments.UserDisplayName: jxx_fa
Tags: <r>
Title: How to deal with zeros in the denominator when calculating percent enrichment?
ThreadText: # How to deal with zeros in the denominator when calculating percent enrichment?
  
  (Asked by: username_0 on 2020-02-26)
  
  I have a `data.frame` with results from a CRISPR screen.
  
  I want to calculate the % enrichment of a variable of interest `var` from baseline to treatment group.
  
  Here is the distribution of `var` in linear:
  [![enter image description here](https://i.sstatic.net/cDOXS.png)](https://i.sstatic.net/cDOXS.png)
  
  I can do scale `var` with log transformation
  [![enter image description here](https://i.sstatic.net/tzXXW.png)](https://i.sstatic.net/tzXXW.png)
  
  But many rows with `var` = 0 will be lost.
  Moreover, I cannot compare % enrichment by dividing `treatmentgroup::var` to `Control/baseline::var` because I will run into the problem of dividing by zero.
  
  I've seen people circumvent this problem by adding a small value ex)0.01 to the entire column of `var`.
  But I'm wondering if there's a better way of circumventing this problem. For example, a simple transformation that can deal with zeros and negative values.
  
  Appreciate any input!
  
  **Tags:** r
  
  > **Comments:**
  > **username_1**: The basic premise that I understand is this: There should not be a zero in your denominator. Zeros in the numerator can be circumvented by pseudocounts, but zero in the denominator indicates some sort of problem in the logic. Also, why are you working on CPMs directly? Why not use a differential expression tool?  
  > **username_0**: @username_1 Many thanks for the input - I'm a first year graduate student and have never worked with crispr screens. Right now I'm kind of brute forcing and see what I can get. Have you personally worked with any differential expression tool with one that you recommend trying out? And is MAGeCK one of those tools? Thanks so much again, appreciate any guidance!  
  > **username_1**: I have worked with DESeq2 but I'm not sure if and how it would apply to CRISPR. Does current research in the field use count data for comparison? How does it account for library depth and other experimental factors?  
  > **username_2**: @Nomad420 you may want to give a try to MAGeCK as you have mentioned. It accepts count data as input and will make your life easier.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2020-04-17. Score: 1
  
  Cube root transformation is another way to deal with zeros without dropping them.
  
  ```
  var^(1/3)
  
  ```
  
  **EDIT** as Michael pointed out, square root transformation is another--perhaps more common--transformation that leaves zeros as zeros.
  
  ```
  sqrt(var)
  
  ```
  
  > **Comments:**
  > **username_4**: Whilst I don't disagree, normally a square root transformation is used  
  
  ---
  
  