You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Libra was developed as an approach for inductively modeling dimensional analysis. It wasn't based on prior research in the field, and so fell into many common pitfalls associated with modeling dimensions. Notably:
comparisons between quantities of the same dimensions, but differently ordered hlists. 1 kg s should be the same quantity as 1 s kg. While we attempt to achieve this in our typeclasses, it isn't the case at the type level, so implicit searches that depend on this equivalence fail
some units of the same dimension have an offset, e.g. Celsius vs Fahrenheit. Libra fails to model these entirely
some units do not scale linearly e.g. decibels. Libra also fails to model these.
the conversions are inexact. Libra only supports conversions between quantities with a MultiplicativeGroup, but this isn't always entirely necessary. It should be possible to convert 1m to 100cm without the need for all the power of a MultiplicativeGroup.
One suggestion is the use of a normal form of dimension lists to enable equality between differently ordered lists. This could be modeled using a typeclass for a total order of all dimensions and units used in a project. If each dimension and unit has a show, this could potentially be derived using string ordering.
The text was updated successfully, but these errors were encountered:
Libra was developed as an approach for inductively modeling dimensional analysis. It wasn't based on prior research in the field, and so fell into many common pitfalls associated with modeling dimensions. Notably:
1 kg s
should be the same quantity as1 s kg
. While we attempt to achieve this in our typeclasses, it isn't the case at the type level, so implicit searches that depend on this equivalence failMultiplicativeGroup
, but this isn't always entirely necessary. It should be possible to convert1m
to100cm
without the need for all the power of aMultiplicativeGroup
.The following technical report on developing a type system for dimensional analysis contains a wealth of information regarding dimensions and their type inference. Some of it's suggestions could be taken forward to solve some of the problems listed above.
One suggestion is the use of a normal form of dimension lists to enable equality between differently ordered lists. This could be modeled using a typeclass for a total order of all dimensions and units used in a project. If each dimension and unit has a show, this could potentially be derived using string ordering.
The text was updated successfully, but these errors were encountered: