Machine learning in trading: theory, models, practice and algo-trading - page 2368

New comment
 
Vladimir Perervenko:
I accidentally read an article with a statement that surprised me.Predictors, responses and residuals: What really needs to be normally distributed?

Passage about linear regression gives out the author as a person unfamiliar with theorist/matstat. Standard variant of assumptions for LR - inputs are deterministic (e.g. time moments) and outputs distribution depends on noise distribution (and each output will have its expectation, depending on input and different from others).

Another option - if inputs and outputs are taken from some joint distribution, the condition of applicability of linear regression model is even stricter here - a COUNTRY (bivariate, at least) distribution must be normal. Without this assumption, you can forget about MNC.

 
Vladimir Perervenko:
I accidentally read an article with a statement that surprised me.Predictors, responses and residuals: What really needs to be normally distributed?

A few quotes:

"Many scientists are concerned about the normality or non-normality of variables in statistical analysis. The following and similar views are often expressed, published, or taught:

  • " If you want to do statistics, then everything has to be normally distributed .
  • " We normalized our data to fit the assumption of normality .
  • " We log-transformed our data because it had a highly skewed distribution .
  • "After we fitted the model, we checked the homoscedasticity of the residuals .
  • " We used a non-parametric test because our data did not meet the assumption of normality .

Because of the networks' requirement for data normalization, a normal distribution, and a bunch of additional adjustments, I switched to tree-like systems. They remember the data as it is.

And after the name of AI (in one of the articles for the general public) as a database based on neural networks or trees, began to treat them exactly as databases, which in a cell (list) can store several very similar lines, ie at the same time and generalize. When you divide the tree to the last example, the cells will have only the same rows without generalization - i.e. you will get a pure database. We still need to generalize, so we stop dividing leaves early.

 
Vladimir Perervenko:

This is not about print but about generators and iterators.

Vladimir! Can you explain

If this package can speed up my code without changing this code, it's very interesting for me, just give me a working example please

 
mytarmailS:

Vladimir! Can you give an explanation of

If this package can speed up my code without changing this code, it's very interesting for me, just give me a working example please

There are a lot of examples in this package. Can't you find any? Here

> #  A generator statement creates a generator factory. The
> #  following generator yields two times and then returns `"c"`:
> generate_abc <- generator(function() {
+   yield("a")
+   yield("b")
+   "c"
+ })
> 
> #  Or equivalently:
> generate_abc <- generator(function() {
+   for (x in letters[1:3]) {
+     yield(x)
+   }
+ })
> 
> #  The factory creates generator instances. They are iterators
> #  that you can call successively to obtain new values:
> abc <- generate_abc()
> abc()
[1] "a"
> abc()
[1] "b"
> 
> #  Once a generator has returned it keeps returning `exhausted()`.
> #  This signals to its caller that new values can no longer be
> #  produced. The generator is exhausted:
> abc()
[1] "c"
> abc()
exhausted
> 
> #  You can only exhaust a generator once but you can always create
> # new ones from a factory:
> abc <- generate_abc()
> abc()
[1] "a"
> 
> 
> #  As generators implement the coro iteration protocol, you can use
> #  coro tools like `loop()`. It makes it possible to loop over
> #  iterators with `for` expressions:
> loop(for (x in abc) print(x))
[1] "b"
[1] "c"
> 
> #  To gather values of an iterator in a list, use `collect()`. Pass
> #  the `n` argument to collect that number of elements from a
> #  generator:
> abc <- generate_abc()
> collect(abc, 1)
[[1]]
[1] "a"

> 
> #  Or drain all remaining elements:
> collect(abc)
[[1]]
[1] "b"

[[2]]
[1] "c"

> 
> 
> #  coro provides a short syntax `gen()` for creating one-off
> #  generator _instances_. It is handy to adapt existing iterators:
> numbers <- 1:10
> odds <- gen(for (x in numbers) if (x %% 2 != 0) yield(x))
> squares <- gen(for (x in odds) yield(x^2))
> greetings <- gen(for (x in squares) yield(paste("Hey", x)))
> 
> collect(greetings)
[[1]]
[1] "Hey 1"

[[2]]
[1] "Hey 9"

[[3]]
[1] "Hey 25"

[[4]]
[1] "Hey 49"

[[5]]
[1] "Hey 81"

> 
> 
> #  Arguments passed to generator instances are returned from the
> # `yield()` statement on reentry:
> new_tally <- generator(function() {
+   count <- 0
+   while (TRUE) {
+     i <- yield(count)
+     count <- count + i
+   }
+ })
> tally <- new_tally()
> tally(1)
[1] 0
> tally(2)
[1] 2
> tally(10)
[1] 12
 
Vladimir Perervenko:

It's not about print, it's about generators and iterators.

Really? ))

 
Maxim Dmitrievsky

Are you going to publish a new article on pair trading based on MO in the future?

 
Evgeni Gavrilovi:

Are you going to publish a new article on MO-based pair trading in the future?

Yes, there hasn't been time yet. Articles take a lot of time to think through their plan, then to program them

 
Maxim Dmitrievsky:

Yes, there hasn't been time yet. Articles require a lot of time to think through their plan, then to program

I have a lot of time to think over their plan and then to program them. Can you also add to the article a script which opens orders directly in Python according to this strategy?

 
Evgeni Gavrilovi:

Can you then add to the article a script that opens orders directly in Python according to this strategy?

Yes, you can. But it would be more convenient as an Expert Advisor.

 
Maxim Dmitrievsky:

Yes, you can. But it's more convenient as an advisor, isn't it?


There's an article on hubra https://m.habr.com/ru/post/549202/, what do you think? Can something practical be done? I am interested in your (and other mathematicians') expert opinion.
1...236123622363236423652366236723682369237023712372237323742375...3674
New comment