Predicting the future with Fourier transforms - page 3

New comment
 
m_keeper:

I am now trying to identify the signs of false forecasts

False forecasts can be identified by an increase in the RMS error on the last, "end" bars. Taking the first available period and extrapolating it forward is not a forecast. It is simply an extension of the periodic component that was - forward. Sort of like having half of the rear end drawn to the front of a moving car.

To try to make a prediction, it is necessary to find a series of resonances in the not too distant past. In other words, a certain amount of bars in the past is run and each time it is drawn ahead, and the forecast error is calculated based on already known historical data. Then the period is changed and the run is repeated again. Again the forecast error is calculated. Those periods with minimal error are considered working forecast periods. Upon appearance of new data, the error is again calculated. Depending on the error, the period is again adjusted to the current forecast. I'm just trying to explain it on figures.

To make it short. We run different periods with certain steps on a relatively small sample of data in the past. All the time the RMS of the extrapolation is calculated. We find the period that correlated most well in the not too distant past and that's when we take it as a working period. This is the first step in making a forecast. Then there is a whole series of steps...


Here is one of the resonances in the figure above. But this does not mean anything yet.

You need to do a whole series of prognoses, and by minimum RMS to choose the most well-correlated one.

In general, without spacetime non-linearities, i.e. their constant curvatures (time is compressed and amplitude increases, amplitude is compressed and time increases - like at night for example), it is next to impossible to receive a decent forecast.


 

Ran the tester for March on M15

n=10

InPast=300

Futur=300

Gladkost=1

In most cases we can believe at least for a day


Added RC pre-processing with variable level filtering to attenuate high frequencies

at the tail end of the window. This did not change anything in principle, but in theory it was better (what is it - you can see it with Gladkost=0)


The prognosis changes abruptly if there is a sharp dip or rise at the beginning or end of the window.

Let's say a step is formed - the filter sees it as a low frequency,

when in 10 bars an opposite step is formed and this market change will be filtered out as a high-frequency one

I think this can be dealt with by working not directly with prices but with a moving average

say with the MA(20) and then just predict the 10 bars of lag that the MA will give


As for the SCR, the idea is correct

You can run two indicators, one predicts the last 100 bars known, and the second one predicts 100 bars into the future

and measure the RMS between the indicators on the last 100 bars, we must try.

The "non-linearities of space-time" - aren't the equi-column bars supposed to solve this problem?

I've never worked with them before. Do you think it will help?

Files:
fft_and_future_2.mq4  6 kb
 
m_keeper:

The "nonlinearities of space-time" - aren't equi-capacity bars supposed to solve this problem?

I've never worked with them. Do you think it'll help?

Equi-bars are sort of "warmer", but not quite yet. Here in the chart I cited, the left yellow half-wave is moving intensely, the amplitude is large, but in a short time. The right green part due to increased resistance - the path is long, and the time took more, and the amplitude is reduced. So they are not symmetrical in time. In fact, for there to be a better match, the period on the left side should be shorter, and the period on the right side should be longer. That is, we must also take into account the length of all price increments, like the length of a rope, and this rope is bent in many places.

And in fact the length of the red and blue forecast part depends on how it will be bent or stretched. The reversal is likely, but the exact spot, i.e. time and especially the position of the price will be quite different. And we draw what we already had.


And another thing. Let's say there are periods when big "fishes" trade, like banks and other "toughs". They do not trade on 15-minute timeframes, but usually consider minimal daily data and make decisions based on it. And the small guys like us trade on the hourlies, up to ticks. So, such a petty half-hearted fuss in an attempt to earn at least 3 kopecks. If in the recent past there have been spikes of large "fish", i.e. lower frequency harmonics, then when they start to appear again, despite the forecast in a short interval - a large wave may just blow away small ones. So in fact you have to consider many frequencies of their phase coincidence or phase contradiction, and that plus slopes, resistances, compression-stretching. In fact, this is for the technique of the future, where you imagine what you need to calculate and a computer will do it all at once. Now we will have to cram it all in with our fingers, pressing buttons and move slower than a turtle, using a lot of energy... And the guys at this 666 - forex, will only laugh and line their pockets. Six is spinning, spinning, you want to take off, make money, and bam, and you're off. The six shows the trajectory of the movement. In Forex, it costs nothing to lose 3 times, so you get 666. I personally have been down even more than once. And those who have achieved and established themselves like Bettera, they are on 7, and these people who created 666 are afraid of them.

 
m_keeper:

Ran the tester for March on M15

Most of the time you can trust for at least a day.

This is strong.

And what if we feed the indicator signal (or rather the difference between the reading and the current price) to the input of the NS?

 

Tell me what's wrong.

Here is the library code

#include <windows.h>
#define EXPORT extern "C" __declspec(dllexport) 

// Прототип экспортной функции...
EXPORT int __stdcall my_func(int i);

BOOL APIENTRY DllMain(HINSTANCE hInst, DWORD dwReason, LPVOID lpReserved)
{
return TRUE;
}

EXPORT int __stdcall my_func(int i)
{
return i;
}

in the indicator I write

#import "tmp3.dll" int my_func(int i);

и
int ghh=1;
int ggg=my_func(ghh);

gives an error

FFT_and_Future EURUSD,M30: cannot call function 'my_func' from dll 'tmp3.dll'(error 127)


Maybe there is some trick here?

I've already tried different things.

 
goldtrader:
m_keeper:

Ran the tester for March on M15

Most of the time you can trust for at least a day.

This is strong.

And what if you feed the indicator signal (more precisely, the difference between the indicator and the current price) to the VS input?

May I answer the question, although it wasn't put to me, since I'm browsing this page.

Actually, the question is not very correct, because there are different networks with different number of inputs and outputs.

There are approximating, classifying and associative ones. With or without a teacher.

But if you assume what the author meant, you can do it. But will the result be satisfactory?

 
m_keeper:

Tell me what's wrong.

Here's the library code

Do you want to make this library __lib_FFT.mq4 as a DLL? Or something else?

 

No, I want to connect the other one, but everything there is written in classes, so rewriting for mq4 is not an option

I tried to compile examples from the forum, but they do not work.

i have Visual studio 6

 
goldtrader: What if you feed the indicator signal (or rather the difference between the reading and the current price) to the NS input?

I think neural networks should be used where you cannot draw conclusions using mathematical, statistical, differential or any other analysis.

Don't make anything from my indicator yet, it's too incomplete.

 
m_keeper:

No, I want to connect the other one, but everything there is written in classes, so rewriting for mq4 is not an option

I tried to compile examples from the forum, but they do not work.

I have Visual studio 6

The "Allow use of DLL" option is enabled, of course? There in MT4, there is an example of how to connect DLL, just for VC++6.

But if it concerns Fourier transformation, why bother with such a complicated thing? I cited the code on the previous page. Although it's not FFT, it's a classical variant, but what's the hurry, if the question is not very sensible so far?

12345678910...55
New comment