search

ELVIS-Project / vis-framework

Thoroughly modern symbolic musical data analysis suite.
http://elvisproject.ca/
31 stars 6 forks source link

Disallow Calling run() with an Indexer after an Experimenter #291

Closed crantila closed 7 years ago

crantila commented 10 years ago

It should be a relatively simple change in both our models. Since we'll have to raise an exception when it happens, we'll have to revise the API.

alexandermorgan commented 8 years ago

Why would we want to disallow this?

crantila commented 8 years ago

https://vis-framework.readthedocs.io/en/latest/about.html#two-types-of-analyzers

alexandermorgan commented 8 years ago

I read through this file and I still don't see why we would want to disallow this. I get that if you're creating a linear workflow, and experimenter will generally be at the end of that workflow. But if you're just exploring a piece or corpus, you could easily want to run an indexer after having run an experimenter. Also, this shouldn't change the results of the indexer so I don't know why we would bother disallowing it. Is the only concern ensuring that user-generated workflows are optimally efficient? I don't think this is a big concern and this restriction wouldn't guarantee that anyway.

crantila commented 8 years ago

This is about the situation where an indexer receives data only from experimenters. For reasons explained at length in the API, this would necessarily produce nonsense, by virtue of the distinction between indexers and experimenters.

Whether to bother adjusting IndexedPiece so it prohibits this is open to discussion. The fact that a workflow with an indexer that receives data only from experimenters will produce nonsense, this is a necessary fact of the framework's design.

alexandermorgan commented 7 years ago

This issue is closely related to the structure of the workflow manager, which is now deprecated. The larger issue of indexers not being able to make meaningful use of any data from experimenters is still present, but this issue is largely alleviated by the fact that many indexer data inputs have defaults now (since VIS 3.0). The issue is also addressed with better documentation and by the raising of more explanatory RuntimeError and RuntimeWarning messages.