Quantity vector, or vector of quantities?

[nushio3]

On writing the test for #31: (please look at comments in https://github.com/goldfirere/units/blob/309236af6dcc6aae4da1bb4b2c7bab91534b6614/Tests/Vector.hs) ,

I noticed that the current design of Data.Metrology.Vector requires Fractional instance for V n where V is the vector type constructor. Particularly, in this case Fractional (Rational, Rational) . I think such instances are not generally available.

From this viewpoint, it seems more natural to define and operate over types of the form V (Qu d l n) , rather than Qu d l (V n) .

This problem is important to me. Because I'm going to do physical simulations using units , I inevitably deal with array of quantities. I've been thinking about this for some time. But just thinking. Thank you for bringing up this issue as a concrete problem with codes!

[nushio3]

Some more thoughts:

A merit of Qu d l (V n) approach is that since we operate on raw V n we might enjoy type-specific optimization that the vector library provides. For example the library may specialize dot-products or maps over V Double or V CFloat . We may lose optimization if we use types of the form V (Qu d l n). We may recover optimization by writing new instances for optimization, or by adding rewrite rules, but that can be hard task.

A demerit of Qu d l (V n) approach is about Fractional (V n) instances. There are widely-used vector spaces that are not fields. For example, 2x2 real square matrices have nonzero elements that doesn't have multiplicative inverses (i.e. nonzero matrices whose det = 0).

[goldfirere]

A few responses:

• I think the problem you ran into in your Vector test is that the file imports the wrong units interface. That file uses Data.Metrology.Poly, which has no support for vectors. If you import Data.Metrology.Vector instead of Data.Metrology.Poly (don't import both!), you get the vector operations, which should require the right Fractional instances.
• I prefer Qu d l (V n) because we want safety properties to be associated with Qu -- it must be opaque. Generalizing Qu to a class would allow people to use quantity-like operations without necessarily respecting unit-safety. This goes against a design principle.

Does this address your concern?

[nushio3]

Oh, I didn't have idea to specialize % and # for vector cases! Indeed, it solves the dilemma I've been occasionally thinking of for a long time. What a joy to have a collaboration!

I have moved the test for linear operation on quantities to Tests/Linearity.hs , on the other hand tests on Vector instances are at Tests/Vector.hs . I'll make the tests more comprehensive, in my spare times.