В ценах битка в 2017 году есть закономерности, которые будут работать и в 2018 и позже.
Будут ли эти данные полностью определять цену битка в 2018 году?
Нет не будут.
Тренд дает как раз та самая неслучайная компонента. С опозданием и ошибкой эту компоненту можно определить, если предположение, что в данных есть тренд становится более вероятным, чем предположение, что в данных нет тренда.
Коллега, приветствую :). Я написал торгового робота для биржи Bittrex и могу поделится своим опытом:
1) самое главное, что нужно понимать: значение цены — это не чисто случайная величина, а смесь: неслучайная_составляющая + случайная_составляющая.
Отсюда следует, что брать любое среднее можно только от случайных величин => для усреднения данных нужно:
(а) либо выделять данные, в которых изменением неслучайной компоненты можно пренебречь,
(б) либо уметь оценивать неслучайную компоненту и предварительно вычитать ее из данных.
2) Неслучайная компонента — гораздо сложнее случайной. Как правило для учета неслучайной компоненты нужны оценки человека-аналитика (так называемые, «оценки по мнению»).
3) В оценку скользящего среднего я не веру. На мой взгляд, в этой оценке случайная и неслучайная компоненты смешиваются вместе и это приводит только к искажению данных. Плюс в этой оценке участвуют какие-то волшебные числа, которые ниоткуда не следуют. Я верю в стандартное распределение, которые еще никто отменить не смог :).
4) Нужно понимать, на чем робот может вообще зарабатывать / уменьшать потери:
4.1) На случайных колебаний в условиях без тренда (с учетом вероятности появления новых трендов): определяем среднюю цену, покупаем актив ниже этой цены и продаем актив выше этой цены;
4.2) На тренде вверх: покупаем в начале тренда и продаем в конце тренда;
4.3) На тренде вниз: продаем актив, если он есть.
На мой субъективный взгляд, в качестве промышленного языка общего назначения лучше Clojure сейчас ничего нет, учитывая наличие готовых библиотек и средств разработки. А также возможности использования Clojure/ClojureScript для веб-приложений.
А то, что Clojure — это LISP, говорит о том, что, наконец то, то было круто в теории, стало круто на практике :).
Поскольку оба языка Erlang и Elixir компилируют в код Erlang VM, то функции из Erlang либы доступны в Elixir приложении и обратно (насколько я понимаю). Другими словами функцию `dmap_dmap:map` можно вызвать из приложения на Elixir и на Elixir же написать код для воркера :).
Ничего не имею против вашего решения, но действительно ли это решение эквивалентно
нашему?
1) Есть ли ограничение по количеству одновременно запущенных процессов-воркеров?
2) Есть ли остановка в случае креша в любом из воркеров?
3) Есть ли остановка в случае таймаута при ожидании ответа от воркера?
4) Можете привести примеры тестов, которые у нас приведены для `dmap_pmap:map`?
Elixir компилирует в Erlang VM, поэтому на вскидку не совсем понятно, зачем писать отдельное решение для dmap на Elixir, если можно просто использовать готовое решение на Erlang, которое просто синтегрировать со своим Elixir кодом :).
Я отвечал на вопрос: Erlang cluster VS однопоточный вариант на С :).
Что касается тестирования Erlang кластера как кластера, то, да, тестирование тут очень важно. Мы тут не привнесли ничего нового: кластер, который мы поднимаем — стандартный Erlang кластер, для которого бенчмарки, по идее, уже должны быть сделаны другими исследователями до нас :). Вопрос действительно важный, я скину ссылки на эти исследования, если найду.
Спасибо за предложение сравнить Erlang кластер с другими решениями, возможно в будущем мы сделаем такие бенчмарки и опубликуем их (это не тривиальная задача).
Понимаю поинт, однако:
1) Если в Erlang не делать вычислений, о которых известно, что они работают в Erlang медленно, то скорость работы Erlang приложения будет не хуже, чем аналогичного приложения на Java.
2) В Erlang есть проработанный механизм, как подключать код на C. :)
3) Мы не бьемся за проценты от скорости работы приложения. Для нас важнее скорость разработки, простота поддержки и мультиплатформенность.
— Введение в Clojure: alexott.net/ru/clojure/clojure-intro
— Introduction to Clojure: clojure-doc.org/articles/tutorials/introduction.html
— Clojure By Example: kimh.github.io/clojure-by-example/#
— Задачи по Clojure: www.4clojure.com
— Книги по Clojure: rutracker.org/forum/tracker.php?nm=clojure
Я бы вам советовал после вводной статьи по Clojure, прочитать книгу по Clojure. И одновременно с чтением книги пробовать писать код самостоятельно.
Мы раньше использовали Component: github.com/stuartsierra/component
Я видел так же, что люди используют Duct: github.com/duct-framework/duct
Otplike эту задачу успешно решает, одновременно с заходом на многопоточность.
Будут ли эти данные полностью определять цену битка в 2018 году?
Нет не будут.
1) самое главное, что нужно понимать: значение цены — это не чисто случайная величина, а смесь: неслучайная_составляющая + случайная_составляющая.
Отсюда следует, что брать любое среднее можно только от случайных величин => для усреднения данных нужно:
(а) либо выделять данные, в которых изменением неслучайной компоненты можно пренебречь,
(б) либо уметь оценивать неслучайную компоненту и предварительно вычитать ее из данных.
2) Неслучайная компонента — гораздо сложнее случайной. Как правило для учета неслучайной компоненты нужны оценки человека-аналитика (так называемые, «оценки по мнению»).
3) В оценку скользящего среднего я не веру. На мой взгляд, в этой оценке случайная и неслучайная компоненты смешиваются вместе и это приводит только к искажению данных. Плюс в этой оценке участвуют какие-то волшебные числа, которые ниоткуда не следуют. Я верю в стандартное распределение, которые еще никто отменить не смог :).
4) Нужно понимать, на чем робот может вообще зарабатывать / уменьшать потери:
4.1) На случайных колебаний в условиях без тренда (с учетом вероятности появления новых трендов): определяем среднюю цену, покупаем актив ниже этой цены и продаем актив выше этой цены;
4.2) На тренде вверх: покупаем в начале тренда и продаем в конце тренда;
4.3) На тренде вниз: продаем актив, если он есть.
А то, что Clojure — это LISP, говорит о том, что, наконец то, то было круто в теории, стало круто на практике :).
нашему?
1) Есть ли ограничение по количеству одновременно запущенных процессов-воркеров?
2) Есть ли остановка в случае креша в любом из воркеров?
3) Есть ли остановка в случае таймаута при ожидании ответа от воркера?
4) Можете привести примеры тестов, которые у нас приведены для `dmap_pmap:map`?
Elixir компилирует в Erlang VM, поэтому на вскидку не совсем понятно, зачем писать отдельное решение для dmap на Elixir, если можно просто использовать готовое решение на Erlang, которое просто синтегрировать со своим Elixir кодом :).
Что касается тестирования Erlang кластера как кластера, то, да, тестирование тут очень важно. Мы тут не привнесли ничего нового: кластер, который мы поднимаем — стандартный Erlang кластер, для которого бенчмарки, по идее, уже должны быть сделаны другими исследователями до нас :). Вопрос действительно важный, я скину ссылки на эти исследования, если найду.
Спасибо за предложение сравнить Erlang кластер с другими решениями, возможно в будущем мы сделаем такие бенчмарки и опубликуем их (это не тривиальная задача).
1) Если в Erlang не делать вычислений, о которых известно, что они работают в Erlang медленно, то скорость работы Erlang приложения будет не хуже, чем аналогичного приложения на Java.
2) В Erlang есть проработанный механизм, как подключать код на C. :)
3) Мы не бьемся за проценты от скорости работы приложения. Для нас важнее скорость разработки, простота поддержки и мультиплатформенность.
Erlang — язык со своими плюсами и минусами.
Некоторые задачи решаются в Erlang очень красиво, а следовательно — быстро и надежно.