Machine learning in trading: theory, models, practice and algo-trading - page 1381
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Yes, not him, butAleksey Vyazmikin. My mistake.
Scale, yes, of course, but they do not cease to be prices).
I came to the conclusion long time ago that the price is not a f-from and do not understand what, so I'll just lose the information, and the result will be worse.
On the issue of scaling ... I can not solve the problem, I have no ideas. Maybe you can give me a hint?I came to the conclusion a long time ago that the price is not a f-from and does not understand what, so even if you prohibit the transformation, it will just be a loss of information and everything, as a consequence the deterioration of the result
I can't solve the problem, I have no ideas. Maybe you can give me a hint?Have you ever chewed the raw chart?
It will help you in about ten years.)
I came to the conclusion a long time ago that the price is not a f-e and does not understand what, so even if you prohibit the conversion, it will just lose information and everything, as a consequence, the deterioration of the result
I can't solve the problem, I have no ideas. Maybe you can give me a hint?In the code, which was published the other day, there is a line with scaling, before the NS to submit.
For the NS of 20 inputs. The ratio (1000) can be anything the NS likes. So on.
In the code I posted the other day, there is a line with scaling before the NS is fed.
For NS of 20 inputs. The ratio (1000) can be whatever the NS likes. Something like this.
so this is 20 increments multiplied by 1000
so that's 20 increments multiplied by 1000
What increments? This is a scaled sequence of prices, in this case - Close. All the ratios in the series remain unchanged.
SD.history[i-j][c.c]/SD.history[i][c.c]
The i-th clause price on the i-th is the returnee
you get 20 returnees with lag from 1 to 20, then multiply by 1000 for some reasonDivide
SD.history[i-j][c.c]/SD.history[i][c.c]
The i-th clause of the i-th price is a return
get 20 returns with lag from 1 to 20, then multiply by 1000 for some reasonI'm not familiar with returns. I don't know this terminology.) It's simply moving the coordinate system to zero and scaling.
We multiply by 1000 so that the numbers on the NS input are at a normal scale (not small). )) Set the coefficient as desired, depending on the dynamic range of the NS or forest inputs.
I don't know about returnees. I do not know this terminology.) This is a simple transfer of the coordinate system to zero and scaling.
We multiply by 1000, so that the numbers at the input of the NS are in normal scale (not small). )) Whatever coefficient you want, set it that way, depending on the dynamic range of the NS or forest inputs.
When you divide one price by a nearby one with a lag, it is a retournee, i.e. the price increase with a given lag.
When you divide one price by a nearby price with a lag, it is a retournee, i.e. a price increment with a given lag.
The whole series is divided by Close(0), i.e. the zero point of the series is always 1 - we bring it to the same scale for all samples. Subtract 1 from each term of the series - bring the series to the origin. Multiply by the scaling factor (1000), to match the range with the NS input.
(No, don't like it, don't use it).
The entire row is divided by Close(0), i.e. the zero point of the row is always 1. Subtract 1 from each member of the row - move the row to the origin. Multiply by the scaling factor (1000), to match the range with the NS input.
Nah, don't like it, don't apply it).
no, I'm just saying that they are returns, instead of -1 you can put log(), the same will be, i.e. logreturns. This loss of information is very significant, because you only have 20 of them.