Машинное обучение в трейдинге: теория, модели, практика и алготорговля - страница 2367

 
Vladimir Perervenko:

Не только apply. Я чаще пользую foreach, можно распараллелить не переделывая код... Иногда полезен итератор, попробуйте

Удачи

Спасибо!

 
mytarmailS:

Спасибо!

А что такое   generate_abc ? я так и не понял потому что пример дает ошибку

library(coro)
> abc <- generate_abc()
Error in generate_abc() : could not find function "generate_abc"
[Удален]  

Все эти операции есть в питоне

print([x for x in range(50)])
 
Это всё началось в лиспе и особенно развито в функциональном программировании, элементы которого есть как в R, так и в питоне.
 
Прочел случайно статью с утверждением для меня удивительным. Predictors, responses and residuals: What really needs to be normally distributed?

Несколько цитат:

"Многие ученые обеспокоены нормальностью или ненормальностью переменных в статистическом анализе. Следующие и подобные мнения часто выражаются, публикуются или преподаются:

  • «  Если вы хотите вести статистику, тогда все должно быть нормально распределено  ».
  • «  Мы нормализовали наши данные, чтобы соответствовать предположению о нормальности  ».
  • «  Мы преобразовали наши данные в журнал, поскольку они имели сильно искаженное распределение  ».
  • «  После того, как мы подобрали модель, мы проверили гомоскедастичность остатков  ».
  • «  Мы использовали непараметрический тест, поскольку наши данные не соответствовали предположению о нормальности  ».

И так далее.  Я знаю, что это сложнее, но все же кажется, что нормальное распределение - это то, что люди хотят видеть повсюду, и что нормальное распределение вещей открывает дверь к чистой и убедительной статистике и сильным результатам.  Многие люди, которых я знаю, перед анализом регулярно проверяют, нормально ли распределяются их данные, а затем они либо пытаются «нормализовать» их, например, с помощью логарифмического преобразования, либо соответствующим образом корректируют статистический метод на основе частотного распределения своих данных.  Здесь я исследую это более внимательно и покажу, что предположений о нормальности может быть меньше, чем можно было бы подумать."

Дальше обоснование мысли и вывод:

" Почему люди до сих пор нормализуют данные?

Еще одна загадочная проблема заключается в том, почему люди по-прежнему склонны «нормализовать» свои переменные (как предикторы, так и ответы) до подгонки модели.  Почему эта практика возникла и стала преобладать, даже если нет никаких предположений, которые могли бы ее вызвать?  У меня есть несколько теорий на этот счет: незнание, склонность следовать статистическим кулинарным книгам, распространение ошибок и т. Д.
Два объяснения кажутся более правдоподобными: во-первых, люди нормализуют данные, чтобы линеаризовать отношения.  Например, с помощью логарифмического преобразования предиктора можно подобрать экспоненциальную функцию, используя обычный механизм наименьших квадратов.  Это может показаться нормальным, но тогда почему бы не указать нелинейную взаимосвязь непосредственно в модели (например, с помощью соответствующей функции ссылки)?  Кроме того, практика логарифмического преобразования ответа может привести к серьезным артефактам, например, в случае данных подсчета с нулевым счетчиком (O'Hara & Kotze 2010).
Вторую правдоподобную причину «нормализации» практики предложила моя коллега Кэтрин Мертес-Шварц: возможно, это связано с тем, что исследователи пытаются решить проблему, и их данные были собраны очень слипчиво и неравномерно.  Другими словами, очень часто один работает с данными, которые имеют большое количество наблюдений, агрегированных в определенной части градиента, в то время как другая часть градиента относительно недопредставлена.  Это приводит к искаженным распределениям.  Преобразование таких распределений приводит к кажущемуся регулярному распространению наблюдений по градиенту и устранению выбросов.  На самом деле это можно сделать с добрыми намерениями.  Однако это тоже в корне неверно."

Для меня это утверждение (шокирующее?) , не могу подобрать подходящее слово. Но буду учитывать в дальнейшем

Predictors, responses and residuals: What really needs to be normally distributed?
Predictors, responses and residuals: What really needs to be normally distributed?
  • www.r-bloggers.com
[This article was first published on Are you cereal? » R , and kindly contributed to R-bloggers]. (You can report issue about the content on this page here)
 
Maxim Dmitrievsky:

Все эти операции есть в питоне

Это не о print а о генераторах и итераторах.

 
Vladimir Perervenko:
Прочел случайно статью с утверждением для меня удивительным. Predictors, responses and residuals: What really needs to be normally distributed?

Пассаж про линейную регрессию выдаёт автора, как человека незнакомого с теорвером/матстатом. Стандартный вариант предположений для ЛР - входы детерминированы (например, моменты времени), а распределения выходов зависят от распределения шума (и каждый выход будет иметь своё матожидание, зависящее от входа и отличное от других).

Другой вариант - если входы и выходы берутся из какого-то совместного распределения, то здесь условие применимости модели линейной регрессии ещё жёстче - нормальным должно быть СОВМЕСТНОЕ (двумерное, как минимум) распределение. Без этого допущения про МНК можно забыть.

 
Vladimir Perervenko:
Прочел случайно статью с утверждением для меня удивительным. Predictors, responses and residuals: What really needs to be normally distributed?

Несколько цитат:

"Многие ученые обеспокоены нормальностью или ненормальностью переменных в статистическом анализе. Следующие и подобные мнения часто выражаются, публикуются или преподаются:

  • «  Если вы хотите вести статистику, тогда все должно быть нормально распределено  ».
  • «  Мы нормализовали наши данные, чтобы соответствовать предположению о нормальности  ».
  • «  Мы преобразовали наши данные в журнал, поскольку они имели сильно искаженное распределение  ».
  • «  После того, как мы подобрали модель, мы проверили гомоскедастичность остатков  ».
  • «  Мы использовали непараметрический тест, поскольку наши данные не соответствовали предположению о нормальности  ».

Из за требования сетей к нормализации данных, нормальному распределнию, и куче доп. настроек - перешел на деревовидные системы. Они запомнят данные как есть.

А после наименования ИИ ( в одной из статей для простых людей ) как базы данных на основе нейросетей или деревьев, стал относиться к ним именно, как к базам данных, которые в 1 ячейке(листе) могут хранить несколько очень похожих строк, т.е. заодно и обобщать. При делении дерева до последнего примера, в ячейках будут только одинаковые строки без обобщения - т.е. получится чистая база данных. Нам все таки нужно обобщать, поэтому останавливаем деление листьев пораньше.

 
Vladimir Perervenko:

Это не о print а о генераторах и итераторах.

Владимир! можете дать пояснения по   

Если этот пакет может ускорить мой код без изменений этого кода то это очень интересно для меня, только дайте рабочий пример пожалуйста 

 
mytarmailS:

Владимир! можете дать пояснения по   

Если этот пакет может ускорить мой код без изменений этого кода то это очень интересно для меня, только дайте рабочий пример пожалуйста 

В пакете море примеров. Не можете найти? Приведу

> # 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