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

HLL coverage improvements #738

Merged
merged 12 commits into from
Feb 25, 2015
Merged

HLL coverage improvements #738

merged 12 commits into from
Feb 25, 2015

Conversation

luizirber
Copy link
Member

HLL coverage improvements

HyperLogLog line coverage is a bit low because some conditions during estimation are not so easy to trigger. After exposing the HLL internals it was easier to find test cases using data already available for the current tests.

This PR improves the coverage and also simplifies some error checking inside the HLL.

@luizirber luizirber force-pushed the tests/hll_coverage branch 8 times, most recently from ffdb830 to 330c194 Compare January 26, 2015 00:27
@luizirber
Copy link
Member Author

Ready for review @mr-c @ctb @camillescott


PyObject * x = PyList_New(counters.size());
for (size_t i = 0; i < counters.size(); i ) {
PyList_SET_ITEM(x, i, PyLong_FromLong(counters[i]));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was really tempted to use the buffer interface, but I think it is better to do it when implementing #714

@mr-c
Copy link
Contributor

mr-c commented Feb 11, 2015

@luizirber As soon as this is made mergable and #738 (comment) is address I think it will be ready to go

@luizirber luizirber force-pushed the tests/hll_coverage branch 3 times, most recently from df9afea to 4dfca3a Compare February 24, 2015 20:58
@luizirber
Copy link
Member Author

  • Is it mergeable?
  • Did it pass the tests?
  • If it introduces new functionality in scripts/ is it tested?
    Check for code coverage with make clean diff-cover
  • Is it well formatted? Look at make pep8, make diff_pylint_report,
    make cppcheck, and make doc output. Use make format and manual
    fixing as needed.
  • 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.
  • Is it documented in the ChangeLog?
    http://en.wikipedia.org/wiki/Changelog#Format
  • Was a spellchecker run on the source code and documentation after
    changes were made?

@luizirber luizirber force-pushed the tests/hll_coverage branch 2 times, most recently from fed6496 to 2e16872 Compare February 24, 2015 22:07
@luizirber luizirber force-pushed the tests/hll_coverage branch 2 times, most recently from 5fcd005 to 2db412b Compare February 24, 2015 22:32
@luizirber
Copy link
Member Author

Ready for review @mr-c @ctb @camillescott

NULL
},
{NULL} /* Sentinel */
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

khmer/_khmermodule.cc:4611:1: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings] ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, I don't really get where is it coming from. Is it from the sentinel?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get multiple warnings for the same line number so I'm guessing it is all the conversions within the code block.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get multiple warnings for the same line number so I'm guessing it is all
the conversions within the code block.

On Tue, Feb 24, 2015, 19:06 Luiz Irber [email protected] wrote:

In khmer/_khmermodule.cc
#738 (comment):

  • {
  •    (char const *)"ksize",
    
  •    (getter)hllcounter_get_ksize, (setter)hllcounter_set_ksize,
    
  •    (char const *)"k-mer size for this HLL counter."
    
  •    "Can be changed prior to first counting, but becomes read-only after "
    
  •    "that (raising AttributeError)",
    
  •    NULL
    
  • },
  • {
  •    (char const *)"counters",
    
  •    (getter)hllcounter_getcounters, NULL,
    
  •    (char const *)"Read-only internal counters.",
    
  •    NULL
    
  • },
  • {NULL} /* Sentinel */
    };

So, I don't really get where is it coming from. Is it from the sentinel?


Reply to this email directly or view it on GitHub
https://github.com/ged-lab/khmer/pull/738/files#r25306902.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found it, shouldn't have used const.

@mr-c
Copy link
Contributor

mr-c commented Feb 24, 2015

Can you eliminate that warning and cover those last two bits with tests?

Otherwise, it LGTM; I love the output of python -c 'import khmer; help(khmer.HLLCounter)'!

@luizirber
Copy link
Member Author

@mr-c fixed remaining issues

mr-c added a commit that referenced this pull request Feb 25, 2015
@mr-c mr-c merged commit 4ffae39 into master Feb 25, 2015
@mr-c mr-c deleted the tests/hll_coverage branch February 25, 2015 17:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants