Add segmentation evaluation about mir_eval

[bmcfee]

General question: is it reasonable to add a scikit-learn dependency to this module? Some of the segmentation evals reduce to clustering evaluations already implemented by sklearn (after some boundary->frame conversion), and I'd really prefer to not implement that all over again.

[craffel]

I'd say definitely not, there are plenty of use cases for people who may not have sklearn. Someone else must have implemented this natively already right? Worst case you could wrap the import in a try catch statement (so all other modules would work) but that's nasty.

-Colin

On Aug 14, 2013, at 1:19 AM, Brian McFee [email protected] wrote:

General question: is it reasonable to add a scikit-learn dependency to this module? Some of the segmentation evals reduce to clustering evaluations already implemented by sklearn (after some boundary->frame conversion), and I'd really prefer to not implement that all over again.

—
Reply to this email directly or view it on GitHub.

[craffel]

Also-will scipy's clustering submodule do the trick instead?

-Colin

On Aug 14, 2013, at 1:19 AM, Brian McFee [email protected] wrote:

General question: is it reasonable to add a scikit-learn dependency to this module? Some of the segmentation evals reduce to clustering evaluations already implemented by sklearn (after some boundary->frame conversion), and I'd really prefer to not implement that all over again.

—
Reply to this email directly or view it on GitHub.

[bmcfee]

It looks like scipy.cluster just implements learning algorithms, not metrics, so no.

Re: sklearn dependency: are there really that many use cases? I'm hardly one for adding dependencies purely out of laziness, but it seems reasonable (to me) that the sort of user that would have need for a full-blown MIR eval package in python might also be the sort to want/use sklearn.

I could also see getting a lot more reuse out of sklearn.metrics beyond clustering (say, for annotation/retrieval evaluation, or maybe cv splits).

[craffel]

Yeah, I think while the use of ML in MIR is pretty widespread, there are still plenty of people working on eg onset, beat, chord recognition etc algorithms which are not learning based. I'd also think there's a substantial population of people using other ML tools instead. Not that installing sklearn should be a big deal for any of them. I just am uncomfortable with added dependencies which a large chunk of your user base may not have.

-Colin

On Aug 14, 2013, at 9:00 PM, Brian McFee [email protected] wrote:

It looks like scipy.cluster just implements learning algorithms, not metrics, so no.

Re: sklearn dependency: are there really that many use cases? I'm hardly one for adding dependencies purely out of laziness, but it seems reasonable (to me) that the sort of user that would have need for a full-blown MIR eval package in python might also be the sort to want/use sklearn.

I could also see getting a lot more reuse out of sklearn.metrics beyond clustering (say, for annotation/retrieval evaluation, or maybe cv splits).

—
Reply to this email directly or view it on GitHub.

[craffel]

All that being said if you think it'd be a big pain to reimplement feel free to add the sklearn dependency, it's not the end of the world.

-Colin

On Aug 14, 2013, at 9:00 PM, Brian McFee [email protected] wrote:

It looks like scipy.cluster just implements learning algorithms, not metrics, so no.

Re: sklearn dependency: are there really that many use cases? I'm hardly one for adding dependencies purely out of laziness, but it seems reasonable (to me) that the sort of user that would have need for a full-blown MIR eval package in python might also be the sort to want/use sklearn.

I could also see getting a lot more reuse out of sklearn.metrics beyond clustering (say, for annotation/retrieval evaluation, or maybe cv splits).

—
Reply to this email directly or view it on GitHub.