Библиотека Generic классов - ошибки, описание, вопросы, особенности использования и предложения - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вы контекст не улавливаете. Если ходить по разным веткам и бездоказательно утверждать глупости - то да, это прямая дорога к бану. Если готовы исходным кодом подкрепить свои утверждения - welcome. Именно поэтому Владимир и сделал Вам предупреждение, т.к. сам он любит исходный код и порою даже требует его предоставление. Посмотрите для примера его собственные ветки.
Совершенно верно. Если будет код от Петра, то будет очень здоровски сравнить производительность.
Посмотрел. Все правильно написано. Вам же ответили, поиск элемента в словаре осуществляется за среднее время O(1), т.е мгновенно.
Вот это и звучит алогично. Среди тысячи ордеров максимум нужно 10 проверок. Но уж точно не одна в среднем. Зависимость среднего времени поиска от количества элементов есть всегда.
Нет. O(n) получается из-за коллизий хеша в очень редких случаях. Эти оценки сложности для оптимального алгоритма. Количество коллизий связано с оверхедом по памяти
В обычном случае искать по сути не надо, т.к. вычислив хеш мы по сути уже знаем расположение нужного элемента
На сколько помниться оптимально выбирать размер хеш словаря нужно как количество ожидаемых элементов в квадрате.
Наглядный пример коллизий - это парадокс дней рождения.
https://ru.wikipedia.org/wiki/
В обычном случае искать по сути не надо, т.к. вычислив хеш мы по сути уже знаем расположение нужного элемента
Звучит неправдоподобно. Но дождусь примеров, тогда посмотрю потроха реализации.
С одной стороны круто, а с другой вспоминаем что в MQL много чего нет по сравнению с другими языками: ни множественного наследования, foreach, yeild return, лямб, ...
Становится понятным что речи о IEnumerable идти не может.
Как тогда удобно обрабатывать С# контейнеры без IEnumerable?
Остаются старые С++ алгоритмы и вместо указателей на функции используются интерфейсы.
В конечном итоге получаем солянку - С# и С++.
Солянка как раз возникла из за некорректных названий, которые всё путают.
Если бы косили под C++, было бы всё понятно.
PS А почему это множественного наследования нету? Я разве не могу в mql5 так написать?
Насколько я понимаю, без проблем.
Поэтому в конечном итоге получаем C/C++. Если сделать нормальные названия. :)
Совершенно верно. Если будет код от Петра, то будет очень здоровски сравнить производительность.
Я всегда готов разговаривать на языке кодов. Автору достаточно было просто предложить мне доказать и я сразу бы перешел к делу.
Пусть автор предоставит задачу и мы сравним наши решения по эффективности.
Тема закреплена. Посмотреть это можно так:
и сразу видно, что тема закреплена:
Звучит неправдоподобно. Но дождусь примеров, тогда посмотрю потроха реализации.
Хеши в среднем O(1), если размер словаря к количеству ожидаемых элементов разрешает.
А дальше идет зависимость от реализаций по разруливанию коллизий, это может быть через список, может быть еще подхеш....
Наглядный пример коллизий - это парадокс дней рождения.
Прочел на вики. Тот случай, когда совсем не понимаешь логику интуитивных рассуждений.
Тема закреплена. Посмотреть это можно так:
и сразу видно, что тема закреплена:
Спасибо. Постараемся сделать интересной эту ветку. Уже вижу востребованность темы:))