Deprecate jackknife in favour of astropy's?
See original GitHub issueThis needs some investigation and also benchmarking whether it makes sense to deprecate astroML.resample.jackknife
in favour of astropy.stats.jackknife_resampling
and astropy.stats.jackknife_stats
or there is an argument to keep it at both places.
cc @mirca in case he wants to comment from the astropy side
Issue Analytics
- State:
- Created 5 years ago
- Comments:7 (4 by maintainers)
Top Results From Across the Web
Robust covariance estimation of galaxy–galaxy weak lensing
Using the mock catalogue to study the error covariance matrix of galaxy–galaxy weak lensing, we compare the full covariance with the 'jackknife' (JK) ......
Read more >arXiv:0705.2359v1 [astro-ph] 16 May 2007
perform jackknife tests which indicate that the observed signal has negligible contamination from instrumental systematics.
Read more >Planck 2018 results - I. Overview and the cosmological legacy ...
Internal consistency checks and jackknife tests, including splits by spatial and electromagnetic frequency, are discussed extensively in Planck ...
Read more >Cosmology And Astrophysics From Small Scales
I would also like to thank Mark Devlin for his immense support and guidance ... The errorbars are estimated from jackknife covariances.
Read more >THE CLUSTERING OF GALAXIES IN THE SDSS ... - IOPscience
THE ASTROPHYSICAL JOURNAL, 767:122 (19pp), 2013 April 20 ... using the jackknife resampling method (following Zehavi et al. 2005b, 2011). Cov(ξi,ξj ) =....
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@bsipocz We adopted a general principle in such cases that we should switch to astropy implementation, unless it is technically inferior (functionality, speed, memory usage, in this priority order) to astroML implementation. Given the analysis above kindly provided by @mirca it seems that we should adopt astropy implementation here.
Ohh, and the option of returning the raw distribution. We use it in one figure, I’ll look around on github whether anyone else uses it for anything.