Dynamic prefix selection

[dmcclean]

For consideration as an implementation of #163.

[bjornbm]

Is this change limiting? I'm thinking of, e.g., Kilo (=1024) as used in KB. Not saying that this example is particularly relevant to the intended use of dimensional, but do any relevant prefixes that are not powers of ten exist? Is there a reasonable workaround for defining such prefixes without Prefix?

[dmcclean]

Good question.

Options: We could expose Prefix, we could expose Prefix from an 'Internal' module (actually we may already?).

We could add the IEC/ISO binary prefixes (kibi, mebi, etc) (which are approved by NIST but not by BIPM). If we wanted to get carried away we could change Metricality to have three alternatives instead of two, introduce amount of data as a base dimension, and limit their use only to where ISO/NIST say they should be used.

Outside of units for amount of data (which we currently don't recognize at all), I am not aware of any prefixes that are not powers of ten.

[dmcclean]

Do you want me to redo this to work around the change to scaleExponent? Or leave it as is?

Even in the case of moving to binary prefixes we could conceivably keep this API and add scaleBase?

[bjornbm]

I haven't thought of any other prefixes so you can leave as is. Regarding the binary prefixes I wouldn't want to pollute dimensional with them. I think they would be better handled by an ad hoc data type (outside of the scope of dimensional) rather than adding another dimension.

On 25 aug. 2016, at 01:36, Douglas McClean [email protected] wrote:

In src/Numeric/Units/Dimensional/UnitNames/Internal.hs:

@@ -141,12 +141,12 @@ data Prefix = Prefix
-- | The name of a metric prefix.
prefixName :: PrefixName,
-- | The scale factor denoted by a metric prefix.

•            scaleFactor :: Rational
  

•            scaleExponent :: Int
  

  Do you want me to redo this to work around the change to scaleExponent? Or leave it as is?

Even in the case of moving to binary prefixes we could conceivably keep this API and add scaleBase?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.