Интересная тема для многих: что будет нового в MetaTrader 4 и MQL4 - большие изменения на подходе - страница 50
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Тогда это снисхождение (остерегаться такого надо - хуже голой критики):
:-)
Мне уже поздновато пить боржоми или там грехи замаливать.. Место в аду для меня давно зарезервировано.
Не думаю что стремление понять без осуждения является самым тяжким из моих грехов. ;)
Есть такая буква. Однако геп (разрывный скачок котировки) может случиться в любой момент, а не только в начале бара. Таки любой "прореженный" формат не без греха, по определению. Полный фид только в тиках. А в истории стакана мог бы быть ещё полнее. Я тут пытаюсь для себя минутный формат состряпать, пока нашёл такой компромисс. Наверно оставлю как описал выше (без Open. только {Hi-Lo-Close}), понимаю все недостатки, это только одна из версий моего кодирования для своего тестера. Предусматривается также тестирование по сырым тикам, или по искусственно прореженным любыми методами (с сохранением тикового формата {бид-аск-тайм}).
Не думаю что стремление понять без осуждения является самым тяжким из моих грехов. ;)
Думать - по тяжести греха, конечно, сильнее. Согласен.
Я рад что ты правильно понял. Так что лучше закажи себе заранее котёл рядом с моим. Хоть потреплемся вдоволь. Времени на трепотню будет целая вечность. Без условно-досрочной реинкарнации.
;)
А ты уверен что MQ бары М1 хранят распакованными?
Тогда откуда задержки при получении истории (маленькие но есть), а вот повторное обращение (типа уже к кешу) идёт быстрее.
Видимо в файле истории бары хранят как изменения от синхробара, те в сжатом виде.
Так что твои подсчёты о 52 байтах это подсчёт распакованной истории.
А ты уверен что MQ бары М1 хранят распакованными?
Тогда откуда задержки при получении истории (маленькие но есть), а вот повторное обращение (типа уже к кешу) идёт быстрее.
Видимо в файле истории бары хранят как изменения от синхробара, те в сжатом виде.
Так что твои подсчёты о 52 байтах это подсчёт распакованной истории.
Об этом я ничего не утверждал. Мало того - уверен что упаковка есть. Формат не объявлен в открытый доступ, и я не пытался его "крякать".
Так что всё верно, у меня описан только распакованный формат. Из документации взят.
Об этом я ничего не утверждал. Мало того - уверен что упаковка есть. Формат не объявлен в открытый доступ, и я не пытался его "крякать".
Так что всё верно, у меня описан только распакованный формат. Из документации взят.
Всё верно, но ты пытаешься показать что новый формат будет экономным, при этом сравниваешь распакованый теперешний и частично запакованный новый.
Я не сравниваю экономность, тебе показалось. Только информативность. Экономии нет, мой распакованный формат больше == 88 байт {Open, High, Low, Close} и == 72 байта {High, Low, Close}.
Ну и нечего было рака за камень заводить. Предложил бы просто удвоить информативность вместо 52 байта 88.
Тоже самое с самого начала hrenfx предлагал.
А зачем вообще формат с таким большим количеством данных? Т.е. надо опредлиться с ограничениями этого тикового фильтра (данного формата), когда прогон с ним не отличает результат от прогона по чистой тиковой истории.
Навскидку видится, что простой тиковый фильтр HighBid+LowAsk не сильно уступит по точности столь навороченному (по количеству данных).
Close-данные - разве что для мультивалютной синхронизации.
Может, проще не изгаляться, а просто перейти на более мелкий ТФ? Например, S20 для той же минутки в формате HighBid+LowAsk потребует всего 48 байт (может и меньше, если 4 байта на цену - выше крыши. В своем тестере все делаю через long int - очень быстро). А по точности 100% уделает ваш минутный фильтр на 88 байт.
P.S. Функция Error(Freq, DataSize) = Full - Freq * DataSize стремится к нулю, при увеличении Freq,
где Error - потеря информации.
Full - полная рыночная информация.
Freq * DataSize - функционал "умножения": количество информации, которое можно восстановить при частоте квантования Freq, и содержании информации (DataSize) на каждый член квантования.