Generic quantities support

[non]

It would be nice if Squants provided a parallel set of generic types for working with other kinds of numbers besides Double, or supported generic types in some other way.

I'm not sure exactly what this would look like, or if this is a realistic goal for the project, but there are definitely types in Spire (Rational, Real, Complex[_], Interval[_], and so on) that would be really useful for dimensional analysis.

[garyKeorkunian]

Erik, I was recently informed of Spires and have been looking at it. I agree it would be nice to let users choose the type for the underlying value. I will play with the idea in a branch and see what I come up with.

Thanks.

[garyKeorkunian]

This work is in progress.

The current development version (0.3.1-SNAPSHOT) offers support for arbitrary numeric types as the argument for all Quantity factory methods. The underlying value and unit multipliers are still Doubles, but this change is a significant step towards providing generic support there as well.

This change will allow user code to begin using arbitrary numeric types now (when creating Quantities) and benefit from the full generics once it is available in the future.

[garyKeorkunian]

Significant progress has been made on this effort. It is a goal for the 0.5 series to have this fully implemented.

There is currently a wip branch that includes this work in progress within the object model replica. This replica can be found in the experimental package in the test code.

Most of the work has been complete and at this time I am playing a bit of whack-a-mole with Scala's type system.

The general strategy is to create a SquantsNumeric trait that can be implemented for any generic type. Implementations for Int, Long, Double and BigDecimal have been created. Implementations for Spire and other types will be included in a contrib project - once all of this working.

The main sticking point is a type conflict between specific UnitOfMeasure implementations and the type required by a Quantity valueUnit.

Quantities are now typed not only on themselves (as in previous versions) but also on a generic value type.

abstract class Quantity[T <: Quantity[T, N], N] ... {
  implicit val num: SquantsNumeric[N]  // provides required operations on N
  def value: N  // previously Double
  def valueUnit: UnitOfMeasure[T]
  ...
}

Since UnitOfMeasure is typed on Quantity, it's signature needed to change to ...

trait UnitOfMeasure[T <: Quantity[T, _]] {
}

The reason for the placeholder in the Value Type position is that it shouldn't matter to the UOM's what generic number type a quantity's underlying value is using. However, this leads to the following type incompatibility:

Quantity.valueUnit must be a UnitOfMeasure[T] where T <: Quantity[T, N]

however

Implementations of UnitOfMeasure are actually UnitOfMeasure[T] where T <: Quantity[T, _]. That is the UOM's are not fixed to specific underlying Quantity value.

In the end Quantity[T, N] != Quantity[T, _], and that is what I need to work through.

I suspect this could be remedied by applying the correct variance, but I haven't found a solution yet.

Any advice or suggests for solving this would be greatly appreciated.

[garyKeorkunian]

Well after a year of dabbling with this off and on I finally have a functioning prototype, which can be found in the squants.experimental package in the test code.

There is still work to do ...

• update the QuantityRange and TimeDerivative / Integral classes to support the change.
• port all of the Quantity Types (there are currently 55 of these).
• create SquantsNumeric Type Classes for Spire types - likely in a companion project.

[cquiroz]

I got inspired by @zainab-ali to add spire/generic support to squants. Would you think the wip branch is a good place to start?

[garyKeorkunian]

@cquiroz I think so. A good amount of work has been done there. The blocker was around the typing for QuantityRanges. Let me know if you have any questions or want to go over it.

[garyKeorkunian]

@cquiroz Actually, the more complete work is in the shared/test/scala/experimental folder of the master branch.

[derekmorr]

I had tried to grab Erik from the Spire project at NEScala to talk about this, but we never connected. He seemed to think there were issues with the current approach, but he didn't elaborate.