Fix Imperial units

[goldfirere]

Please see https://github.com/goldfirere/units/issues/3 for back-story.

[gambogi]

Alright, so I think I'd like to take this one on, but I'd like to get some feedback on my current plan for implementation.

Right now, there is only support for British Imperial Units, however the systems differ between the US, the UK, and Australia (I think Canada also has a few special ones). However, the countries that still rely on the Imperial System came to an agreement on the yard and the pound[1]. I think we should have those units in a base file Data.Metrology.Imperial.Units and then implement each Country's system in an appropriate subdirectory Data.Metrology.Imperial.US.Units vs Data.Metrology.Imperial.UK.Units for example. Each country's types would then be defined in terms of the official base units, whenever possible. Another thing to consider would be finding other units which are also of shared quantity, and potentially including that in the base Imperial unit definitions.

I'm not sure if I need a `Data.Metrology.Imperial.[country].Types for each country though, as that seems messy.

Thoughts?

[1] http://en.wikipedia.org/wiki/International_yard_and_pound

[goldfirere]

Thanks for volunteering to do this!

I agree with your plan for the different units.

For types polymorphic in the LCSU (like in SI.Poly), we can just use the SI types wholesale. We should export a suitable LCSU definition from each country.

And, even for monomorphic types, we can just use the SI types. This does mean that a user doing a calculation only in feet will still use meters internally, but this will be transparent to the user and the conversion is only done at uses of # and %, not at every bit of arithmetic. I think this is fine for standard users. Users who want more power (er, precision) should use the poly types!

Finally, it would be nice if a user can say import Data.Metrology.Imperial.US and get to work, so that module should re-export the useful bits from the Imperial and SI hierarchies (like the types). Does that make sense? Do you agree? Along similar lines, I think there should be Data.Metrology.Imperial.US.Poly that is careful not to export instances for DefaultDimOfUnit and exports the SI poly types.

I feel like what I've just written is hard to understand, so please push back if I'm writing gibberish or if you disagree with the plan.

Again, thanks!

[gambogi]

From what you have written this is the impression I'm getting of the directory structure:

Data
    Metrology
         Imperial
            Units.hs
            Types.hs
            US     
                 Units.hs
                 Types.hs
                 Poly.hs
            UK
                 Units.hs
                 Types.hs
                 Poly.hs
            AUS           
                 Units.hs
                 Types.hs
                 Poly.hs

My plan was to have the country specific ones reexport the base units that they have in common. I'm not really clear on what LCSU is used for within the library, so some guidance there will probably reduce potential errors.

[goldfirere]

What would Data.Metrology.Imperial.Units have? Ditto Types?

Following from your helpful presentation style, here is what I see:

Data
    Metrology
         Imperial
            US.hs   -- exports SI's MonoTypes and US's units
            US     
                 Units.hs   -- just has the units; no types; units are based on SI's dimensions
                            -- also includes LCSU
            UK.hs
            UK
                 Units.hs
            AUS.hs
            AUS           
                 Units.hs

This is different than what I proposed above, but on further thought, the Poly module would just re-export the units and SI's poly types... which isn't all that useful. The point of these re-exports is to make things easier, and I think a user who wants polymorphism would want to just import what they want directly. Happily, this is a simplification.

An LCSU might look like

import qualified Data.Metrology.SI.Dims as D
type Imperial = MkLCSU '[(D.Length, Foot), (D.Time, Second), (D.Mass, Pound), (D.Current, ???), ...]

The idea is that an LCSU dictates what units to use for dimensioned quantities internally. So, the LCSU above means that all lengths are converted into feet upon becoming proper quantities. The LCSU should contain mappings for each of SI's base dimensions. (If no Imperial unit is around, just use the SI unit, I would say.) Concrete LCSU's are important only when worried about numerical precision.

Does this help? It seems simpler, I think.

[goldfirere]

FYI, just added @gambogi to the committers list. Fire when ready. :)

[goldfirere]

@gambogi, any progress here? I'll be taking a look at units over the next few days and may be able to address this myself... Thanks!

[gambogi]

I haven't had a chance to actually write this yet. If you have the time, feel free.

[gambogi]

Didn't mean to close

[rastus-vernon]

If the Weights and Measures Act of 1824 is too incomplete, outdated or inconvenient, this document from NIST may be of use: https://web.archive.org/web/20061109061142/http://ts.nist.gov/WeightsAndMeasures/Publications/upload/h4402_appenc.pdf (although it is difficult to find your way around it).

The Units of Measurement Regulations of 1995 also seem to contain a good list.

[goldfirere]

This was actually closed by bd195fb.