Комментарии пользователя Кирилл Гудков
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, но при разумном применении дает небольшое к-во коллизий.
Проверил гипотезу на себе. Тут помянуты какие-то Оксимирон и Моргенштерн. Арий Моргенштерна не слышал, но это кажется тот чудак, у которого наколки на лице, в новостях мелькал. Отбрасываем этот многогранный талант.
Нагуглил Оксимирона. Он немного моложе меня, разница чуть больше чем у Путина с Шевчуком. Физиономию ни разу не видел, с творчеством разумеется незнаком (рэп это кал не фанат данного направления).
Выборка небольшая, но теорию подтвердила.
Шевчука я кстати вполне узнал, встретив на улице. Тяжело наверно жить, когда каждый пятый прохожий смотрит как на экспонат. Искаженное восприятие действительности от такой жизни неизбежно, человек слаб.