Precisions v. Performance of decimal vs double

[DaveSkender]

I was on an online forum recently and saw someone mention that the use of decimal data precision is bad to use for financial indicators. I'd say decimal precision is necessary for financial data; and yes, it's observably slower than double in this kind of application.

Our decision to use decimal (m) is based on several key problems with using less precise data types, like double (d) and float (f):

1. The rounding errors, especially when compounding calculations, are observable, potentially problematic, and disturbing to rational financial analysts. For example:

   213.35f - 211.52f = 1.83000183 // float
   213.35d - 211.52d = 1.829999999999984 // double
   213.35m - 211.52m = 1.83 // decimal = mathematically correct

2. It's necessary for supporting cryptocurrency prices that currently allow up to 8 decimal point precision:

   1.00004330f - 1.00004326f = 0 // float (very bad)
   1.00004330d - 1.00004326d = 0.00000003999999975690116 // double
   1.00004330m - 1.00004326m = 0.00000004 // decimal

With that said, I'm fairly content with the current v1.9.2 library performance with a typical indicator execution time of 0.3ms, but am always considering these tradeoffs. float is definitely not an option; but if we were to switch to double, which has better precision, it would typically be 0.1ms, but then you'd have some rounding errors that could propagate poorly. My gut says it's not a good-enough tradeoff in many cases.

Note

SEP 2024 UPDATE: My views on this have changed slightly now that I know more about where this does and does not have important accuracy impact. Now, our goal is to maximize use of double, but with some accurate money exceptions.

[DaveSkender]

The reason I bring this up now is that the idea of using double instead of decimal in thoughtful places, not everywhere, is potentially a good opportunity to make some incremental performance gains. It doesn't make sense to me to do this on things like candle size calculations (e.g. H-L is expected to be 213.35 - 211.52 = 1.83); however, in other cases, it can work without problems.

For example, the internal calculation for GetSlope does not make any significant difference but goes much faster.

[DaveSkender]

The assumption I'll make is that we can adapt or markets will "price split" before we hit the point where more than 15 significant digits are required in this library. What this will allow us to do is make a tradeoff to use double (it's 8 bytes, about 15 significant digits) for much more of the indicator data, but continue to use decimal for anything that might be used for representations of monetary price (e.g. quotes and candles data) or where cumulative error propagation or conversion might be an issue.

[DaveSkender]

I'll be adding more test data to ensure we're able to handle these extreme ranges of price data + to exceed these ranges to see where and how it breaks.

[DaveSkender]

This is a rather interesting problem. I'm trying to determine if this scenario produces any real problems with the indicators:

double d = 10000000000000000 + 1;
Console.WriteLine($"{d:f}");

10000000000000000.00

Clearly, it's not mathematically correct, but are there actually any scenarios where it matters?

[DaveSkender]

For v1.20.0 I have generally made broad changes from decimal to double for internal calculations where there is no issues. This has resulted in about a 2x performance improvement overall. There may be more opportunities to explore, later. For now, my general approach:

• Price overlays: refactor internals, but keep decimal output
• Unbound oscillators and price characteristics: refactor internals + move to double outputs
• Bound oscillators (on a fixed scale): refactor internals, but keep decimal output
• Price transforms and candlestick patterns: minor internal refactoring + keep decimal output. Price precision is important on these.

[DaveSkender]

In version 2.0, I intend to increase the use of double for output values and limit decimal to candle-based outputs, like Renko and candlestick patterns, where price precision is required.

[DaveSkender]

My current view on our convention can boil down to:

• use double for non-money values
• use decimal for "accurate money" values » typically price or price substitutes

[manutiedra]

After those poor results on fiddle, I had to test it in benchmark.net. Here are the results running it in release mode, started without debugging and with optimize true::

// * Summary *

BenchmarkDotNet v0.14.0, Windows 10 (10.0.19045.4780/22H2/2022Update)
13th Gen Intel Core i9-13900H, 1 CPU, 20 logical and 14 physical cores
.NET SDK 8.0.303
[Host] : .NET 8.0.7 (8.0.724.31311), X64 RyuJIT AVX2
DefaultJob : .NET 8.0.7 (8.0.724.31311), X64 RyuJIT AVX2

Method	Mean	Error	StdDev
PrimitiveIntMath	314.6 us	6.20 us	9.27 us
PrimitiveDoubleMath	307.1 us	6.08 us	15.58 us
PrimitiveDecimalMath	72,038.1 us	1,360.49 us	1,566.75 us
GenericIntMath	311.9 us	6.59 us	18.25 us
GenericDoubleMath	307.7 us	6.13 us	15.83 us
GenericDecimalMath	70,226.7 us	1,398.75 us	3,351.31 us

I have attached the benchmark project.

benchmark.zip

[DaveSkender]

That's interesting. I'm thinking Fiddle doesn't do /optimize when it compiles, which seems to make a notable difference. I'll have to take a closer look later. Intuitively, it doesn't seem like a generic would have the same amount of overhead as a primitive; generally, looks like the generic works well.

[manutiedra]

And about the CLS compliant thing, why is it so important? There is a lot of .net core that is not CLS compliant dotnet/aspnetcore#2689 (comment)

[DaveSkender]

Other languages can use CLS compliant library interfaces. For example, our Python wrapper uses this DLL. The link above explains the standard.

With that said, I am planning to look into adding a TQuote interface with double values; though, it's not highly prioritized at the moment. I may be able to use this generic approach for an internal overload to help that along.

[DaveSkender]

Tracking INumber<T> here for future consideration:

• research: Use of System.Numerics.INumber<T> generic math #1282