Это не мешает разработчикам складывать данные в кучу и пересчитывать все с нуля при поступлении нового элемента. Так что первый пример в статье он, скорее, как "антигерой"
Данные заранее не известны. И не хранятся вообще нигде. Вся суть поточных вычислений в том, что данные обрабатываются при поступлении. Каждое входное значение имеет собственную временную метку. Для избежания ошибок «заглядывание в будущее» вычисления строго выполняются только для текущего момента времени, или условно текущего если это симуляция. Таким образом, учитывая особенности скользящего среднего, о которых говорит выше @fivehouse
Не было цели определить погрешность, да и данные, с которыми работает алгоритм, не имеют большой точности вычислений, ограничиваются двумя тремя разрядами после запятой. Так что влияние погрешностей крайне мало.
На JS нельзя сдвинуть указатель на первый элемент массива напрямую, придется записывать в массив все поступающие значения и отдельно хранить индекс "начала" и сдвигать его при добавлении элемента. Получается в памяти будут вообще все данные.
А написание структуры, которая отличается от стандартного массива и реализует какую-то более продвинутую логику, сопряжено с использованием `new` оператора, что убьет производительность.
Это один из хороших вариантов решения проблемы. Спасибо. И как и любой "ускоряющий" механизм, дает нагрузку на память. (К сожалению не смог найти картинку где диаграммами показано что увеличение производительности чаще всего приводит к увеличению потребляемой памяти)
Вы правы, но не совсем. Текущая реализация это и есть кольцевой буффер. Вопрос в том, как сделать ее быстрее, а именно без использования shift операции. Либо же вообще отказаться от такого подхода и каким-то другим образом хранить числа для атомарных перерасчетов суммы.
Пошёл по модели JetBrains, считаю, что граалей не существует и имея софт любого уровня потребуются годы, чтобы разобраться с самим рынком. Это не типичный опенсорц, здесь аудитория имеет глубокую вовлечённость и уже в первые дни люди что-то дополняют и добавляют. Рассчитываю на появление большего числа плагинов, что ускорит и мои личные разработки. А появление новых потребителей раскроет какие то баги или нюансы, остававшиеся в тени
Хороший вопрос спасибо! Правда ответ получится очень долгим, но постараюсь коротко. Проблему типизации решает TypeScript. Проблему скорости решает JIT компилятор. Мы сравнивали с питоном, со «стандартными» либами по индикаторам и тоже были быстрее. При встрече на конференции Blockchain life с представителями подобной платформы на C#, я задал им вопрос как они делают оптимизацию, на что мне ответили, что брутфорсят рандомом, я спросил почему не генетика — сказали долго. Ну у меня не долго получилось. За счет того, что я все писал сам под очень узкую специализацию. Это про технику. Потом вы интересовались почему же JavaScript — одна из самых важных причин, это возможность работы в браузере, ну и вторая это комьюнити Front-End, которое имеет интерес к торговле, но не имеет желание изучать C# или Python, я увидел тут свою аудиторию и хочу ее захватить, как свободный кусочек рынка. Например такой ответ :)
И кстати понятно почему вы так думаете, про лопаты, те у кого получилось не орут об этом на каждом углу. А те у кого не получилось орут. Моя особенность в том, что мне приходится говорить о том, что у меня получилось, потому что я все таки систему разработки хочу продвинуть/продать.
Хоть статья и не об этом, вы можете посмотреть стратегии которые я опубликовал. Там есть вся статистика если вам интересно. Вот ссылка. Но это действительно больше для примера, и речь не идет о том что вы бездумно это включите и деньги польются рекой. Такое было бы глупо публиковать. Речь про то, что это постоянно нужно поддерживать и исследовать, чтобы оно работало. Например стратегии не живут больше 2х недель в основном после оптимизации, тк рынок успевает измениться. Ну и прочие нюансы, к которым люди приходят которые этим занимаются. Можно отдельную статью про это написать :)
Это было бы справедливо, если бы я конкретную стратегию опубликовал и рецепт. Это статья про систему, которая в итоге получилось. А те стратегии которые приносят деньги, я не публикую, это уже моя личная разработка. Посыл поста был такой, что и вы можете попробовать себе что-нибудь запрограммировать.
Не уверен, что вы поняли мой посыл. Но может это конечно моя вина (первая статья все таки)… Обратите внимание на строки
Утверждение что event обработан если он имеет флаг defaultPrevented и его распространение прервано — не верно.
В качестве пояснения, приведу пример. Перехватить CTRL+F без preventDefault не получится. Таким образом if( event.defaultPrevented ) return не гарантирует состояния обработанности. — Это первое.
До картинки вы похоже не дочитали про кросбраузерность использоваться символьного представления клавиши… — это второе…
Ну и пожалуй в коде какие-то проблемы…
И даже если ваш приведенный пример кода правильно написать — простым в дебаге и понятным, от этого он не становится. Не говоря уже про рефакторинг такого и масштабируемость
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Это не мешает разработчикам складывать данные в кучу и пересчитывать все с нуля при поступлении нового элемента. Так что первый пример в статье он, скорее, как "антигерой"
Данные заранее не известны. И не хранятся вообще нигде. Вся суть поточных вычислений в том, что данные обрабатываются при поступлении. Каждое входное значение имеет собственную временную метку. Для избежания ошибок «заглядывание в будущее» вычисления строго выполняются только для текущего момента времени, или условно текущего если это симуляция. Таким образом, учитывая особенности скользящего среднего, о которых говорит выше @fivehouse
Не было цели определить погрешность, да и данные, с которыми работает алгоритм, не имеют большой точности вычислений, ограничиваются двумя тремя разрядами после запятой. Так что влияние погрешностей крайне мало.
Все, понял, индекс цикличный просто. Супер :)
На JS нельзя сдвинуть указатель на первый элемент массива напрямую, придется записывать в массив все поступающие значения и отдельно хранить индекс "начала" и сдвигать его при добавлении элемента. Получается в памяти будут вообще все данные.
А написание структуры, которая отличается от стандартного массива и реализует какую-то более продвинутую логику, сопряжено с использованием `new` оператора, что убьет производительность.
Это один из хороших вариантов решения проблемы. Спасибо. И как и любой "ускоряющий" механизм, дает нагрузку на память. (К сожалению не смог найти картинку где диаграммами показано что увеличение производительности чаще всего приводит к увеличению потребляемой памяти)
Указатель в массиве на 0й элемент вы имеете в виду? Если нет, приведите пример реализации абстрактно или на JS
Вы правы, но не совсем. Текущая реализация это и есть кольцевой буффер. Вопрос в том, как сделать ее быстрее, а именно без использования shift операции. Либо же вообще отказаться от такого подхода и каким-то другим образом хранить числа для атомарных перерасчетов суммы.
Пошёл по модели JetBrains, считаю, что граалей не существует и имея софт любого уровня потребуются годы, чтобы разобраться с самим рынком. Это не типичный опенсорц, здесь аудитория имеет глубокую вовлечённость и уже в первые дни люди что-то дополняют и добавляют. Рассчитываю на появление большего числа плагинов, что ускорит и мои личные разработки. А появление новых потребителей раскроет какие то баги или нюансы, остававшиеся в тени
В качестве пояснения, приведу пример. Перехватить CTRL+F без preventDefault не получится. Таким образом if( event.defaultPrevented ) return не гарантирует состояния обработанности. — Это первое.
До картинки вы похоже не дочитали про кросбраузерность использоваться символьного представления клавиши… — это второе…
Ну и пожалуй в коде какие-то проблемы…
И даже если ваш приведенный пример кода правильно написать — простым в дебаге и понятным, от этого он не становится. Не говоря уже про рефакторинг такого и масштабируемость