Use more specialized type classes instead of Numeric about coulomb HOT 8 CLOSED

Hi @ipsq! IIRC, Libra did something like that. That would also be a way to support #13. I've actually been leaning toward removing any requirements on N in the class itself, and possibly factoring out the numeric operations into an implicit class, making the core Quantity a bit leaner.

from coulomb.

I'd be all for it. We are using some optimized numeric types in conjunction with refined skipping heavy calculations when the type system offers certain guarantees.

from coulomb.

this generalization raises a couple questions I don't have obvious answers for. Taking the basic numeric operators +, -, *, / as an example, the proper typelevel/algebra type classes would be:

• +: AdditiveSemigroup
• -: AdditiveGroup
• *: MultiplicativeSemigroup
• /: MultiplicativeGroup

Currently, the implicit data structure that represents unit definitions encodes the conversion coefficients for derived units via a Rational. That integrates well enough with pretty much any data type adhering to the spire/Numeric type class, since these are all scalar numerics themselves.

However, the more general type classes above will admit types that aren't themselves scalar. Complex numbers and matrices, for example. These two examples at least have a well-defined notion of what it means to be multiplied by a scalar but I'm not sure all examples of MultiplicativeSemigroup, etc, support a definition scalar multiplication.

It also raises the question of whether 'scalar conversion coefficient' is even the right type. If my multiplicative semigroup is Complex, does that imply I should be using unit definitions where the conversion coefficient is also complex? Likewise for matrices?

Are your custom types representations of scalar numeric types?

Another example: I currently make use of the spire/Numeric type for guaranteeing that I can convert between types. This is to allow things like mixing numeric types in unit expressions, paralleling the way one can do 3 + 3.14. However, more general type classes like AdditiveGroup do not support this guarantee, so I'd also either have to restrict this feature, or provide another typeclass that will allow such conversions. Restricting them might not be a bad policy, but it's a change from the current behavior.

from coulomb.

@ipsq my original concept, IIRC, was that if someone wanted to use a new kind of numeric type, the approach would be to define a corresponding spire/Numeric typeclass instance for it. Is that something that would work for your custom types?

from coulomb.

I'm not even sure "scalar numeric" is quite sufficient - the field integers mod n, for prime n is a field but it's not obvious to me whether it's well defined to declare a unit system over that.

from coulomb.

I think I have worked out how to make progress with this. I'm making some calls to things like uc.n1.plus(value, uc.cv21(rhs.value)) and I've already abstracted the conversion with cv21 in a way that allows for specialization. I just need do the same thing with n1.plus - turn that into uc.plus, and then I can specialize rules in the right way.

I'll try to work on this soon

from coulomb.

@ipsq I have pushed a pr for this, as a core refactoring for 0.4.x
#66

coulomb core logic is now fully algebra-ized, and completely decoupled from Numeric.

from coulomb.

Closing this with #66, feel free to re-open if it isn't meeting people's needs

from coulomb.