For coders : what would you like to see as value for 'x = 1.123 * 0.67' (double) in the MetaEditor Watchlist ? (see first post for more explanation).

New comment
 
  • 29% (4)
  • 7% (1)
  • 64% (9)
  • 0% (0)
Total voters: 13
 

The full discussion about this can be found here : https://www.mql5.com/en/forum/494649/page8#comment_58078895

My proposal is to show the real value in priority, not as a tooltip. The other values can be shown optionally or additionally.

Forum on trading, automated trading systems and testing trading strategies

New MetaTrader 5 Platform Build 5260: Enhancements in Algo Forge, extended OpenBLAS support, and new inheritance rules in MQL5

Alain Verleyen, 2025.09.21 13:28

The issue is not for 0.3 only, consider this:
1.123 * 0.67, then how we're supposed to emit the string of full result (in debugger, or Print())? 5 decimal places, 6, 7,....,17 ?!!!
Simple! Let RYU pick the shortest (and accurate) one for you.

0.75241

I want to see the real value, that's it. Not (only) a value coming from an internal representation for the computer (0.752410000000000023).

I am not suggesting to hide anything, but either to show all "values" directly (a tooltip is not very practical), or to let the coder choose what he wants to see.


 
I voted for showing the real value (0.75241), since it is the most intuitive for programmers and matches the expected mathematical result.

The IEEE-754 or hexadecimal representations can remain optional for cases where exact binary inspection is required.
 

This is an X/Y problem!

I vote the MQL should have a real decimal based numeric floating point data type, for example binary-coded decimal (BCD) and other variants.

Most properly implemented financial applications use decimal based numeric data types, because it is crucial for financial calculations. They don't use binary floating point which introduces round errors, and because it can cause serious problems when real money is involved. So, I don't understand how trading applications can be any different.

COBOL, one of the oldest and most influential programming languages in finance, adopted this paradigm right for the very beginning of its existence.

How can a trading application and its system be so careless as to us binary floating point? Did software developers not learn their history lessons yet?

Storing financial data in decimal numeric format is crucial to guarantee accuracy of both the data and calculations carried out on it. It's a more accurate representation and rounding of decimal quantities.

MetaQuotes, please adopt decimal based numerical data types!

 
Fernando Carreiro #:

This is an X/Y problem!

I vote the MQL should have a real decimal based numeric floating point data type, for example binary-coded decimal (BCD) and other variants.

Most properly implemented financial applications use decimal based numeric data types, because it is crucial for financial calculations. They don't use binary floating point which introduces round errors, and because it can cause serious problems when real money is involved. So, I don't understand how trading applications can be any different.

COBOL, one of the oldest and most influential programming languages in finance, adopted this paradigm right for the very beginning of its existence.

How can a trading application and its system be so careless as to us binary floating point? Did software developers not learn their history lessons yet?

Storing financial data in decimal numeric format is crucial to guarantee accuracy of both the data and calculations carried out on it. It's a more accurate representation and rounding of decimal quantities.

MetaQuotes, please adopt decimal based numerical data types!

I've also posted a suggestion to support decimal type in MT5, but think about one big problem induced by such an introduction: at which step(s) of calculations in an (arbitrary complex) expression would you suggest to apply rounding according to the decimal precision? And what if the expression contains decimals with different precisions, such as lots/volumes (say, 2 digits) and prices (say, 5 digits)?

If you round after each atomic operation (say, multiplication or division) you'll end up with very large error/bias in results. If you perform all calculations in floating point and when round the result up to required decimal precision, you'll break your financial balance (that is result will not match expected aggregated value of arguments).

 
Fernando Carreiro #:

This is an X/Y problem!

I vote the MQL should have a real decimal based numeric floating point data type, for example binary-coded decimal (BCD) and other variants.

Most properly implemented financial applications use decimal based numeric data types, because it is crucial for financial calculations. They don't use binary floating point which introduces round errors, and because it can cause serious problems when real money is involved. So, I don't understand how trading applications can be any different.

COBOL, one of the oldest and most influential programming languages in finance, adopted this paradigm right for the very beginning of its existence.

How can a trading application and its system be so careless as to us binary floating point? Did software developers not learn their history lessons yet?

Storing financial data in decimal numeric format is crucial to guarantee accuracy of both the data and calculations carried out on it. It's a more accurate representation and rounding of decimal quantities.

