Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] save full signature in SBT leaves #366

Closed
wants to merge 5 commits into from
Closed

[WIP] save full signature in SBT leaves #366

wants to merge 5 commits into from

Conversation

luizirber
Copy link
Member

Fixes #198

  • Is it mergeable?
  • make test Did it pass the tests?
  • make coverage Is the new code covered?
  • Did it change the command-line interface? Only additions are allowed
    without a major version increment. Changing file formats also requires a
    major version number increment.
  • Was a spellchecker run on the source code and documentation after
    changes were made?

@codecov-io
Copy link

codecov-io commented Nov 3, 2017

Codecov Report

Merging #366 into master will increase coverage by 0.06%.
The diff coverage is 94.06%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #366      +/-   ##
==========================================
+ Coverage   90.75%   90.82%   +0.06%     
==========================================
  Files          33       33              
  Lines        5010     5091      +81     
  Branches       36       36              
==========================================
+ Hits         4547     4624      +77     
- Misses        463      467       +4
Impacted Files Coverage Δ
sourmash/search.py 93.02% <100%> (+0.1%) ⬆️
sourmash/sbt.py 85.62% <100%> (+0.02%) ⬆️
tests/test_sbt.py 98.94% <100%> (+0.09%) ⬆️
sourmash/sourmash_args.py 93.05% <86.66%> (-2.26%) ⬇️
sourmash/commands.py 91.91% <92.3%> (+0.33%) ⬆️
sourmash/sbtmh.py 88.38% <94.28%> (+1.52%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 988459c...a15ab81. Read the comment docs.

@luizirber
Copy link
Member Author

I'm revisiting this and some comments.

I'm getting the tree ksize from the root node (I'm initializing the BFs with a real ksize instead of using 1), but the best solution seems to be to keep both scaled and ksize as a property of the tree (NOT the root node!), and maybe even as a list. Why?

  • once we have a tree structure, we can reuse it for other ksizes (but need to recalculate the internal nodes)
  • it's a good way of knowing what other trees we can build with the same leaves (instead of having to go thru all the leaves and accumulating what ksizes and scaled values are available)

there is still a bunch of TODO here, so don't merge!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants