Ну наверное больше десятка видел статей про алготрейдинг с использованием только индикаторов. А из фигур видел только один урок по поиску чего-то похожего на ГиП, но который находил не далеко не все ГиП, а только в небольшом окне из нескольких свечей. И дальше не было никакого алгоритма с бектестами.
Я полгода назад искал в гугле алготрейдинг с фигурами, но попадается либо просто базовое неформализованное описание фигур без алгоритма, либо алготрейдинг с индикаторами. Статью на Хабре, про которую вы говорите, не находил.
Меня интересуют фигуры не сами по себе, а с точками входа и стопами за линии поддержки. Если фигура сработала, то заработал, если нет - закрылся по маленькому стопу. В итоге в среднем можно неплохо зарабатывать, мне кажется. По крайней мере, некоторые курсы по трейдингу так учат. И их авторы побеждают на турнирах и ЛЧИ с сотнями процентов доходности за несколько месяцев. Но они торгуют руками, попыток сделать такое в алгоритмах я не видел.
То, что рынок - разводняк, не спорю. Скорее всего, им крутят большие дяди с огромными капиталами, провоцируя толпу на выгодные для них действия, которые ведут к перетеканию денег от толпы к ним. Должны быть какие-то правила, по которым они действуют, инициируют движения, которые психологически заставляют толпу продавать и покупать тогда, когда это выгодно им. Если разгадать хотя бы их часть, можно к ним присоединиться и тоже себе часть этого потока забрать. Я думаю, это возможно, но не сводится к простым индикаторам. И как только заметная для них часть потока начнёт утекать посторонним, они эти правила усложняют, поэтому старая информация в интернете и книгах не работает или становится неполной.
Везде вижу уроки, что в алготрейдинге используют только тупые индикаторы. Но никогда не слышал, чтобы кто-то пытался сделать алгоритмы, которые торгуют те же идеи, что и люди: фигуры типа флагов, головы и плечей, бэтменов, волн Эллиотта или Вульфа и т.п..
И свечные модели, всякие price action тоже в алгоритмах не видел, хотя то, что рассказывают на Ютубе, вроде неплохо формализуется на первый взгляд. Конечно наверняка большинство - это инфоцыгане, но бэктест бы это сразу показал.
Уже давно вынашиваю идею создания своего языка для хранения и обработки данных - чего-то типа убийцы JSON, protobuf, flatbuffers, TOML и SQL в одном флаконе. Думал, как делать JIT для него. Хотел что-то легковесное, при этом кроссплатформенное, думал делать своё: IR на основе ARM64 и упрощённую аллокацию регистров. И тут вы как раз такое сделали, да ещё и с человеческим лицом. Теперь как руки дойдут до JIT, буду знать, куда смотреть.
А поддержка SSE для процессоров без AVX планируется? У меня несколько таких девайсов есть, причём два из них относительно свежие, например, мини-ПК на Celeron N5095. Ещё есть VPS, где только SSE2 вроде или SSE3 - не выше.
В РФ мало знать английский, надо ещё умудриться работать в условиях санкций. Конечно проще, если рассматривать релокацию. Я язык знаю, но уезжать не готов, а с удалёнкой сложнее.
А можно поставить Coolify так, чтобы сборка шла локально, а на VPS только само приложение? И захостить на самой дешёвой VPS 512 МБ ОЗУ и 1 vCPU, которой более чем достаточно для запуска всех моих приложений?
Или может есть аналог Coolify, если он так не может?
В TS с тем же успехом можно сделать аргумент типа number|string|object. И в контексте тех же дженериков те же сбросы оптимизированного кода происходят, в отличие от шаблонов C++, где создаётся специализированная для типа оптимизированная функция. И наоборот, можно сам JS писать так, чтобы не допустить такой ситуации.
TS сам по себе не влияет на производительность, но может быть инструментом, который поможет своими подсказками и ограничениями упорядочить типы в коде, чтобы не только избежать багов в коде, но и избежать ситуации, когда V8 сбрасывает оптимизированный код. Всё равно это задача того, кто пишет код, которую он должен держать в уме, ограничивая типы.
У меня немало проектов с фронтендом, но из всего перечисленного в статье использую только TypeScript. И не понимаю, что у вас там за дженерики на дженериках и зачем они?
Другое дело C++, там можно нагородить многоэтажных и сложных шаблонов ради того, чтобы потом всё заинлайнилось и оптимизировалось компилятором, сгенерировав наиболее оптимальный код алгоритма или структуры данных для каждого типа.
Но в экосистеме JS типы TS - просто ограничения, проверки и подсказки, не влияющие на производительность. Не вижу смысла усложнять.
Я пытаюсь сделать именно СУБД с таблицами и с запросами по одной таблице - хотя бы уровня SELECT без JOIN'ов и GROUP BY по функционалу - сам язык SQL для этого необязательно делать. Каждая таблица - это директория с набором файлов-сегментов типа 0.seg, 1.seg, 2.seg, и т.д. по мере накопления данных. Когда файл вырастает большой, начинаем писать новый, а старый сжимается блоками и фиксируется навсегда как read-only файл - его можно раздавать и кешировать. Если элемент обновился, он уже попадёт в новый сегмент, а в архиве зависнет старая версия. Чтобы найти именно последнюю версию, надо у сервера спросить карту, которая скажет, в каком архиве последняя версия или она ещё в живом сегменте.
По сути, сегмент таблицы - это массив байт в начале и массив смещений элементов в конце плюс другие метаданные для поиска (даты и т.п.). Первым запросом читаем конец файла - смещения и другие метаданные сегмента, проходимся по ним на клиенте, а вторым по найденному смещению достаём сами данные сжатого блока, где лежит искомый элемент. В своей СУБД сразу делаю VFS, чтобы можно было работать как с БД в памяти, так и в локальном файле или удалённом сервере без необходимости что-то монтировать в ОС.
SQLite через абстракцию от ФС тоже можно заставить работать, но это будет медленно, так как она не приспособлена для таких задержек. Там B-деревья и сканирование по строкам с множеством чтений файла друг за другом - пинг будет складываться. И её неудобно пилить на много файлов, потому что каждый станет своей отдельной БД. Там оверхед на метаданные, и сжатие только через плагины, причём менее эффективное, так как вроде мелкими блоками работает.
Другое дело - своя СУБД, специально предназначенную для поиска элементов за минимальное количество прыжков по файлу - за 2, и автоматическую упаковку старых данных в отдельные read-only файлы. Постепенно такие архивные файлы будут копиться, но сервер БД всегда будет работать только с текущим не дописанным сегментом и держать компактную карту с интервалами ключей, по которым можно определить какие файлы-архивы стоит смотреть для запроса. А в архивах будет искать сам клиент, предварительно получив актуальную карту с сервера. Большую часть карты можно тоже хранить в архивах, а с сервера только получать дельту, можно даже в режиме реал-тайм подписки.
Cloudflare бесплатно проксирует же, правда в РФ с ним проблемы, но я нашёл некоторые костыли, чтобы только для блокирующих его провайдеров использовалась прокси-VPS. Конечно при большой нагрузке Cloudflare может прийти с требованием платить, но это вроде очень большая нагрузка должна быть. Вряд ли это случится до того, как я хорошо заработаю на своём проекте, и это станет неважным. А если не заработаю, то и не придут, смогу поддерживать его в рабочем состоянии практически бесплатно. Как минимум, не надо платить за вычисления, можно захостить всё на слабом серваке с большими дисками и быстрой сетью. И моя СУБД хорошо экономит место и трафик за счёт блочного сжатия большей части данных и упаковки метаданных. Если традиционные БД весят намного больше, чем сырые данные, которые там лежат, то у меня будет в разы меньше. Не понял, зачем мне минус поставили. Неужели такая архитектура никому не интересна? Даже если идея выкладывать данные на всеобщее обозрение кажется стрёмной, можно ведь захостить её внутри контура компании, а клиентами сделать бекенд, любое количество микросервисов и т.п., и БД не будет боттлнеком даже если вырастет до терабайтов.
Не шутка. Я пишу свою соцсеть, где пользователи смогут писать код шейдеров и не только, всё выполняться в браузере и публиковаться как посты. В общем , убийца ShaderToy. Искал решения, как сделать это, чтобы потом практически не платить за инфраструктуру. Придумал такую СУБД, публичные фрагменты которой можно выложить на CDN и по HTTP Range-запросами находить всё, что надо, прямо с клиента. Бекенд только будет изредка выдавать карту, чтобы клиент знал, где искать актуальную версию данных, а также для записи и данных, требующих контроля. И то скорее всего такие данные будут тоже на CDN, но в зашифрованном виде, а бекенд будет только ключи выдавать.
В России как минимум мобильные операторы блочат Cloudflare. Мне пришлось для них настраивать редирект напрямую на свою VPS, которая проксировала с Cloudflare.
Я как раз сейчас делаю свою СУБД с нейронками. Я уже давно придумал уникальную СУБД, которая позволит разгрузить бекенд и переложить большую часть нагрузки на самих клиентов, чтобы даже моя VPS за 75₽ в месяц потянула мою будущую соцсеть даже с десятками тысяч пользователей. Некогда было ей заняться, а с нейронками дело пошло.
Я тоже пришёл к подобным выводам, но на макбуке с M4 Pro. Пробовал обучать простую MLP модель в Keras на GPU, обучалась медленно. Кажется, было очень много синхронизаций CPU и GPU, GPU не нагружался толком. Когда перешёл на CPU, оказалось, что он в одном потоке в разы быстрее! Можно было параллельно обучать несколько моделей с разными гиперпараметрами на разных ядрах, чтобы быстрее найти лучшую конфигурацию.
А там не надо. Пользуюсь без аккаунта. Даже фичи ИИ доступны без аккаунта, но с более строгими лимитами.
Вообще мне его ChatGPT рекомендовал, как очень оптимизированный и легковесный терминал. Но я на него так и не перешёл полностью, пока не привык к тому, что он не похож ни на один другой терминал.
Я иак понял, от QuikSharp там только серверная часть? А если я пишу на TypeScript/Node.js, то мне надо переписать только один файл QuikPy.py на TypeScript? Это весь биндинг на клиентской стороне?
Для поддержки GCC 8 можно не отказываться от концептов, а просто добавить флаг -fconcepts и сделать `#define concept concept bool`
Я так делаю в рабочем проекте, который использует нетривиальные концепты и собирается в GCC 8+. Но не знаю насчёт стандартного хедера с готовыми концептами, я сам определяю все концепты. В теории, -fconcepts можно даже в GCC 6 использовать, но я не пробовал, так как мне достаточно поддержки GCC 8.
Вообще-то там 7 ГБ SSD. Тоже пользуюсь три года уже, тогда он стоил 55₽ и было 768 МБ, потом повысили. Ни разу он сам не перезагружался. Иногда зависал, но видимо меня заддосили, кончилась память, и ушёл в swap. Ну и сам сервер конечно медленный, думаю конкуренты в статье шустрее по большинству параметров. Но как самый дешёвый VPS с легковесными сервисами, прокси и пробросом домашнего сервера с серым IP через FRP вполне норм. Правда через прокси многие российские сайты с капчей пристают постоянно, особенно если не залогинен.
Я уже три года пользуюсь, туда прокси поставил. Как уже написали, Gemini не работает, ещё заметил, что intel.com не работает. Как-то определяет Россию несмотря на локацию IP Нидерланды. Остальное работает хорошо. Я его выбрал, когда цена была вроде 130 рублей, и он был самым дешёвым сервером за границей с оплатой российской картой. А потом они перешли на цены в баксах и пришлось платить $3. Переходить куда-то ещё было лень.
У меня примерно неделю уже как отвалились все Cloudflare Tunnel. Не знаю, как с проводным интернетом, но по 4G билайна в Московской области cloudflared выдаёт TLS Timeout и не может создать туннель. Проводного интернета в моё СНТ не провели.
Думаю теперь пробрасывать свои сервисы через frp на VPS, но тогда я упрусь в её пропускную способность. А Cloudflare Tunnel имели кеширование вроде, ускоряя повторное скачивание файлов.
Ну наверное больше десятка видел статей про алготрейдинг с использованием только индикаторов. А из фигур видел только один урок по поиску чего-то похожего на ГиП, но который находил не далеко не все ГиП, а только в небольшом окне из нескольких свечей. И дальше не было никакого алгоритма с бектестами.
Я полгода назад искал в гугле алготрейдинг с фигурами, но попадается либо просто базовое неформализованное описание фигур без алгоритма, либо алготрейдинг с индикаторами. Статью на Хабре, про которую вы говорите, не находил.
Меня интересуют фигуры не сами по себе, а с точками входа и стопами за линии поддержки. Если фигура сработала, то заработал, если нет - закрылся по маленькому стопу. В итоге в среднем можно неплохо зарабатывать, мне кажется. По крайней мере, некоторые курсы по трейдингу так учат. И их авторы побеждают на турнирах и ЛЧИ с сотнями процентов доходности за несколько месяцев. Но они торгуют руками, попыток сделать такое в алгоритмах я не видел.
То, что рынок - разводняк, не спорю. Скорее всего, им крутят большие дяди с огромными капиталами, провоцируя толпу на выгодные для них действия, которые ведут к перетеканию денег от толпы к ним. Должны быть какие-то правила, по которым они действуют, инициируют движения, которые психологически заставляют толпу продавать и покупать тогда, когда это выгодно им. Если разгадать хотя бы их часть, можно к ним присоединиться и тоже себе часть этого потока забрать. Я думаю, это возможно, но не сводится к простым индикаторам. И как только заметная для них часть потока начнёт утекать посторонним, они эти правила усложняют, поэтому старая информация в интернете и книгах не работает или становится неполной.
Везде вижу уроки, что в алготрейдинге используют только тупые индикаторы. Но никогда не слышал, чтобы кто-то пытался сделать алгоритмы, которые торгуют те же идеи, что и люди: фигуры типа флагов, головы и плечей, бэтменов, волн Эллиотта или Вульфа и т.п..
И свечные модели, всякие price action тоже в алгоритмах не видел, хотя то, что рассказывают на Ютубе, вроде неплохо формализуется на первый взгляд. Конечно наверняка большинство - это инфоцыгане, но бэктест бы это сразу показал.
Уже давно вынашиваю идею создания своего языка для хранения и обработки данных - чего-то типа убийцы JSON, protobuf, flatbuffers, TOML и SQL в одном флаконе. Думал, как делать JIT для него. Хотел что-то легковесное, при этом кроссплатформенное, думал делать своё: IR на основе ARM64 и упрощённую аллокацию регистров. И тут вы как раз такое сделали, да ещё и с человеческим лицом. Теперь как руки дойдут до JIT, буду знать, куда смотреть.
А поддержка SSE для процессоров без AVX планируется? У меня несколько таких девайсов есть, причём два из них относительно свежие, например, мини-ПК на Celeron N5095. Ещё есть VPS, где только SSE2 вроде или SSE3 - не выше.
В РФ мало знать английский, надо ещё умудриться работать в условиях санкций. Конечно проще, если рассматривать релокацию. Я язык знаю, но уезжать не готов, а с удалёнкой сложнее.
А можно поставить Coolify так, чтобы сборка шла локально, а на VPS только само приложение? И захостить на самой дешёвой VPS 512 МБ ОЗУ и 1 vCPU, которой более чем достаточно для запуска всех моих приложений?
Или может есть аналог Coolify, если он так не может?
В TS с тем же успехом можно сделать аргумент типа number|string|object. И в контексте тех же дженериков те же сбросы оптимизированного кода происходят, в отличие от шаблонов C++, где создаётся специализированная для типа оптимизированная функция. И наоборот, можно сам JS писать так, чтобы не допустить такой ситуации.
TS сам по себе не влияет на производительность, но может быть инструментом, который поможет своими подсказками и ограничениями упорядочить типы в коде, чтобы не только избежать багов в коде, но и избежать ситуации, когда V8 сбрасывает оптимизированный код. Всё равно это задача того, кто пишет код, которую он должен держать в уме, ограничивая типы.
У меня немало проектов с фронтендом, но из всего перечисленного в статье использую только TypeScript. И не понимаю, что у вас там за дженерики на дженериках и зачем они?
Другое дело C++, там можно нагородить многоэтажных и сложных шаблонов ради того, чтобы потом всё заинлайнилось и оптимизировалось компилятором, сгенерировав наиболее оптимальный код алгоритма или структуры данных для каждого типа.
Но в экосистеме JS типы TS - просто ограничения, проверки и подсказки, не влияющие на производительность. Не вижу смысла усложнять.
Я пытаюсь сделать именно СУБД с таблицами и с запросами по одной таблице - хотя бы уровня SELECT без JOIN'ов и GROUP BY по функционалу - сам язык SQL для этого необязательно делать. Каждая таблица - это директория с набором файлов-сегментов типа 0.seg, 1.seg, 2.seg, и т.д. по мере накопления данных. Когда файл вырастает большой, начинаем писать новый, а старый сжимается блоками и фиксируется навсегда как read-only файл - его можно раздавать и кешировать. Если элемент обновился, он уже попадёт в новый сегмент, а в архиве зависнет старая версия. Чтобы найти именно последнюю версию, надо у сервера спросить карту, которая скажет, в каком архиве последняя версия или она ещё в живом сегменте.
По сути, сегмент таблицы - это массив байт в начале и массив смещений элементов в конце плюс другие метаданные для поиска (даты и т.п.). Первым запросом читаем конец файла - смещения и другие метаданные сегмента, проходимся по ним на клиенте, а вторым по найденному смещению достаём сами данные сжатого блока, где лежит искомый элемент.
В своей СУБД сразу делаю VFS, чтобы можно было работать как с БД в памяти, так и в локальном файле или удалённом сервере без необходимости что-то монтировать в ОС.
SQLite через абстракцию от ФС тоже можно заставить работать, но это будет медленно, так как она не приспособлена для таких задержек. Там B-деревья и сканирование по строкам с множеством чтений файла друг за другом - пинг будет складываться. И её неудобно пилить на много файлов, потому что каждый станет своей отдельной БД. Там оверхед на метаданные, и сжатие только через плагины, причём менее эффективное, так как вроде мелкими блоками работает.
Другое дело - своя СУБД, специально предназначенную для поиска элементов за минимальное количество прыжков по файлу - за 2, и автоматическую упаковку старых данных в отдельные read-only файлы. Постепенно такие архивные файлы будут копиться, но сервер БД всегда будет работать только с текущим не дописанным сегментом и держать компактную карту с интервалами ключей, по которым можно определить какие файлы-архивы стоит смотреть для запроса. А в архивах будет искать сам клиент, предварительно получив актуальную карту с сервера. Большую часть карты можно тоже хранить в архивах, а с сервера только получать дельту, можно даже в режиме реал-тайм подписки.
Cloudflare бесплатно проксирует же, правда в РФ с ним проблемы, но я нашёл некоторые костыли, чтобы только для блокирующих его провайдеров использовалась прокси-VPS. Конечно при большой нагрузке Cloudflare может прийти с требованием платить, но это вроде очень большая нагрузка должна быть. Вряд ли это случится до того, как я хорошо заработаю на своём проекте, и это станет неважным. А если не заработаю, то и не придут, смогу поддерживать его в рабочем состоянии практически бесплатно.
Как минимум, не надо платить за вычисления, можно захостить всё на слабом серваке с большими дисками и быстрой сетью. И моя СУБД хорошо экономит место и трафик за счёт блочного сжатия большей части данных и упаковки метаданных. Если традиционные БД весят намного больше, чем сырые данные, которые там лежат, то у меня будет в разы меньше.
Не понял, зачем мне минус поставили. Неужели такая архитектура никому не интересна? Даже если идея выкладывать данные на всеобщее обозрение кажется стрёмной, можно ведь захостить её внутри контура компании, а клиентами сделать бекенд, любое количество микросервисов и т.п., и БД не будет боттлнеком даже если вырастет до терабайтов.
Не шутка. Я пишу свою соцсеть, где пользователи смогут писать код шейдеров и не только, всё выполняться в браузере и публиковаться как посты. В общем , убийца ShaderToy. Искал решения, как сделать это, чтобы потом практически не платить за инфраструктуру. Придумал такую СУБД, публичные фрагменты которой можно выложить на CDN и по HTTP Range-запросами находить всё, что надо, прямо с клиента. Бекенд только будет изредка выдавать карту, чтобы клиент знал, где искать актуальную версию данных, а также для записи и данных, требующих контроля. И то скорее всего такие данные будут тоже на CDN, но в зашифрованном виде, а бекенд будет только ключи выдавать.
В России как минимум мобильные операторы блочат Cloudflare. Мне пришлось для них настраивать редирект напрямую на свою VPS, которая проксировала с Cloudflare.
Я как раз сейчас делаю свою СУБД с нейронками. Я уже давно придумал уникальную СУБД, которая позволит разгрузить бекенд и переложить большую часть нагрузки на самих клиентов, чтобы даже моя VPS за 75₽ в месяц потянула мою будущую соцсеть даже с десятками тысяч пользователей. Некогда было ей заняться, а с нейронками дело пошло.
Разве Cloudflare ZeroTrust ещё где-то работает в РФ? У меня летом все туннели отвалились, пришлось через frp на VPS делать.
Я тоже пришёл к подобным выводам, но на макбуке с M4 Pro. Пробовал обучать простую MLP модель в Keras на GPU, обучалась медленно. Кажется, было очень много синхронизаций CPU и GPU, GPU не нагружался толком. Когда перешёл на CPU, оказалось, что он в одном потоке в разы быстрее! Можно было параллельно обучать несколько моделей с разными гиперпараметрами на разных ядрах, чтобы быстрее найти лучшую конфигурацию.
А там не надо. Пользуюсь без аккаунта. Даже фичи ИИ доступны без аккаунта, но с более строгими лимитами.
Вообще мне его ChatGPT рекомендовал, как очень оптимизированный и легковесный терминал. Но я на него так и не перешёл полностью, пока не привык к тому, что он не похож ни на один другой терминал.
Я иак понял, от QuikSharp там только серверная часть? А если я пишу на TypeScript/Node.js, то мне надо переписать только один файл QuikPy.py на TypeScript? Это весь биндинг на клиентской стороне?
Для поддержки GCC 8 можно не отказываться от концептов, а просто добавить флаг -fconcepts и сделать `#define concept concept bool`
Я так делаю в рабочем проекте, который использует нетривиальные концепты и собирается в GCC 8+. Но не знаю насчёт стандартного хедера с готовыми концептами, я сам определяю все концепты. В теории, -fconcepts можно даже в GCC 6 использовать, но я не пробовал, так как мне достаточно поддержки GCC 8.
Так что enable_if можно забыть, как страшный сон.
Вообще-то там 7 ГБ SSD. Тоже пользуюсь три года уже, тогда он стоил 55₽ и было 768 МБ, потом повысили. Ни разу он сам не перезагружался. Иногда зависал, но видимо меня заддосили, кончилась память, и ушёл в swap. Ну и сам сервер конечно медленный, думаю конкуренты в статье шустрее по большинству параметров. Но как самый дешёвый VPS с легковесными сервисами, прокси и пробросом домашнего сервера с серым IP через FRP вполне норм. Правда через прокси многие российские сайты с капчей пристают постоянно, особенно если не залогинен.
Я уже три года пользуюсь, туда прокси поставил. Как уже написали, Gemini не работает, ещё заметил, что intel.com не работает. Как-то определяет Россию несмотря на локацию IP Нидерланды. Остальное работает хорошо. Я его выбрал, когда цена была вроде 130 рублей, и он был самым дешёвым сервером за границей с оплатой российской картой. А потом они перешли на цены в баксах и пришлось платить $3. Переходить куда-то ещё было лень.
У меня примерно неделю уже как отвалились все Cloudflare Tunnel. Не знаю, как с проводным интернетом, но по 4G билайна в Московской области cloudflared выдаёт TLS Timeout и не может создать туннель. Проводного интернета в моё СНТ не провели.
Думаю теперь пробрасывать свои сервисы через frp на VPS, но тогда я упрусь в её пропускную способность. А Cloudflare Tunnel имели кеширование вроде, ускоряя повторное скачивание файлов.