ch5oh, гмммммм

Не хочу палить Грааль, но частично придется...
Тут присутствует подмена понятий
Достоверность по ТВ означает частоту подтверждения прогноза.
Достоверность по трейдингу означает влияние прогноза на совокупный финрез.

Грубо говоря — можно не угадывать в момент маленьких приращений цен и хорошо угадывать в период больших.

С уважением

P.S. Именно за это не перевариваю ТВ-подход в трейдинге. Он неплох с модельной точки зрения, но практически ничего не дает в части зарабатывания прибыли.

Проходят годы, а проблемы, волнующие трейдеров не меняются.
Процитирую целиком лучший пост на эту тему из уважения к героям прошлых лет (2012 год):

Сказка о феях Эпиграф:

Танкисты (Т) посреди леса, жутко матерясь, натягивают гусеницу. Вдруг появляется Лесная Фея (Ф) и спрашивает:
Ф: -Танкисты, танкисты, а что это вы такое делаете?
Т: -Трахаемся!
Ф: -А хотите по-настоящему потрахаться, со вкусом?
Т: -Ну дык, конечно хотим!
Взмахнула Фея своей волшебной палочкой, и у танка отвалилась
башня...

В трейдинге как и в любой деятельности, которая связана с исследованиями, часто возникает ситуация, когда направление дальнейших действий неизвестно и не определено. Соответственно из этого положения человек начинает искать выход основываясь на своем бэкграунде и опыте.
Конечно для любого трейдера необходимы знания софта, и хотя бы одного языка программирования.
Но речь в сказке пойдет о тех, кто уже имеет достаточно опыта торговли, создания систем, и знаний.

Так вот приходит такой трейдер в творческий тупик, и начинает сразу думать о путях выхода, и как правило речь идет не о том, чтобы искать решения в себе. А о поиске внешних средств, несколько простых кейсов, чтобы было понятно о чем я:
1. Excel медленно считает, нужно написать свою программу для расчетов
2. Эх, если бы у меня была программа Х я бы натянул рынок, не то что с этой программой Y
3. У меня не получается торговать руками, но вот если купить робота за 3000 рублей, вот тогда я стану богатым
4. Хранить историю котировок в текстовых файлах не кошерно, надо придумать свой формат сжатия
5. Программа Z не умеет тестировать тот класс стратегий, что мне надо напишу ка я свой фреймворк/бэктестер/терминал для этого
6. А напишу ка я свой бэктестер, потому-что свой, потому-что удобнее и не то что у других

Все это, господа — секс с феями. Все трейдеры в душе перфекционисты, все хотят быстрее, выше, сильнее. Но время — ресурс невосполнимый, и тратя его на одно дело, мы забираем его у других. Поэтому я оглянулся назад и оценил, сколько работы я сделал зря ради красоты и перфекционизма. Многие проекты были заброшены сразу после того как доведены до стадии какой-то работоспособности. Мне стало грустно, конечно опыт остался, очередного робота(order management system) или бэктестера я могу за пол месяца написать на хорошем уровне, но не хочу!

Поэтому выработал для себя несколько правил:
1. Если проблему можно решить за 1 день, написав под это узкую программу, или за 30 дней, написав под это фреймворк. Нужно писать узкую утилиту, потому как есть вероятность, что больше никогда к этому не вернешься. Однако и утилиту можно сделать гибкой.
2. Если чешутся руки создать что-то глобальное и красивое, задайся вопросам а науха это надо? Какую конкретно задачу это красивое-доброе-совершенное будет решать, и сколько бенефита оно принесет? Если задача все равно важная, см. п. 1.
3. Если при решении задачи возникает желание создать что-то глобальное, с формулировкой, например «а хорошо бы иметь свой бэктестер» — значит задача поставлена неверно, или слишком общО сформулирована.
4. Если задачу можно сделать как-то через жопу имеющимися средствами — делай через жопу
5. Всегда стараться сократить время на решение задачи путем повышения эффективности. Если есть 100% уверенность повторяемости действий, нужно делать фреймворк. Но не нужно писать новый Амиброкер или Омегу, нужно делать только то, что даже через п.4 не делается. Если решился делать фреймфорк, делай масштабируемую архитектуру (напр для роботов-исполнителей), но реализовывать нужно только, то что потребуется здесь и сейчас для решения задачи.
6. Для каждого гвоздя должен быть свой микроскоп! Глупо тестировать торговые системы на ассемблере, глупо делать двойную работу переписывая алгоритмы в разных платформах, глупо писать свое если есть уже готовое.