Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Код действительно красивый. НО я что-то не совсем согласен. По задумке топикстартера нужно найти между какими уровнями цена. В данной функции через параметр передаётся массив ценовых уровней.
В каком они порядке - хз.
Дальше мы пробегаем в цикле по данным уровням, не зная в каком они проядке до тех пор, пока БИД не будет иметь значение больше цены на данном ценовом уровне. Если значение выше 0 ВЫХОД.
Возвращается предыдущее значение, т.е. перед тем как значение станет ВЫШЕ.
НО мы же не сортировали ценовые уровни!!! А если на последнем значении L значение БИДа будет ниже значения Levels[L] ,но ниже(выше) других, в зависимости от самой функции. Что тогда?
Код действительно красивый. НО я что-то не совсем согласен. По задумке топикстартера нужно найти между какими уровнями цена. В данной функции через параметр передаётся массив ценовых уровней.
В каком они порядке - хз.
Дальше мы пробегаем в цикле по данным уровням, не зная в каком они проядке до тех пор, пока БИД не будет иметь значение больше цены на данном ценовом уровне. Если значение выше 0 ВЫХОД.
Возвращается предыдущее значение, т.е. перед тем как значение станет ВЫШЕ.
НО мы же не сортировали ценовые уровни!!! А если на последнем значении L значение БИДа будет ниже значения Levels[L] ,но ниже(выше) других, в зависимости от самой функции. Что тогда?
в этом варианте предполагается что уровни отсортированы. это разумно, т.к. цена движется, а уровни (как я думаю) неподвижны. поэтому их следует один раз отсортировать после построения (или перестройки).
и кстати, если уровней много, можно написать ещё более быстрый код, использующий бинарный поиск. только немного более длинный.
в этом варианте предполагается что уровни отсортированы. это разумно, т.к. цена движется, а уровни (как я думаю) неподвижны. поэтому их следует один раз отсортировать после построения (или перестройки).
и кстати, если уровней много, можно написать ещё более быстрый код, использующий бинарный поиск. только немного более длинный.
в этом варианте предполагается что уровни отсортированы. это разумно, т.к. цена движется, а уровни (как я думаю) неподвижны. поэтому их следует один раз отсортировать после построения (или перестройки).
и кстати, если уровней много, можно написать ещё более быстрый код, использующий бинарный поиск. только немного более длинный.
Действительно было бы интересно. А код очень интересный. И по скорости работы значительно быстрее будет (при достаточном количестве уровней, при необходимости можно всегда определить)
Интерестно, Поделитесь примером
Действительно было бы интересно. А код очень интересный. И по скорости работы значительно быстрее будет (при достаточном количестве уровней, при необходимости можно всегда определить)
ОК, пример бинарного поиска здесь : https://www.mql5.com/ru/forum/6461/page2#comment_177675
А если Bid меньше всех элементов Levels[] ?
Хде!? контроль выхода за пределы массива???
;)
Я бы так сделал:
Элементы Levels[] должны быть упорядочены по возрастанию.
В функцию предаётся максимальный индекс массива, а возвращается - индекс элемента, который не больше Bid.
Если возврат результат = -1, то Bid меньше минимума.
А если Bid меньше всех элементов Levels[] ?
Хде!? контроль выхода за пределы массива???
;)
Я бы так сделал:
Элементы Levels[] должны быть упорядочены по возрастанию.
В функцию предаётся максимальный индекс массива, а возвращается - индекс элемента, который не больше Bid.
Если возврат результат = -1, то Bid меньше минимума.
Вот обязательно надо поумничать, да ?
;)
Вот обязательно надо поумничать, да ?
;)
Не, ну, ведь, и в самом деле, функция могла полезть далеко за пределы переданного массива.
;)
ЗЫ. А так, конечно, твое решение изящно.