dmcclean
commented
10 years ago Sorry for not answering that in #7, I must have missed it somehow.
For me, having showIn :: Unit d v -> Quantity d v -> String is the most essential problem I am trying to solve, along with being able to compose units. AnyUnit and UnitMap are nice, but are probably a distraction in this conversation.
All of the Signal types in my autopilot come with a way to show the signal, which is awesome for monitoring what is going on. I use this bit of machinery to allow doing that even when abstracting over the type of the signal's content.
Right now the rest of that file is written against non-named-units dimensional-dk:
instance (Show v, Fractional v, Typeable d, Typeable v) => Representable (Quantity d v) where
type RepresentationDescriptor (Quantity d v) = Unit d v
represent unit value = show $ value /~ unit -- TODO: use the showIn function
defaultRepresentation _ = siUnitIf it was written against named-units dimensional-dk:
instance (Show v, Fractional v, Typeable d, Typeable v) => Representable (Quantity d v) where
type RepresentationDescriptor (Quantity d v) = Unit d v
represent = showIn
defaultRepresentation _ = siUnitNow instead of just getting a bare "74.961", I would get "74.961 kt", which is huge.
This is without using UnitMap, because it doesn't work by keeping a map from dimension to unit, instead it works by tracking the preferred unit when the signal is constructed.
For PID gains, I can use "redundant" units like degree / (degree / second), and the name of that unit can be computed and displayed. I can even form this unit compositionally in the definition of the PID loop signal function, as the preferred unit of the output divided by the preferred unit of the input, which an alternative scheme based on separate names would struggle to do.
I'd like to add to dimensional-experimental a function that takes Unit d v -> Quantity d v -> Text.LaTeX.LaTeX (probably using the siunitx CTAN package to avoid reinventing too many wheels). We could add a function that takes Unit d v to the UCUM name for the unit.
You could use other means to create a specialized show function taking a map of desired units, or even just taking a particular desired unit, but to do so you'd have to figure out how to represent units. I think that the representation in the branch is the one that makes the most sense and has the most benefits, because it encodes what a unit really is (a named dimensional quantity), and because it allows you to compose units using the group action on unit names and the group action on unit values together.
AFAICT, neither the NIST Guide nor the BIPM's The International System of Units "brochure" (not sure why they call it a brochure) directly defines a "unit". The BIPM document does point to another of their documents, though, the International Vocabulary of Basic and General Terms in Metrology, which in section 1.9, Note 1, does say that "Measurement units are designated by conventionally assigned names and symbols." Indeed, it seems to me that they could hardly not be, or they would be no different than quantities. How could something be, in their words, "defined and adopted by convention", without naming it? I suppose we could just point at the prototype kilogram and say "that one", but we could also do that with any other quantity.
(Unrelated: In that document, also check out section 1.12, which defines a "coherent derived unit" to be what we implemented as siUnit, the "derived unit that, for a given system of quantities and for a chosen set of base units, is a product of powers of base units with no other proportionality factor than one". I added a note to this effect in the documentation.)
bjornbm
@dmcclean, I've reviewed your named-units-variants branch and lite this iteration better. However, as I asked in #7 regarding the named-units branch:
Can you provide a concrete use case (perhaps pseudo-code) of what named-units will enable that cannot be handled by other means (e.g. a specialised show function taking a map of desired units)? Thanks