Advanced topic: if you had the choice, what data type would you choose to work with currency rates ?

New comment
 

In MQL double data type is used to represent currency rates, as well as for all data needing some decimals.

It has some advantages :

  • IEEE754 is an universal standard, commonly used everywhere, very well documented. It's fast an efficient.

And drawbacks :

  • It doesn't allow to represent all decimal values with precision.
  • Except some professional coders, it confuses everyone (the forum is full of topics about "how to display X digits" or the like).

If you had to design it, would you still use double or an alternative ? And why ?

Personally I would keep double internally, but I would hide it, as an implementation detail, behind a "rate" type (or whatever the name). And I would provide a clean and simple interface, easily understandable and usable, even by amateur coders. So I would keep the advantages and "hide" the drawbacks.

 

Based on my experience, especially in the old days, high-quality applications used Binary Coded Decimal (BCD) for financial and accounting data. The main advantage was that the number always had a true decimal representation and the number of digits could be set to a fixed number of digits. There are however other modern options besides BCD, that still maintain this kind of functionality, which is especially needed for financial data.

In the case of MetaTrader and it's Quote data, I would have designed it, using "ticks" (quote, not count) saved as Integer format, given that the "tick size" is already part of the symbol's contract specifications. This would allow all the raw quote data to be handled without any need for conversion, and could easily converted to floating point when equations such as moving averages need to be applied.

I would have also designed MQL trade functions to ALL work with "ticks" (in Integer format) and not in quote prices as "doubles".

EDIT: As for the volume (lots), I would have also designed it based on "lot step" and save as Integer and not "double".

EDIT2: One more advantage of using "ticks" and "lot step" would be the prevention of the annoying runtime errors that "newbie" codes get, when price and volume are not properly aligned.
 
@Fernando, I am your opinion.

PostgreSQL is used as backend for a lot of Finance Software solutions and it supports special data types to represent money values. Interestingly, they also suggest to use a concept similar to what you have suggested.



There are also hardware implications to be considered with such a decision, as doubles will be processed on the FPU part of a CPU, and that is significantly faster. The transition or casting between integers and floats is also costly.

Further floats have a very broad application in specialized hardware and find their representation in functions. The function set AVX, SSE, MMX, and any GPU will only operate on floating point units.

Mixing both would also mean, it is very necessary to have a clear boundary between both, so that as little as possible casting is performed.

Maybe it would be smart to implement a more robust float concept in general. And I am not aiming at redefining floats, but the application of those.

The main issue with usage of floats lies in the decimal precision, or their lack of such. So maybe it would be smart to use doubles as data type, but shift all values to be left of the decimal point.

This would remove the awkward problems with decimal precision, but keep the performance benefits given by specialized hardware.

So a combination of both worlds, the integer as it only represents natural numbers, and the float hardware support for the actual implementation.

EDIT: fixed typos.
 

In Ethereum they have a specification for decimals (how many decimals a token/coin has) and everything else is in integers .

New comment