MetaQuotes, please adopt decimal based numerical data types!

Ok, it's also an interesting point, but this poll is clearly to see in the real context of MT5, so using double for price, volume, quotes etc...

Also please stay on technical points, critics about MetaQuotes design choice is mostly assumptions and will lead nowhere (unless someone of MQ will participate which is unlikely). For sure they will not change their design now, after 15 years of existence, at best they could add a new type beside double which will stay at the core of the platform data.

Using BCD or other variants is leading to other issues, like bigger memory usage or impact on performance, so it's not so obvious it's the right design choice.

 
Stanislav Korotky #:

I've also posted a suggestion to support decimal type in MT5, but think about one big problem induced by such an introduction: at which step(s) of calculations in an (arbitrary complex) expression would you suggest to apply rounding according to the decimal precision? And what if the expression contains decimals with different precisions, such as lots/volumes (say, 2 digits) and prices (say, 5 digits)?

If you round after each atomic operation (say, multiplication or division) you'll end up with very large error/bias in results. If you perform all calculations in floating point and when round the result up to required decimal precision, you'll break your financial balance (that is result will not match expected aggregated value of arguments).

There is no issue at all! You are only confusing the issue.

If COBOL, Fortran and many other languages can seamlessly work with decimal based numerics and with different precisions, what is the issue?

When working with decimal numerics, all arithmetic operations are also carried out in decimal, not binary, and the quote and volume data should also be stored in decimal format.

There are even implementations for C and C++, of which some compilers having built-in support for optimisations for decimal based operations.

 
Alain Verleyen #: but this poll is clearly to see in the real context of MT5, so using double for price, volume, quotes etc...
Yes, and for that reason I also voted on the poll with option 3, namely "0.75241".
 
Fernando Carreiro #:

There is no issue at all! You are only confusing the issue.

If COBOL, Fortran and many other languages can seamlessly work with decimal based numerics and with different precisions, what is the issue?

When working with decimal numerics, all arithmetic operations are also carried out in decimal, not binary, and the quote and volume data should also be stored in decimal format.

There are even implementations for C and C++, of which some compilers having built-in support for optimisations for decimal based operations.

It seems you don't understand the problem. In an actual expression coming from a trade system you can't guarantee to have all values of the same decimal precision (due to their underlying nature). And meaning of result value can imply different precision, so you can't eliminate rounding at some (one or more) stage(s).

I worked in a firm developing financial accounting systems - I know the problem.

 
Fernando, what you say about decimals is absolutely valid in theory. Many finance-oriented languages, such as COBOL or even .NET with its decimal type, avoid rounding problems by working directly in base 10. In that sense, your reasoning makes sense.

However, in the context of MetaTrader 5 the situation is different. Since its release in 2010, the platform and the MQL5 language have been built on the 64-bit IEEE-754 double type. More than 15 years have passed with that foundation, and the whole ecosystem of terminals, servers, brokers, and libraries depends on it. Switching the core to decimal today is simply not realistic.

Alain is right when he says that the current debate is more practical: how the value is displayed in the editor's Watchlist. For developers it is more useful to see the expected result (for example, 0.75241), while keeping the other representations as optional. And as Stanislav pointed out, introducing a decimal type would also bring serious issues with intermediate rounding and mixing different precisions (e.g. prices with 5 digits versus volumes with 2).

In short, your point about decimals is correct in other environments, but it does not apply here. What can be improved is how the value is represented in the debugger, since that is what directly affects our daily work in MT5.
 
Stanislav Korotky #: It seems you don't understand the problem. In an actual expression coming from a trade system you can't guarantee to have all values of the same decimal precision (due to their underlying nature). And meaning of result value can imply different precision, so you can't eliminate rounding at some (one or more) stage(s). I worked in a firm developing financial accounting systems - I know the problem.

The same applies to binary floating point. The rounding error considerations are equivalent.

There is a mantissa and an exponent, be it binary or decimal, and there is a limit to the precision of what is stored, and how it is manipulated during calculations.

Just as a "double" has a fixed number of available bits for representing the number, so does the decimal counterpart. I see no issue nor difference, one is binary and the other is decimal, that is all.

Binary is faster and more compact, while decimal may be slower and less compact. But that is where the differences end.

And yes, I have also worked for a financial institution before. Between 2000-2002, I worked for a major well known Spanish bank, in the software department of their trading division, and even visited the trading floor often. 

12
New comment