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

Some minor changes and fixups #77

Merged
merged 4 commits into from
Nov 4, 2016
Merged

Conversation

n1tehawk
Copy link
Contributor

  • be clearer on M.EPSILON
  • whitespace and code formatting
  • remove some unnecessary code from _is_table_equals()
  • update AppVeyor to use Lua 5.3.3

Also:
- Set it to the actual machine epsilon, not twice the value.
  (i.e.: be more strict/picky on rounding errors in almostEquals)
- Move EPSILON to top of file, make clear it's now a configuration
  var (user may assign to M.EPSILON)
@n1tehawk
Copy link
Contributor Author

Somehow github's CI integration hooks didn't pick up on this PR. I'll try to force-push my branch to get it to 'catch up' again...

@n1tehawk n1tehawk force-pushed the contrib branch 2 times, most recently from 376c181 to 743f82e Compare October 21, 2016 13:10
@coveralls
Copy link

coveralls commented Oct 21, 2016

Coverage Status

Coverage increased (+0.0003%) to 99.824% when pulling 743f82e on n1tehawk:contrib into 9d00f65 on bluebird75:master.

Coverage analysis indicates that the test for an "empty"
actualKeysMatched table always succeeds, and the enclosed
return statement never gets executed.

This is to be expected, as for any given (non table-type)
key `k` that is present in `actual` but not in `expected`,
our earlier value-based test would already fail. We compare
actual[k] against (expected[k] == nil), which won't pass.

Fixed this by removing the unnecessary code.
@coveralls
Copy link

coveralls commented Oct 21, 2016

Coverage Status

Coverage increased (+0.0003%) to 99.824% when pulling 978d4a6 on n1tehawk:contrib into 9d00f65 on bluebird75:master.

@bluebird75
Copy link
Owner

The commit is fine, I will accept it.

However, after re-reading the discussion with Laurent, I think he makes a good point that luaunit should not introduce a bias in the calculation. marginBoost should go away...

I'll discuss it further in #68

@bluebird75 bluebird75 merged commit 4732946 into bluebird75:master Nov 4, 2016
@n1tehawk n1tehawk mentioned this pull request Nov 4, 2016
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.

None yet

3 participants