Open YaTaUser opened 7 months ago
Technically speaking, exponential moving average family uses the whole historical values you provide and does not have a fixed size window (like SMA
, WMA
, etc do).
Something similar happening with Vidaya
, which holds it's force coefficient for the entire history.
So there is nothing wrong in this kind of behavior.
My impression of this crate is, it's less for demonstrating mathematical exercises, but for giving reliable and usable moving averages. For example, this is Vidya-100 over 200 candles (last 100 shown, last value ~15'830):
The same over entire DAX history (currently 7640 candles), last value is ~14'540:
Yahoo! Finance reports a latest value of that moving average of 16'235:
While I think I understand the technical strategy, the above findings don't look like I can draw reliable conclusions from the graphs calculated. Which means, math algorithms need adjustments.
I don't know what do you mean by "reliable and usable moving averages", but all the methods are pure mathematical operations with all the pros and cons of this fact. You may like it or not, but there is nothing to change. There is nothing to "adjust".
Also I don't know what's the algorithm behind Yahoo finances. Here is two different VIDYA
s from TradingView on all the data they have. As you can see both lines are pretty close to what is drawn on your second chart. You can also investigate their implementation and Yata
s implementation.
Perhaps we can at least agree that YaTa is typically used for analysis of trading prices. Here "reliable" means that calculated averages depend only on prices in history (and sometimes trading volume), not on unrelated factors like the length of price history looked at.
Another thing is that many market participants look at such moving averages for their analysis and following on that, their trading decisions. Which means, a moving average calculated by YaTa should be the same as what other analysis softwares do. If professional trader Smith at Goldman Sachs sees EMA200 at a particular price, you and me should see the very same. This way these averages get useful.
Yahoo calculates averages right in the browser. I tried to decipher that, but it's heavily obfuscated. A pity, because that is the only software I've seen so far which calculates a Vidya which makes sense. By nature, moving averages have crossing points with the not averaged price, which implementations of TradingView and YaTa don't.
Looking around even more, TA-Lib appears to be kind of a gold standard for technical analysis. It does have extra code for dealing with different history lengths:
4.2 Unstable Period
Some TA functions provides different results depending of the "starting point" of the data being involve. This is often referred as a function having memories. An example of such function is the Exponential Moving Average. It is possible to control the unstable period (the amount of data to strip off) with _TASetUnstablePeriod and _TAGetUnstablePeriod.
I've yet to find out what these two functions do.
Notably, TA-Lib features a whole lot of moving averages, but not Vidya. It does support TRIMA and EMA, so I currently try to get the above test code working with that library, in order to compare results.
Perhaps we can at least agree that YaTa is typically used for analysis of trading prices.
No. I personally use moving averages for other technical purposes, that does not have any connection with trading at all. Moving average itself is a pure mathematical construction, which has nothing related to economics or trading. Therefore it does not give any guarantees except mathematical consistency.
Here "reliable" means that calculated averages depend only on prices in history (and sometimes trading volume), not on unrelated factors like the length of price history looked at.
This is totally wrong. The core idea behind EMA is to use all historical data:
An exponential moving average (EMA), also known as an exponentially weighted moving average is a first-order infinite impulse response filter that applies weighting factors which decrease exponentially. The weighting for each older datum decreases exponentially, never reaching zero.
So what is unstable period for this kind of MA? It depends on target precision you need. For someone it's enough 5%, for others - 0.1%.
Again this library gives no guarantees, that values calculated using Yata
will be exactly the same, as somewhere else, because there are many other factors, that may affect on final result.
For example, what values are used, when there is no actual values in the history? Zero? Previous value? NaN? Or period just skipped? Each variant may (and with EMA-family will) give different results.
Again, what values are used before the very first historical value? In Yata
it is guaranteed, that each method
and indicator
built with concept, that previous values is an infinite series of values equal to first historical value (that's why you need to provide first values when building method or indicator). Other libraries may give other guarantees. Some of them use zero values in such cases (AFAIK, TradingView).
Some MAs have fixed unstable period
equal to it's length (SMA, WMA, MMA, etc). So this question is not so important for them. But again, EMA uses all the history by it's definition. Calculation of unstable period for this kind of methods/indicators is not covered by this library (yet).
Again this library gives no guarantees, that values calculated using Yata will be exactly the same, as somewhere else
Somehow you try to explain this crate is useless. Even in the technical world users usually want matching results across different ways of computing data by particular algorithms.
Anyways, here's code for doing moving averages with both, YaTa in Rust and TA-Lib in C, in the same folder:
The bolder among us unpack it and just run ./compare.sh
. Else doing make
and cargo build
separately and fixing what's missing is a better idea.
About that _TASetUnstablePeriod mentioned earlier, it's described here: https://ta-lib.github.io/d_api/ta_setunstableperiod.html It describes what the issue with EMA/DEMA/TEMA is and how one can set the unstable period for these averages. TA-Lib skips results during the unstable period, one gets only sufficiently stable results.
I was about to write an evaluation of comparison results. As you now stated correctness doesn't matter here, that's probably pointless.
About that _TASetUnstablePeriod mentioned earlier, it's described here: https://ta-lib.github.io/d_api/ta_setunstableperiod.html It describes what the issue with EMA/DEMA/TEMA is and how one can set the unstable period for these averages. TA-Lib skips results during the unstable period, one gets only sufficiently stable results.
Now after I told you three times right about the same thing you found it somewhere else. Great.
So, what is your actual suggestions? You want me to add another skip
implementation just because... it was made on C lib?
I was about to write an evaluation of comparison results. As you now stated correctness doesn't matter here, that's probably pointless.
I didn't tell that.
@amv-dev Hi! How can I contact you?
@amv-dev Hi! How can I contact you?
you can write a letter to amv-dev@protonmail.com
When inspecting some suspect behavior in my application it turned out moving average values depend on the calculation length. For example, calculating an EMA20 over 500 numbers gives a different last moving average value than calculating the same average over only its last 200 numbers.
Being a programmer, I wrote some code to investigate this:
Lo' and behold, this code confirms my observation. The list this code prints out shows good accuracy for some moving averages ...
... still reasonable accuracy for others ...
... and not really usable numbers (deviation > 1%) for some:
My current working hypothesis is that these mathematical shortcuts taken when calculating moving averages sum up numerical inaccuracies, thousands of tiny errors end up in substantial ones. While calculating the next value from the previous one is certainly faster, accurate results would require to calculate "fresh" values from values in the moving average window, ignoring the previous moving average value.