Комментарии пользователя Кирилл Гудков
Artem Loychenko, первопричина большинства неэффективностей — короткошерстная обезьяна за терминалом. Азарт, страх потерь, объяснение всего и желание все время быть правым — все это есть в каждом из нас. Наверно на охоте в саванне это было полезно.
Но если цель отличается от «весело потратить выходные в ласвегасе», то надо как-то сдерживаться. Нет никаких «систем» заработка на рулетке, кроме как играть за казино.
что в целом смешно, потому что все мы усредняемся
Дальше не читал. Если текст начинается с надевания кастрюли на голову читателя, то продолжение лучше не будет.
тогда как после формирования бара вряд ли можно войти по средней цене
Это и есть подглядывание. Это «вряд ли можно» имеет огромную разницу с «точно можно».
Попробуйте смоделировать торговлю лимитными ордерами — любую как угодно полученную цену проверьте на перехлест в 1 шаг цены с диапазоном следующей свечи, а не текущей. Если перехлест есть — ваша сделка состоялась, нет — повторите все на следующем баре. Не используйте тех данных, которых вы на момент открытия свечи знать не можете.
Интуитивно кажется невелика разница, на деле даже знание high-low текущей свечи в момент ее открытия даст преимущество, которое весомее любой стратегии на OHLC. Точное знание, а не какой-то там прогноз.
Дед Нечипор, на упомянутую мной формулу нужно наложить маску по размеру хэштейбла. Т.е. размер тейбла берется кратным степени двойки. Морочиться с делением на простое число не надо, это замедлит функцию, если число неизвестно в compile time.
Так что сдвиг N именно таки и определяет, с какого участка брать. После умножения на 0x1000193 распределение хаоса по битам будет подобно гауссиане, брать биты по краям — плохая идея.
Трудно придумать приложение, где это бы реально имелo хоть какой-то смысл. Когда размеры хэш тейбла невелики, проще бороться с коллизиями увеличением размера самого тейбла, заполнение на 50-70% по учебникам на деле нафиг не уперлось. Память ничего не стоит, пока она влезает в L1D.
Когда нужна быстрая но приличная хэш функция для значения, влезающего в 32 бита, использую обычно такой шаблон:
const uint64_t MAGIC = 0x01000193;
size_t hash = value*MAGIC >> N;
N подбирается на типовом наборе хэшируемых значений по к-ву коллизий на заданном размере тейбла, обычно оно в диапазоне 10-20.
Это не то же самое, что хэш FNV, откуда константа позаимствована. Оно работает много быстрее FNV, но при разумном применении дает небольшое к-во коллизий.
Проверил гипотезу на себе. Тут помянуты какие-то Оксимирон и Моргенштерн. Арий Моргенштерна не слышал, но это кажется тот чудак, у которого наколки на лице, в новостях мелькал. Отбрасываем этот многогранный талант.
Нагуглил Оксимирона. Он немного моложе меня, разница чуть больше чем у Путина с Шевчуком. Физиономию ни разу не видел, с творчеством разумеется незнаком (рэп это кал не фанат данного направления).
Выборка небольшая, но теорию подтвердила.
Шевчука я кстати вполне узнал, встретив на улице. Тяжело наверно жить, когда каждый пятый прохожий смотрит как на экспонат. Искаженное восприятие действительности от такой жизни неизбежно, человек слаб.
Просто трейдер,
чаты на 10-20 человек
Вы так говорите, как будто это что-то плохое...
как может измениться корелляция между стратегиями на одном инструментеРано или поздно свалится в +1.0. Не вычеркивайте этот сценарий из допустимых, если не хотите играть в рулетку.