Brian McFee
Brian McFee
> I'm in favor of the ridge solution if it's generally accepted by the community, but I suppose we'd need to be careful about communicating what metric exactly we have...
> Let me know if that does the trick. LGTM, thanks! > Pypi was also yelling at me that I was the sole maintainer of mir_eval so I added Brian.McFee...
> Hm, yes, maybe based on [#68 (comment)](https://github.com/craffel/mir_eval/issues/68#issuecomment-495227366) it would make most sense to remove it or just call out to museval? Lol, I'd forgotten that we'd already had this...
Alright, I'm closing this PR out to open an new one implementing the deprecation cycle. (And meanwhile relaxing the test tolerance to skirt around heisenbugs.)
Punting this from the milestone since #382 renders it irrelevant.
> What steps are remaining to take to make mir_eval compatible with the latest NumPy again? AFAIK it's really just down to replacing uses of deprecated dtype aliases (np.complex, np.float)...
Good project for [docathon](https://bids.github.io/docathon/) this coming week. I'll take a crack at it probably around wednesday.
Hrm, looks like only the project owner can set up the integration. :cry:
Blocked by #375
It's less about having a deep/wide hierarchy of exceptions than making it easy to catch all mir_eval-generated exceptions in one go, if the caller wants to. Right now, we can't...