Adding to the discussion on the need for a generic interface for `Impurity`, or more precisely `Error`, I believe we all see that it's good to have. Ideally I would have preferred a single `Error` trait and that all types of Error like Square or KL divergence extend it, but the consensus is
that it negatively impacts performance.

In addition to performance-oriented implementations for specific loss functions, I would still recommend a generic `Error` interface and a generic implementation of decision-tree based on this interface. One possibility is to add a third `calculate(stats)`, or more precisely `error(errorStats: ErrorStats)` to the `Error` interface. I am not sure it will help the signature collision problem though, unless we just keep the one signature for generic error statistics.

For reference and example of one such interface and implementations, see `trait LossStats[S <: LossStats[S]]` and `abstract class Loss[S <: LossStats[S]:Manifest]` in my previous PR,
[https://github.com/apache/incubator-spark/pull/161/files](https://github.com/apache/incubator-spark/pull/161/files), that exactly do that and provide interfaces for aggregable error statistics and calculating error from these statistics. (On second thought, I feel `ErrorStats` and `Error` are better names.) Also see the generic implementation `class DecisionTreeAlgorithm[S <: LossStats[S]:Manifest]` and implementations of specific error functions, `SquareLoss` and `EntropyLoss`.