Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Так вот если ордер закрылся, то его надо из массива "вычеркнуть". В таких случаях я пользовался копированием массива "сам в себя" и сокращением размерности на единицу.
я в таком случае несуществующий тикет записывал в массив -1 , и ждал когда все ордера будут закрыты и удалял весь массив (размер размер массива устанавливаю =1).
При таком подходе элемент массива тикетов (если не существует ордер) всего с одним условием проверяется: if(ArrayOfTicket[i] > 0) .....
имхо так быстрее чем постоянно массив "перетряхивать"
я в таком случае несуществующий тикет записывал в массив -1 , и ждал когда все ордера будут закрыты и удалял весь массив (размер размер массива устанавливаю =1).
При таком подходе элемент массива тикетов (если не существует ордер) всего с одним условием проверяется: if(ArrayOfTicket[i] > 0) .....
имхо так быстрее чем постоянно массив "перетряхивать"
Ничего не понял... А какая разница, удалять поэлементно или проверять индексы несуществующих ордеров...массив по любому перетрахивается...
В общем, как сегодня в новостях сказали, запатентовать вкус невозможно. Фломастеры только на цвет разные, а на вкус все одинаковые.
Ничего не понял... А какая разница, удалять поэлементно или проверять индексы несуществующих ордеров...массив по любому перетрахивается...
В общем, как сегодня в новостях сказали, запатентовать вкус невозможно. Фломастеры только на цвет разные, а на вкус все одинаковые.
удаление элемента подразумевает копирование оставшихся элементов массива, я не удаляю элементы массива, а маркирую значением -1 несуществующие элементы (тикеты), и удаляю массив тикетов когда нет рыночных ордеров
насчет фломастеров, однозначно так и есть, зависит от задачи, в принципе при оптимизации обычно 2 решения:
- или добавляем сложность алгоритма, но экономим память и тратим вычислительные ресурсы ПК
- или упрощаем алгоритм и экономим вычислительные ресурсы, но потребляем память
Контрольная сумма считается не верно, если в массиве есть 0 то может быть ошибка
Вариант Никитина как раз на такой ошибке работает.
Контрольная сумма считается не верно, если в массиве есть 0 то может быть ошибка
Вариант Никитина как раз на такой ошибке работает.
Да, Вы правы. Только Никитин выбрасывал дополнительно и нулевые элементы. Поэтому его код и выглядел как ошибочным. На самом деле решалась изначально поставленная Вами задача.
Если задокументировать у него проверку на нулевые элементы, то результат одинаковый:
Повторюсь, что сейчас контрольная сумма учитывает порядок элементов, раньше не учитывала.
Да, Вы правы. Только Никитин выбрасывал дополнительно и нулевые элементы. Поэтому его код и выглядел как ошибочным. На самом деле решалась изначально поставленная Вами задача.
Если задокументировать у него проверку на нулевые элементы, то результат одинаковый:
Повторюсь, что сейчас контрольная сумма учитывает порядок элементов, раньше не учитывала.
Кстати, если порядок очень важен, то можно в мой вариант добавить ArraySort в конце, заодно глянуть насколько ArraySort вообще эффективен.
Меня сейчас интересует другой вопрос, на который не могу найти ответа.
Может кто-то сможет объяснить, почему такой вариант из кода Кузнецова:
работает более чем в два раза быстрее, чем такой, делающий абсолютно тоже самое:
Что за чудеса компилятора?
Неужели для такой конструкции:
while(arr[i]!=x && i<j) i++;
компилятор находит какую то особенную ассемблерную команду поиска для процессора?
Кто-нибудь силен в современных командах процессора?
Кстати, если порядок очень важен, то можно в мой вариант добавить ArraySort в конце, заодно глянуть насколько ArraySort вообще эффективен.
Пробовал я с ним. Довольно затратная функция выходит. Хотя после нее выкидывать проще. Все нужные подряд идут.
Да, Вы правы. Только Никитин выбрасывал дополнительно и нулевые элементы. Поэтому его код и выглядел как ошибочным. На самом деле решалась изначально поставленная Вами задача.
Если задокументировать у него проверку на нулевые элементы, то результат одинаковый:
:
работает более чем в два раза быстрее, чем такой, делающий абсолютно тоже самое:
оптимизатор непричём - сравнений меньше в 2 раза..