Алгоритмы, методы решений, сравнение их производительности - страница 15
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Видится явно проявляемое неоднократное неуважение к сообществу и ярко выраженные провокации.
Не читать это (посты человека в различных конструктивных ветках) не всегда получается, после чего развидеть и забыть - тем более.
Троллинг и плевки в руки помощи, число которых сильно отличает этот ресурс с положительной стороны.
Возможно, ошибаюсь.
Контролируйте свои эмоции пожалуйста. Если не принимаете чужую точку зрения, можете не участвовать в дискуссии. Никто вас не принуждает.
Поправьте меня, но разве длина строки не конечна?
https://msdn.microsoft.com/ru-ru/library/sx08afx2.aspx
Не могу только найти это ограничение для MQL5...
Строка это посути массив uchar, со своими плюшками, проде автоматической переразметки. Поэтому длина строки не ограничена по крайней мере в явном виде, также как и размер массива. Но потенциально для очень длинной строки может не хватить памяти, о чем свидетельствует такой специфический код ошибки как ERR_STRING_RESIZE_ERROR (Недостаточно памяти для перераспределения строки).
Строка это посути массив uchar, со своими плюшками, проде автоматической переразметки. Поэтому длина строки не ограничена по крайней мере в явном виде, также как и размер массива. Но потенциально для очень длинной строки может не хватить памяти, о чем свидетельствует такой специфический код ошибки как ERR_STRING_RESIZE_ERROR (Недостаточно памяти для перераспределения строки).
Ограничение только по памяти
1. То есть, скорость алгоритма не важна. Решение "концептуально-мощное" и этого достаточно. Ок.
2. То есть подключили через инклюд и все? Хорошо.
//--------------------------------------------------------------------
Если главный критерий оценки алгоритма - "Концептуальная мощь", то я проиграл.
Если главный критерий оценки алгоритма - простота, скорость и удобство - то выйграл.
На этом можно закрыть тему.
Вы "свой алгоритм" можете еще ускорить и упростить ( и вам об этом постоянно говорят), если строку замените на два int[] одинакового размера и в одном хранить номер сделки, а в другом магик и искать нужный индекс магика по соответствующему перебору массива сделок. Это будет быстрее. Конечно это частный случай, вытекающий из вашего примера.
Петр познал массивы и понял, что это универсальный и могучий инструмент, затем начал познавать строки..., а представляете что будет, когда он познакомится со структурами? и я боюсь подумать что будет, когда он узнает про шаблоны :)
Петр подмени в своем примере эти функции:
И скорость вынесет шаблон :)
1. То есть, скорость алгоритма не важна. Решение "концептуально-мощное" и этого достаточно. Ок.
2. То есть подключили через инклюд и все? Хорошо.
//--------------------------------------------------------------------
Если главный критерий оценки алгоритма - "Концептуальная мощь", то я проиграл.
Если главный критерий оценки алгоритма - простота, скорость и удобство - то выйграл.
На этом можно закрыть тему.
Просто пример показан самый рядовой - т.е. кучу лишней инфы, ладно хоть обработчика дебага и дефайна на принт нету - а то еще бы строк 300 добавилось.
Зато как бы весь код полностью....
нужная же часть кода по добавлению и вызову как раз через библиотеку будет гораздо удобнее, меньшее коду, более читаема
приходит тикер с маджиком - надо это сохранить а потом в удобной форме дергать по тикеру ну или маджику. ну и немного усложним - т.е. сохроняем все значения, тикер маджик ТР СЛ комент, цену открытия, время, Цену закрытия. - скажем будет для учета виртуальных ордеров
По факту наиболее быстрое решение будет хранить всю информацию в структуре. А вот доступы совершать через упорядоченого саммива индекса ссылок. причем по маджику и текру. т.е. их два будет - по памяти не рационально конечно - но если мы будет дергать ордера чатсто - то по скорости самое оно.
Это лобовое решение и потому не самое быстрое. Лучше делать через HashMap. Но в текущей реализации там потребуется не структура, а наследуемый от определенного интерфейса класс для описания полей своих ордеров.
Вы "свой алгоритм" можете еще ускорить и упростить ( и вам об этом постоянно говорят), если строку замените на два int[] одинакового размера и в одном хранить номер сделки, а в другом магик и искать нужный индекс магика по соответствующему перебору массива сделок. Это будет быстрее. Конечно это частный случай, вытекающий из вашего примера.
Интересное и дельное предложение. Ведение параллельных записей. В других своих решениях делал это.
Единственно только, - изначально нам неизвестно количество ордеров которые выставит советник. Какой размер задать массиву int?
Поэтому решил взять строку.
Это лобовое решение и потому не самое быстрое. Лучше делать через HashMap. Но в текущей реализации там потребуется не структура, а наследуемый от определенного интерфейса класс для описания полей своих ордеров.
чет не нашел у себя фаил Generic, похоже причина старый билд. Ну дак а принцип навигации как будет обеспечиваться - исходный то код какой?
Интересное и дельное предложение. Ведение параллельных записей. В других своих решениях делал это.
Единственно только, - изначально нам неизвестно количество ордеров которые выставит советник. Какой размер задать массиву int?
Поэтому решил взять строку.
Петр, есть такая великая функция, называется ArrayResize(). Она позволяет в моменте выполнения программы увеличивать размер массива.