Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • vidjil vidjil
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,700
    • Issues 1,700
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 97
    • Merge requests 97
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • vidjil
  • vidjilvidjil
  • Issues
  • #2656
Closed
Open
Created Sep 20, 2017 by Mathieu Giraud@magiraudOwner

Central region : couper en deux pour ne pas pénaliser deux fois

Dans 2e23e720, j'avais écrit :

A more exact option could have been to use something like (first_pos_max + last_pos_max / 2) + getS()/2, but it would raise symmetry problems. The selected option should anyway improve the estimation in most of the cases.

Je pense que ce qui me chiffonait pour la symétrie, c'était qu'doit être invariant aux reads rev-compés. Prendre la position (first_pos_max + last_pos_max) / 2 n'est pas reproductible. Mais il suffit de dépasser d'un nucléotide quand c'est impair, et plus de soucis. On comptera dans ce cas une position deux fois, mais ce sera mieux que toute la zone centrale comptée deux fois.

Voir aussi #1878.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking