About a common computations domain.

[KelSolaar]

At the moment the main computations domains in the API are the following:

• [0-1]
• [0-10]
• [0-100]

While I'm not super keen of diverging from the references, it's obvious that having a common computations domain would make things smoother. I will enumerate the existing objects with their domains so that we can discuss about all that. At the moment I'm kind of biased toward [0-100] because CAMs, CATs and some of the spectral code is operating in that domain.

[KevinJW]

obviously ACES is a bit of a 'spanner in the works' for that.

On Tue, Sep 9, 2014 at 5:26 PM, Thomas Mansencal [email protected]
wrote:

At the moment the main computations domains in the API are the following:

• [0-1]
• [0-10]
• [0-100]

While I'm not super keen of diverging from the references, it's obvious
that having a common computations domain would make things smoother. I will
enumerate the existing objects with their domains so that we can discuss
about all that. At the moment I'm kind of biased toward [0-100] because
CAMs, CATs and some of the spectral code is operating in that domain.

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

[KelSolaar]

@KevinJW There are a lot of them atm (too much) :)

[MichaelMauderer]

Usually I am a fan of [0-1] as its the normalised one. But there if definitely a benefit in having the models work as they where originally described.

So...is there a way to have both? Have the original description as a default and then a normalised version? Or have a parameter that defines whether input is given according to specification or normalised.

The important bit either way is that the behaviour needs to be obvious, and needs to follow the principle of least astonishment.

[KelSolaar]

At some point I was thinking about having a package wide variable if once set would force everything to be normalised in the chosen domain, it would require quite a lot of work but:

• It could be an elegant way of not breaking backward compatibility, although in the current alpha state of the API and provided we document clearly the changes it's not a big deal.
• It would allow one to set the working domain for the whole API at once.
• It would probably make the code a bit less elegant though because we would have to do some conditional testing in the objects, as a workaround I was also thinking about implementing that using a special normalising decorator where you input the original domain and the normalisation is done by consulting the package wide variable.

[MichaelMauderer]

I am not sure about that. It would result in a magic function/variable changing the state of the whole package, having a side effect on virtually everything ... it sounds like trouble, but I'll give it some thought.

[KelSolaar]

What about a decorator issuing warnings if it detects or smells that the input domain given by the user is either wrong or fishy?

[MichaelMauderer]

I assume it should be pretty easy to detect if something is out of domain for [0-1], so that would probably be a sensible possibility.

[KelSolaar]

A potential side effect of the decorator would be performance issue when checking the domains repeatedly. The API is at the moment not meant to have huge performance over large dataset, but it's not excluded that we work toward that one day with either Cython or Numba.

[KelSolaar]

This issue should be handled implicitly by the metadata code as per #267.