Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discrete vs Continuous quantities #14

Open
davidrpugh opened this issue Mar 13, 2017 · 3 comments
Open

Discrete vs Continuous quantities #14

davidrpugh opened this issue Mar 13, 2017 · 3 comments

Comments

@davidrpugh
Copy link

davidrpugh commented Mar 13, 2017

@bherd-rb Some tradable resources have quantities that are naturally discrete whilst other tradable resources have quantities that are natural continuous. I have been trying to come up with a solution to get this information into the type system. Getting this information into the type system is useful because it would allow us to restrict that types of orders that a particular auction can accept. For example, we might want to force market participants to only submit orders for discrete quantities (or continuous quantities).

I think that the Wurman et al (2001) paper provides a solution. Suppose that we have a trait Quantity that extends AnyVal and is parameterized on the type of value it contains. Then we can define two case classes for DiscreteQuantity and ContinuousQuantity as follows.

sealed trait Quantity[+T <: AnyVal] extends AnyVal {
  def value: T
}

case class DiscreteQuantity(value: Long) extends Quantity[Long]

case class ContinuousQuantity(value: Double) extends Quantity[Double]

Thoughts?

@davidrpugh
Copy link
Author

@bherd-rb There are some issues with the above implementation. First, one can not extend from a trait/class that extends from AnyVal nor can one mixin a trait with a class that extends from AnyVal. More details on this issue can be found on SO. This means that if we move forward with this implementation we must accept that additional memory overhead associated with allocating instances of the Quantity objects which was saved by the use of value classes. Second I would prefer to restrict the type of T to be any numeric value rather than the more generic AnyVal but at present this it is not possible to do this. I did learn about the specialized annotation that should help improve run-time performance of calculations using quantities.

Here is the correct implementation...

  sealed trait Quantity[@specialized(Long, Double) +T <: AnyVal] {

    def value: T

  }

  final case class DiscreteQuantity(value: Long) extends Quantity[Long]

  final case class ContinuousQuantity(value: Double) extends Quantity[Double]

@davidrpugh
Copy link
Author

@bherd-rb I think I managed to find a way to restrict the type T to be any type that can be converted to a Double using implicit conversions...

sealed abstract class Quantity[@specialized (Long, Double) +T](implicit ev: T => Double) {

  def value: T

}

final case class DiscreteQuantity(value: Long) extends Quantity[Long]

final case class ContinuousQuantity(value: Double) extends Quantity[Double]

However, this is having this change in type impacts the order types in non-trivial ways that I am trying to sort out.

@davidrpugh
Copy link
Author

davidrpugh commented Mar 13, 2017

@bherd There is now a PR #15 that implements the ideas discussed above.

@davidrpugh davidrpugh added this to the Version 0.2.0 milestone Apr 12, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant