Ошибки, баги, вопросы - страница 673
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ренат, нулевым пунктом - большое спасибо за внимание к теме и конструктивный ответ!
Далее.
1. про х64
Renat:
Более правильный вариант - переход на x64.
...
Конечно же, если кто-то будет вызывать сотни индикаторов в режиме сканирования рынка без их выгрузки, то им прямая дорога исключительно в 64 битную версию + установка дополнительной памяти.
Сейчас странно заниматься массивными тестами, сидя на x32. Любой приличный x64 компьютер с 16 Гб памяти (без фанатизма по видеокартам и мониторам) можно купить за 15 000 рублей.
Переход на x64 - по любому правильное направление действий. Но. Одно другое не исключает. Даже мои 16гиг (их есть у меня) мне не хочется транжирить на ненужные мне по факту данные. У меня есть ещё чему параллельно работать надо - MSVS, Матлаб, и т.п., на которых я тоже объёмистые задачи хочу считать. Я рад, что вы это понимаете и готовы искать пути экономии.
2. Про фиксированное начало истории:
Renat:
Нам самим хочется уменьшить потребление ресурсов. Возможно, решением может быть некая функция IndicatorMaxDepth(uint len), которая будет действовать только на индикаторы, создаваемые в этом эксперте.
Но проблема в том, что при тестировании буферы индикаторов в режиме накопления будут расти вместе с историей и экономии не получится.
Полностью (почти) согласен. Оговорка: Во многих случаях оптимизация проводится на небольшом куске последней истории. В этом случае экономия может быть и весьма существенная. И всё же вариант рассматриваю как относительно рабочий - особенно если у вас есть хорошие наработки или прикидки по реализации. Мне, например, вариант представляется не вполне полноценным - трудозатрат много, а результат не радикален. Половинчатое решение.
3. А вот он и язь! :
Renat:
Подрезать в рилтайме историю индикатора, поддерживая заданную глубину чревато красивыми глюками и прямым сносом крыши у программистов, которые считают/привыкли к синхронности баров чарта и буфера индикатора.
Нет ! , не чревато - если бары чарта ведут себя таким же образом - синхронно. Другими словами - если кольцевые буферы (пусть даже разные по размеру) всегда (насильственно) используют флаг AsSeries - массовых неприятностей у юзера не ожидается.
// В этом случае удобно будет сделать все предоставляемые юзеру исторические буферы - индикаторными (т.е. кольцевыми, с AsSeries=true).
В этом варианте:
(1) есть внутренне представление индикаторных и ценовых массивов (на вашей стороне) : индексация слева направо (AsSeries==false), размеры юзера не касаются, да и вообще "вход воспрещён".
И (2) есть сторона юзера - все буферы кольцевые (в реализации. юзер видит виртуальный линейный массив), индексация справа налево (AsSeries==true) и размер задан юзером.
Какие здесь сносы юзерской крыши? Никаких. При выходе за заданный диапазон - стандартная реакция Array out of range.
Трудности (немалые, если честно) только у вас. Но! Учитывая универсальность схемы - напрячься придётся только один раз. И пофиксить все "красивые глюки" в зародыше, при отладке беты. После чего - всеобщее счастье и очень экономная конструкция.
Мы проведем ревизию кеша индикаторов, у которого сейчас работает принцип максимальной эффективности против принципа экономии памяти. Индикаторы, от которых отказались, попробуем сразу же выгружать, а не держать некоторое время в памяти, как делается сейчас. Это даст возможность вызывать сотни индикаторов подряд с прямой выгрузкой через IndicatorRelease.
3. А вот он и язь! :
Нет ! , не чревато - если бары чарта ведут себя таким же образом - синхронно. Другими словами - если кольцевые буферы (пусть даже разные по размеру) всегда (насильственно) используют флаг AsSeries - массовых неприятностей у юзера не ожидается.
// В этом случае удобно будет сделать все предоставляемые юзеру исторические буферы - индикаторными (т.е. кольцевыми, с AsSeries=true).
В этом варианте:
(1) есть внутренне представление индикаторных и ценовых массивов (на вашей стороне) : индексация слева направо (AsSeries==false), размеры юзера не касаются, да и вообще "вход воспрещён".
И (2) есть сторона юзера - все буферы кольцевые (в реализации. юзер видит виртуальный линейный массив), индексация справа налево (AsSeries==true) и размер задан юзером.
Какие здесь сносы юзерской крыши? Никаких. При выходе за заданный диапазон - стандартная реакция Array out of range.
Трудности (немалые, если честно) только у вас. Но! Учитывая универсальность схемы - напрячься придётся только один раз. И пофиксить все "красивые глюки" в зародыше, при отладке беты. После чего - всеобщее счастье и очень экономная конструкция.
Хорошая идея. Я - за. Но она не отменяет внедрение кольцевой схемы, а просто хорошо дополняет.Опишу условия теста:
В результате автоматического подрезания индикатора мы:
Опишу условия теста:
В результате автоматического подрезания индикатора мы:
1.
Да, это терпимо. Вряд ли это приведёт к массовому недовольству, скорее наоборот - экономия очень обрадует. Никто ж не запрещает тратить память устанавливая огромный MaxBar.
// Вот глючат же индикаторы из-за пропуска баров! Вот уж где недовольство оправдано всерьёз!
// Дык вы даже это терпите... :) Ну и нам приходится... :(
2.
Вот как раз нет и нет! Кольцевая схема как раз и приводит к огромной экономии на копировании при сдвигах по истории. Фактически при сдвигах на один бар (N баров) , приходится копировать ровно одно значение (N значений). Затраты же (юзерские) на виртуализацию индекса ничтожны. Фактически их даже трудно обнаружить при стресс тестах (остаток от деления вычисляется процессором за один такт + смещение виртуального начала буфера при каждом сдвиге по истории - ещё пару тактов). Так что скорость мы практически не теряем. Невозможно обнаружить это замедление, настолько оно мало. И на фоне гигантской экономии памяти эти потери несоизмеримы с выигрышем.
3.
Эххх, лицорука...
Почему-то столько плясок и воплей вокруг захлёбывающихся на unlimited bars индикаторов, но ни слова - о пляшущих графических объектах. Попробуйте на Unlimited построить, например, супербольшие Вилы Эндрюса (на MN1, например), потом ограничьте в настройках терминала число баров, сходите на младшие таймфреймы и отмотайте к точкам привязки. Некоторые из них будут в грандиозном временнОм отрыве от экстремумов (это притом, что вилы всеми тремя точками лежат исключительно в области настоящих M1-баров, не заходя за границу подложных от более высоких таймфреймов!). А всё почему? Видимо, потому, что для расчёта точного M1-значения некоторых точек автопривязки не хватило исторических данных на M1. Хотя причём тут исторические данные?! Их-то, может, и хватило, а вот отображаемых в окне баров - нет, поэтому и сдвиги. То есть некоторые точки "сами толком не знают, где они лежат".
Хоть бы кто у себя проверил, а то, может, у меня одного такая свистопляска...
Заметил одну странность!
В момент формирования нового бара если считать значения Open и Close предыдущих баров (например 10 предыдущих баров), а потом спустя 5 секунд получить их снова, то некоторые из этих значений отличаются и потом если их получать пока новый бар формируется то все нормально, но вот в первые несколько секунду почему-то эти значения другие.
Надеюсь я понятно объяснил.
Не подскажите, прежде чем считывать значения баров Open и Close от начала нового бара нужно ставить задержку более 5 секунд?
Вот пример работы:
Сверху правильно сработала после задержки, снизу сразу после появления нового бара с ошибкой, а справа эталон для 6-й строки.
Возможно проблема в несинхронизированности, новый бар желательно отслеживать по всем используемым инструментам.
Да, Вы оказались правы, спасибо!
Аналогично, опера.