`logScore` organization proposal

PointSetDist_Scoring.res

// Needs to be able to import `PointSetTypes.pointSetDist` as `t` 
type scoreArgs = DistDist(t, t) | DistFloat(t, float), DistDistDist(t, t, t), DistFloatDist(t, float, t) 
// Can be expanded for the other 4 cases of the definition of scoring a scalar prediction against a dist answer.

module KlDivergence = {
  ...
} 

module LogScoreAgainstScalarAnswer = {
  let score = (prediction, answer) => ...
  let scoreWithPrior = (prediction, answer, prior) => ...
}

module T = { 
  let score = (args: scoreArgs) => 
    switch args {
      DistDist(prediction, answer) => KlDivergence.score(prediction, answer)
      DistFloat(prediction, answer) => LogScoreAgainstScalarAnswer.score(prediction, answer)
      DistDistDist(prediction, answer, prior) => KlDivergence.score(prediction, answer) - KlDivergence.score(prior, answer)
      DistFloatDist(prediction, answer, prior) => LogScoreAgainstScalarAnswer.scoreWithPrior(prediction, answer, prior)
    } 
}

thanks!

me in slack:

the main change in philosophy is importing the type PoitnSetTypes.pointSetDist and it's constructors into the scoring file, instead of making the scoring file unaware

also:

• I'll be moving integration logic into scoring file now, too.

the main change in philosophy is importing the type PoitnSetTypes.pointSetDist and it's constructors into the scoring file, instead of making the scoring file unaware

I don't see much of that here, but I'm happy for the scoring file to be dependent on PoitnSetTypes.pointSetDist, if that's what you mean.

I'll be moving integration logic into scoring file now, too.
Moving lots to the scoring file seems good to me