Add input checking and improve test coverage

[jamesmbaazam]

This PR addresses comments raised in #79 and fixes #113.

[codecov-commenter]

Codecov Report

Merging #131 (612b5f9) into main (e77de7b) will increase coverage by 1.32%.
Report is 2 commits behind head on main.
The diff coverage is 100.00%.

❗ Current head 612b5f9 differs from pull request most recent head 309fa34. Consider uploading reports for the commit 309fa34 to get more accurate results

@@            Coverage Diff             @@
##             main     #131      +/-   ##
==========================================
+ Coverage   97.88%   99.20%   +1.32%     
==========================================
  Files           5        5              
  Lines         236      251      +15     
==========================================
+ Hits          231      249      +18     
+ Misses          5        2       -3     

Files	Coverage Δ
R/borel.r	100.00% <100.00%> (ø)
R/utils.r	100.00% <100.00%> (+28.57%)	⬆️

... and 1 file with indirect coverage changes

📣 Codecov offers a browser extension for seamless coverage viewing on GitHub. Try it in Chrome or Firefox today!

[sbfnk]

Great! Note the decrease in code coverage - can we add a test for this?

[jamesmbaazam]

Good point. That should be straightforward. Thanks for taking a look.

[pratikunterwegs]

Thanks for making these changes @jamesmbaazam. I've found a few places where some more input checks would be useful. These are internal functions so I appreciate that the inputs are likely to be well known and controlled, but these extra checks would still help to isolate issues during development.

Regarding the tests, some of them have expectations on (some of) the value limits, and it would be good to have these tests for all functions that return values. For functions that take a vector and return outputs, it would also be good to test that the input and output lengths correspond as expected.

[pratikunterwegs]

Thanks for looking at this review again @jamesmbaazam - I had forgotten about it entirely. Just a note that the commit hashes are not linking to the diff view, but that's no big deal. I'm just wondering why this PR is active now - my impression was that {bpmodels} was being superseded by {epichains} - will these changes be reflected there too?

[jamesmbaazam]

Just a note that the commit hashes are not linking to the diff view, but that's no big deal.

They are local hashes. I'm yet to push them. They'll link up when I've pushed them.

I'm just wondering why this PR is active now - my impression was that {bpmodels} was being superseded by {epichains} - will these changes be reflected there too?

Valid question. {epichains} shares these util functions and will benefit from this exercise. My intention is to port over these changes.

[jamesmbaazam]

Thanks for reviewing this @pratikunterwegs. I've addressed your comments and will merge this as it's been inactive for a pretty long time because it was deprioritized. I'll port over the changes to {epichains} where I will accept further reviews.