Closed mkborregaard closed 3 years ago
Merging #41 (41216e9) into main (d901551) will decrease coverage by
0.47%
. The diff coverage is0.00%
.
@@ Coverage Diff @@
## main #41 +/- ##
========================================
- Coverage 7.32% 6.84% -0.48%
========================================
Files 12 13 +1
Lines 273 292 +19
========================================
Hits 20 20
- Misses 253 272 +19
Flag | Coverage Δ | |
---|---|---|
unittests | 6.84% <0.00%> (-0.48%) |
:arrow_down: |
Flags with carried forward coverage won't be shown. Click here to find out more.
Impacted Files | Coverage Δ | |
---|---|---|
src/NeutralLandscapes.jl | 100.00% <ø> (ø) |
|
src/algorithms/nncluster.jl | 0.00% <0.00%> (ø) |
|
src/algorithms/nnelement.jl | 0.00% <0.00%> (ø) |
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 d901551...41216e9. Read the comment docs.
Maybe some testing to work out whether it really gives the same results would be in order
can this be done with PyCall? seems like a way to call NLMpy/NLMR equivalents would be good for testing and benchmarking
It's always problematic when random number draws are involved I think - unless we cache a few million random numbers and read from that instaed of rand calls
This is the final landscape algorithm. Maybe some testing to work out whether it really gives the same results would be in order. One difference in behaviour is that the original code applies the
mask
first here. That means that for masks with many NaNs, this code here might end with numbers of cluster that for reasons of random sampling are more spread out around the target value ofp
. Ameliorating this would require making a specificrand!
method for this particular NeutralLandscapeMaker, so it loses some consistency. Thoughts?