Dynamic prefix selection

[dmcclean]

I'd like to be able to display a Length Double by automatically selecting an appropriate metric prefix for meter based on the value of the Length Double rather than requiring a static selection of prefix.

As far as I can tell, we don't have support for this. Now that we have reified Prefixes, a list of siPrefixes, and the applyPrefix function (https://github.com/bjornbm/dimensional/blob/master/src/Numeric/Units/Dimensional/SIUnits.hs#L112-L116) we are close, we just need a function to select the correct prefix.

Proposed interface: (the Floating context being required to access logBase and RealFrac being required for truncate)

withAppropriatePrefix :: (Floating a, RealFrac a) => Unit 'Metric d a -> Quantity d a -> Unit 'NonMetric d a

We could possibly also expose:

appropriatePrefix :: (Floating a, RealFrac a) => Unit 'Metric d a -> Quantity d a -> Prefix

where

withAppropriatePrefix u q = applyPrefix (appropriatePrefix u q) u

Are there any reasons why this is undesirable? Are these names any good?

[dmcclean]

That split into appropriatePrefix and withAppropriatePrefix ignores some concerns about the fact that the appropriate prefix is sometimes no prefix at all. Change the return type of appropriatePrefix to be Maybe Prefix and the definition of withAppropriatePrefix to deal with it.

[dmcclean]

Another possible concern here is that deka, hecto, deci, and centi are second-class citizens in actual usage, even if that status doesn't appear to be codified anywhere that I could quickly find.

Should we have variants that exclude them from the search?

[bjornbm]

I think we should, perhaps even allowing users to provide their own assoc list of prefixCandidates appropriate to the field. For example, in addition to never having seen dekameters or hektometers it might be rare in a field to go beyond kilometers, preferring, e.g., 42164 km over 42.164 Mm.

[dmcclean]

Good idea.

[dmcclean]

Should these be lists of Maybe Prefix? Or should choosing no prefix always be allowed, even if the caller doesn't supply it in their list? Or should I fold the maybe-ness into the definition of Prefix so that no-prefix-at-all can be represented as a Prefix instead of requiring a Maybe Prefix? (Analysis paralysis.)

[dmcclean]

I went with the third thing. It seems cleaner because otherwise Maybe Prefix is pretty much everywhere you would want to use a Prefix.

[dmcclean]

I want to fix this as the next order of business. @bjornbm do you have suggestions for what predefined PrefixSets (in the nomenclature of #164) we might wish to provide, and what to name them? siPrefixes is the set of all SI prefixes, and majorSiPrefixes is only those whose exponent is a multiple of 3, are there any others we should predefine? Perhaps a convenience method like:

restrictRange :: Prefix -> Prefix -> PrefixSet -> PrefixSet
restrictRange low high = filterPrefixSet (\p -> low <= p && p <= high)

[bjornbm]

I can't think of any sensible ones other than siPrefixes and majorSiPrefixes. The one other convention I can think of would be for meter: majorSiPrefixes <> deci <> centi (should PrefixSet have a Semigroup instance?). Perhaps lengths are common enough to justify such a PrefixSet?