Add convenience conversion function from float/double to long?

[bherd-rb]

@davidrpugh We have recently switched from double to long for prices (I still think for good reasons). However, in the case of micropayments, prices will very likely be small non-integer numbers. In that case, manual conversion is required every time the value is to be passed to ESL. The conversion itself may not be trivial. For example, how should a value of 0.01 be translated to long? In theory, the developer would have to determine the smallest amount of interest in the respective simulation and make that corresponding with a long value of 1.

Would it make sense to use some sort of internal currency hierarchy similar to that used in Ethereum in ESL? On top of that, we could then provide some convenience functions to perform conversions, e.g. from double to long.

[davidrpugh]

@bherd-rb Currently we are leaving it up to the developer to choose the smallest unit of value and normalize that to a long value of 1.

One possibility I had thought of was creating a type hierarchy for Price...

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

  def value: V

}

final case class DiscretePrice(value: Long) extends Price[Long]

final case class ContinuousPrice(value: Double) extends Price[Double]

...for micro-payments one could require the use of a continuous price. I still worry about numerical precision issues when using Doubles.

This problem is equivalent to choosing a minimum tick size which would typically be specific to a particular type of tradable.

I had not thought about using some sort of internal currency hierarchy a la Ethereum. I will think about this a bit more...

[davidrpugh]

Possibly relevant docs...

https://www.w3.org/TR/Micropayment-Markup/
http://wwwhome.cs.utwente.nl/~pras/publications/2005-I3E-2ndgeneration-payments.pdf

...is there a reasonable value for a minimum tick size for a micropayment independent of type of tradable? What happens in combinatoric/multi-dimensional auctions where bundles of tradables are being auctioned? I guess minimum tick would be the minimum of the ticks for each tradable in the bundle?

Should we consider adding a tick field to the Tradable trait and requiring that the price specified in an order be a multiple of this minimum tick?

[bherd-rb]

@davidrpugh Good guestions, indeed. I like the idea of adding a tick field, this is kind of what I was thinking about. Seems like a very elegant solution. I don't see any obvious problems at the moment but I need to think about it in more detail ...

As an example for a minimum tick size: if we want to simulate an Ethereum-based system, the smallest possible value at the moment would be around 0,000000000000000042 USD (current exchange rate for 1 Wei). That's a multiplication factor of 1000000000000000000.

[davidrpugh]

@bherd-rb I will open a PR for adding a minimum tick size field for each tradable later today and we can discuss and think about issues with this approach.

Simulating an Ethereum-based system is not a bad idea but using multiplication factors of 1000000000000000000 is probably not possible. This number is roughly 2^60 which is within a factor of 8 from the largest possible 64-bit long.

[davidrpugh]

More docs that might be relevant to the discussion...

https://docs.oracle.com/javase/7/docs/api/java/util/Currency.html
http://java-performance.com/

@phelps-sg do you have opinions?

[davidrpugh]

@bherd-rb Here is an interesting discussion of features that will be in Java 9 (which we can perhaps use for inspiration)...

https://dzone.com/articles/looking-java-9-money-and
https://github.com/JavaMoney/jsr354-api

[davidrpugh]

@bherd-rb Where are we on this issue? We merged PR #35, but I think this is only a partial solution. What do you think about the Price hierarchy that I defined above?

[bherd-rb]

@davidrpugh Sorry, I've completely forgotten about the price hierarchy. I'll have a look and give you feedback as quickly as possible.

[davidrpugh]

@bherd-rb No worries. The solution above does not provide a convenience function to convert doubles/floats to longs but rather attempts to provide the user with the choice to express prices using either (depending on the use case).

[bherd-rb]

@davidrpugh I like the idea of a price hierarchy! Here is a summary of my state of knowledge on representing money and currencies (please correct me if I'm wrong):

• Using long is fine as long as we don't need to do any calculations involving non-integer values (e.g. percentages). This would require manual conversion and introduce rounding issues if not done consistently.
• Using double is fine as long as the following two rules are observed (feels as limiting as the previous solution):
  1. Avoid working with non-integral values while using double (calculate in the smallest currency units).
  2. Round any multiplication/division results using Math.round/rint/ceil/floor (per your system requirements).
• The most convenient, recommended, yet also most inefficient solution is to use BigDecimal for all numeric calculations. See here for a discussion.

BigDecimal seems like the most stable solution, yet it is quite inefficient. Against that background, letting the user choose (based on your price hierarchy) seems like a sensible first start. Here are my questions:

• Given the advantages of BigDecimal, should we also include it as an option into your price hierarchy? It is fairly inefficient in comparison to double but it might be perfectly fine for many non-demanding simulations.
• I like the idea of the Money Pattern by Fowler described in this thread. It hides some of the intricacies, e.g. with respect to rounding, from the user. Would something like that be helpful?

The Money and Currency API in Java 9 looks great. It would be worth considering as soon as it is available.

[davidrpugh]

@bherd-rb thanks for the comments. I particularly like your suggestion to incorporate BigDecimal into the Price hierarchy as well as the link to Martin Fowler's "Money patter." I would be keen to know if @DavoudTaghawiNejad or @phelps-sg have thought about this issue. @rafabap has already run into precision issues with using doubles in his simulations, perhaps he also has ideas.

[davidrpugh]

@bherd-rb I came across this library for type-safe dimensional analysis that looks quite useful. If you scroll about half way down the README you will find a discussion of Money, exchange rates, etc.