Автоматическое магическое число - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Если бы вы не закрывали ордера частично, вы могли бы использовать комментарий для хранения информации об исходной паре/таймфрейме...?
Если есть два советника на одном и том же символе и таймфрейме, как они узнают, из какого из исторических ордеров брать их соответствующие ID?
Все это отчасти зависит от того, какая информация гарантированно будет доступна при повторном запуске. Например, на этом форуме есть люди, которые хранят данные такого рода в скрытых объектах в окне графика. Это неплохо, но меня лично пугает любой механизм, который пользователь может сломать - не понимая, как и зачем.
Если есть два советника на одном и том же символе и таймфрейме, как они узнают, из какого из ордеров брать их соответствующие ID?
Черт - это было в рамках проекта :D
Наверное, я предполагал, что советник (если он другого типа или версии) будет иметь идентификатор и в комментариях :)
-BB-
Я не могу понять, как это возможно без того, чтобы либо MT4, либо пользователь назначил ID каждому советнику. Или, точнее говоря, я не вижу ничего, что не включало бы в себя что-то очень неприятное, например, генерацию уникального ID, а затем модификацию .chr файла советника для хранения ID как части внешних параметров советника.
И, для общего развлечения, следующий способ не продвигает обсуждение, но он заменяет входные данные для хэша djb2 значением, которое гарантированно уникально (ценой необходимости вызова DLL). Я не знаю, насколько хорошо djb2 работает с такими вещами, как GUID, но я только что попробовал сгенерировать 1,000,000 идентификаторов без каких-либо коллизий. Но это все равно не решает проблему перезапуска.
Я не могу понять, как это возможно без того, чтобы либо MT4, либо пользователь назначил ID каждому советнику. Или, точнее говоря, я не вижу ничего, что не включало бы в себя что-то очень неприятное, например, генерацию уникального ID, а затем модификацию .chr файла советника для хранения ID как части внешних параметров советника.
>>Каким образом n-й экземпляр советника может получить свой файл chartyy.chr?
.
Если предположить, что экземпляр действительно может сопоставить свой собственный файл .chr:
если в источнике EA есть: extern int myID = <someCompileTimeVal>;
то любой экземпляр, увидев <someCompileTimeVal>, может считать, что это "первый раз" -> генерировать свой id -> модифицировать строку myID -> создавать файлы восстановления, используя уникальность myID , ...
затем при обнаружении перезапуска получить доступ к своему .chr файлу для p/u myID , который будет мастер-ключом, позволяющим перемапировать файлы...
.
например:
chart02.chr
<схема>
символ=EURUSD
период=15
..
..
<эксперт
name=LMT 1.8
флаги=343
window_num=0
<входы>
myID=<someCompileTimeVal>
...
</inputs>
</expert>
EOF
Помогите!!!
.
И, для общего развлечения, следующее не очень продвигает обсуждение, но оно заменяет входные данные для хэша djb2 значением, которое гарантированно уникально (ценой необходимости вызова DLL). Я не знаю, насколько хорошо djb2 работает с такими вещами, как GUID, но я только что попробовал сгенерировать 1,000,000 идентификаторов без каких-либо коллизий.
Я использовал PsPad ed, чтобы втянуть 1 миллион и сделал сортировку с галочкой remove dups.
>>Но... КАК вы сделали это "...без каких-либо столкновений" ?
"И, для общего развлечения, следующее не очень продвигает обсуждение, но оно заменяет входные данные для хэша djb2 значением, которое гарантированно уникально (ценой необходимости вызова DLL). Я не знаю, насколько хорошо djb2 работает с такими вещами, как GUID, но я только что попробовал сгенерировать 1,000,000 идентификаторов без каких-либо коллизий."
.
К вашему сведению, я обнаружил коллизии в 1 миллионе вызовов кода
отсортировано EOF
.
отсортировано + удалены разряды EOF
>>Как n-й экземпляр эксперта будет p/u свой файл chartyy.chr?
.
если предположить, что экземпляр действительно может сопоставить свой собственный файл .chr:
если в источнике EA есть: extern int myID = <someCompileTimeVal>;
тогда любой экземпляр, увидев <someCompileTimeVal>, может считать, что это "первый раз" -> gen it's id -> mod myID line -> create recovery files using myID's uniqueness, ...
затем при обнаружении перезапуска получает доступ к своему .chr файлу для p/u myID , который будет главным ключом, позволяющим перемапировать файлы...
Вы правы. Я забыл, что нет очевидного способа для советника определить свой .chr файл, если есть несколько советников для одного и того же символа и таймфрейма. Я думал, что он может создать скрытый объект label, содержащий что-то вроде GUID, а затем искать файл .chr, содержащий правильное значение. Однако я уверен, что файл .chr не обновляется при добавлении нового объекта на график.
И есть еще одна проблема. Я уверен, что MT4 хранит информацию о графике в памяти и записывает ее в файл .chr при закрытии MT4 (или при изменении свойств советника), и это, следовательно, перезаписывает любые изменения, которые сам советник внес в файл .chr во время работы. Если бы вы были невероятно смелым, вы могли бы попробовать установить свойство extern, имитируя нажатие клавиш - вызвать окно свойств, перейти к нужному параметру, изменить его, нажать Enter и т.д.
К вашему сведению, я нашел коллизии в 1 миллионе вызовов кода.
отсортировано EOF
При повторном запуске я тоже: 172 коллизии в 1 000 000 попыток.
Вы правы. Я забыл, что для советника нет очевидного способа идентифицировать свой .chr-файл, если есть несколько советников для одного и того же символа и таймфрейма. Я думал, что он может создать скрытый объект label, содержащий что-то вроде GUID, а затем искать файл .chr, который содержит правильное значение. Однако я уверен, что файл .chr не обновляется при добавлении нового объекта на график.
И есть еще одна проблема. Я уверен, что MT4 хранит информацию о графике в памяти и записывает ее в файл .chr при закрытии MT4 (или при изменении свойств советника), и это, следовательно, перезаписывает любые изменения, которые сам советник внес в файл .chr во время работы. Если бы вы были невероятно смелым, вы могли бы попробовать установить свойство extern, имитируя нажатие клавиш - вызвать окно свойств, перейти к нужному параметру, изменить его, нажать Enter и т.д.
Я прочитал вышеизложенное -> пошел делать упражнения -> и во время душа серые клетки кричат OBJECT. Вы убиваете маршрут .chr, но два слова "ярлык объекта" вызвали этот взрыв мозга :)
Итак, как вам это? Забудьте на время о получении 100% гарантированного ID. Другая часть - это восстанавливаемая память состояния, содержащая ID советника.
Ну...
1. void vArchiveID (int iID), int iRestoreID () [и int iGetNewID () перейдем к другому посту, если этот будет в порядке :]
2. vArchiveID() создает [скрытый?] объект label? на карте памяти состояния советника.
Имя объекта ДОЛЖНО быть одинаковым для любого вызывающего советника... так .ex4 lib или .mqh lib для (1)
3. КТ разоряется или советник идет ко дну и т.д.
4. при перезапуске советник первым делом вызывает iRestoreID(), которая возвращает -1, если на графике нет объекта, или архивный ID из предыдущего запуска.
5. если ID нет, то вызывается iGetNewID(), затем vArchiveID() и, предположительно, создается [впервые] файл дампа.
6. если ID "восстановлен", то весело идет восстановление последнего состояния через файлы дампа...
..
Что скажете?
[...]
Что скажете?
То, что вы предлагаете - это, я думаю, именно то, на что я намекал в своем сообщении с временной меткой 14:43. Единственная опасность такого пути - и единственная причина для вмешательства в файл .chr напрямую, чтобы установить внешние свойства - это исключить возможность случайного удаления объектов с графика. Но даже это можно в значительной степени преодолеть, обеспечив воссоздание объекта, если необходимо, в deinit().
Но BB/CB могут считать зависимость от файла .chr неприемлемой. Им может понадобиться что-то, что можно восстановить исключительно из данных, хранящихся вне сайта (т.е. из торгового списка, хранящегося у брокера).
Я некоторое время отсутствовал в этой теме.
Похоже, что мы добавляем некоторую степень сложности, чтобы обеспечить возможность восстановления с помощью автоматических магических чисел, да? То есть, чтобы тупой кусок реинкарнированного кода мог выяснить, кем он был в прошлой жизни, когда все, что он знает, это то, что он есть и где он находится. Не обязательно плохо. Но...
Я подумал, что было бы полезно задокументировать (очень кратко):
- Критерии для принятия решения о внедрении магических чисел
- Критерии для принятия решения об использовании автоматизированной генерации магических чисел
- Критерии для принятия решения о внедрении слоя персистентности
- Критерии для принятия решения о выборе глобальных чисел против доступа к файлам для персистентности.
Я предлагаю это для того, чтобы каждый не думал, что он должен внедрить кухонную раковину в свой советник.
Мнения ?
CB
- У меня осталось всего 8 постов, прежде чем я сделаю перерыв на некоторое время.
Да, в конце концов, кухонная раковина, скорее всего, находится на этом сайте, все академическое. Для меня первоочередной задачей является гарантированное авто[make|acquire] Expert ID. Значение, которое может быть использовано для многих целей.
Наличие уникального способа доступа к файлам дампа при перезагрузке в лучшем случае бессистемно и в любом случае требует от пользователей соблюдения правил использования эксперта. Множество экземпляров ccy+period+EA - это не вариант.
Я хотел, чтобы любой экземпляр мог определить, кто был мной до перезапуска, но это оказалось неработоспособным. Со своей стороны, я не доверяю ни одному пользователю следовать даже самым элементарным правилам. Если я не могу быть полностью уверен в автоматическом методе, я бы не стал принимать полумеры, при которых требуется вмешательство пользователя.
.
Используя jjc's CoCreateGuid() i/f я собираюсь сгенерировать достаточно неповторяющихся чисел. Достаточно - это субъективно, но я хочу, чтобы их было много... В сочетании с одним фрагментом библиотечного кода в качестве функции сервера доступа к ресурсам в файл с номерами. Количество номеров будет таким, что по крайней мере 2 года может пройти без повторного использования номера. При достижении EOF, он просто сворачивается в BOF и продолжает выдавать числа. Мои расчеты "пальцем в небо" основаны на том, что 10 пользователей работают 5 дней в неделю и 50 недель в году, где каждый день одному пользователю может потребоваться 20 новых ID. Затем этот результат удваивается. Абсурдное количество чисел - в основном 200 000. Да, функциональность каменного века, но герметичная и не требующая никакой зависимости от терминала, кроме возможности выполнить мой код. Конечно, можно бесконечно долго обсуждать последствия одного, 10 или 100 файлов, их физическое расположение и механизмы доступа. В конце концов, это намного лучше, чем моя жалкая функция make expert id, и является водонепроницаемым в отношении уникальности номера на [в действительности] более 2 лет.
.
CB, 666 должно быть счастливое число пилотов вертолетов? :\