A possible problem for algorithms dealing with new, complicated datatypes that don't have catFeatures

[peterTorrione]

Right now, algorithms use "catFeatures" to handle when there are multiple feature sets coming into a new Algorithm:

prtPreProcPca/prtClassPlsda+prtFusion...

It would really happen in the above, where a "/" is followed by a single action.

To make the code simple, we also call catFeatures everywhere instead of trying to figure out when we should call it (it's easy enough to do).

The problem is that for prtClassMultiplInstance, for example, there is no such thing as "catFeatures".

I see a few options.

1) We can re-write the current algo.run code to only use catFeatures when necessary. This will still break for MIL data in the case above, but lets you write straight algorithms. This has to be a temporary fix. I'll do it now.

2) Write catFeatures for dsMIL. There might be other data sets where catFeatures doesn't make any sense. We should either figure out the "right thing" or warn / error nicely...

[kennethmorton]

I think the solution to this is to make a method of datasets (I suppose it is abstract in prtDataSetBase) to combine from a parallel algorithm catParallel perhaps. prtDataSetInMemory can just call catFeatures and MIL can do whatever insanity is required.

[peterTorrione]

Agree - catParallel. Should be on our to-do-list.

That or, this is meaningless and should not be allowed for prtDataSetClassMil, or prtDataSetClassGraph, etc.