Алгоритмы, методы решений, сравнение их производительности - страница 15

 
fxsaber:

Видится явно проявляемое неоднократное неуважение к сообществу и ярко выраженные провокации.

Не читать это (посты человека в различных конструктивных ветках) не всегда получается, после чего развидеть и забыть - тем более.

Троллинг и плевки в руки помощи, число которых сильно отличает этот ресурс с положительной стороны.


Возможно, ошибаюсь.

Контролируйте свои эмоции пожалуйста. Если не принимаете чужую точку зрения, можете не участвовать в дискуссии. Никто вас не принуждает.

 
Vladimir Karputov:

Поправьте меня, но разве длина строки не конечна?

https://msdn.microsoft.com/ru-ru/library/sx08afx2.aspx

Не могу только найти это ограничение для MQL5...

Строка это посути массив uchar, со своими плюшками, проде автоматической переразметки. Поэтому длина строки не ограничена по крайней мере в явном виде, также как и размер массива. Но потенциально для очень длинной строки может не хватить памяти, о чем свидетельствует такой специфический код ошибки как ERR_STRING_RESIZE_ERROR (Недостаточно памяти для перераспределения строки).


 
Vasiliy Sokolov:

Строка это посути массив uchar, со своими плюшками, проде автоматической переразметки. Поэтому длина строки не ограничена по крайней мере в явном виде, также как и размер массива. Но потенциально для очень длинной строки может не хватить памяти, о чем свидетельствует такой специфический код ошибки как ERR_STRING_RESIZE_ERROR (Недостаточно памяти для перераспределения строки).


Для меня тоже ценная информация. Спасибо.
 
fxsaber:

Ограничение только по памяти

очевидно, что ограничение по типу длины, т.е. рядом с INT_MAX
 
Реter Konow:

1. То есть, скорость алгоритма не важна. Решение "концептуально-мощное" и этого достаточно. Ок.

2. То есть подключили через инклюд и все? Хорошо.

//--------------------------------------------------------------------

Если главный критерий оценки алгоритма - "Концептуальная мощь", то я проиграл.

Если главный критерий оценки алгоритма - простота, скорость и удобство - то выйграл.

На этом можно закрыть тему.


Вы "свой алгоритм" можете еще ускорить и упростить ( и вам об этом постоянно говорят), если строку замените на два int[] одинакового размера и в одном хранить номер сделки, а в другом магик и искать нужный индекс магика по соответствующему перебору массива сделок. Это будет быстрее. Конечно это частный случай, вытекающий из вашего примера.

Петр познал массивы и понял, что это универсальный и могучий инструмент, затем начал познавать строки..., а представляете что будет, когда он познакомится со структурами? и я боюсь подумать что будет, когда он узнает про шаблоны :)

Петр подмени в своем примере эти функции:

struct SDealMagic {int deal,magic;} array[];
//
void Trading()
{
   Random_orders_of_strategy=MathRand();
   ArrayResize(array,Random_orders_of_strategy);
   for(int i=0; i<Random_orders_of_strategy; i++)
   {
      array[i].deal=i;
      array[i].magic=MathRand()
   }
}
//
int Get_magic(int deal_number)
{
   for(int i=0; i<Random_orders_of_strategy; i++)
      if(array[i].deal==deal_number) return(array[i].magic);
   return(-1);
}

И скорость вынесет шаблон :)

 
Реter Konow:

1. То есть, скорость алгоритма не важна. Решение "концептуально-мощное" и этого достаточно. Ок.

2. То есть подключили через инклюд и все? Хорошо.

//--------------------------------------------------------------------

Если главный критерий оценки алгоритма - "Концептуальная мощь", то я проиграл.

Если главный критерий оценки алгоритма - простота, скорость и удобство - то выйграл.

На этом можно закрыть тему.


Просто пример показан самый рядовой - т.е. кучу лишней инфы, ладно хоть обработчика дебага и дефайна на принт нету - а то еще бы строк 300 добавилось.

Зато как бы весь код полностью....

нужная же часть кода по добавлению и вызову как раз через библиотеку будет гораздо удобнее, меньшее коду, более читаема

 
Alexandr Andreev:

приходит тикер с маджиком - надо это сохранить а потом в удобной форме дергать по тикеру ну или маджику. ну и немного усложним - т.е. сохроняем все значения, тикер маджик ТР СЛ комент, цену открытия, время, Цену закрытия.  - скажем будет для учета виртуальных ордеров

По факту наиболее быстрое решение будет хранить всю информацию в структуре. А вот доступы совершать через упорядоченого саммива индекса ссылок. причем по маджику и текру. т.е. их два будет - по памяти не рационально конечно - но если мы будет дергать ордера чатсто - то по скорости самое оно.

Это лобовое решение и потому не самое быстрое. Лучше делать через HashMap. Но в текущей реализации там потребуется не структура, а наследуемый от определенного интерфейса класс для описания полей своих ордеров.

 
Yury Kulikov:

Вы "свой алгоритм" можете еще ускорить и упростить ( и вам об этом постоянно говорят), если строку замените на два int[] одинакового размера и в одном хранить номер сделки, а в другом магик и искать нужный индекс магика по соответствующему перебору массива сделок. Это будет быстрее. Конечно это частный случай, вытекающий из вашего примера.


Интересное и дельное предложение. Ведение параллельных записей. В других своих решениях делал это.

Единственно только, - изначально нам неизвестно количество ордеров которые выставит советник. Какой размер задать массиву int?

Поэтому решил взять строку.

 
fxsaber:

Это лобовое решение и потому не самое быстрое. Лучше делать через HashMap. Но в текущей реализации там потребуется не структура, а наследуемый от определенного интерфейса класс для описания полей своих ордеров.


чет не нашел у себя фаил Generic, похоже причина старый билд. Ну дак а принцип навигации как будет обеспечиваться - исходный то код какой?

 
Реter Konow:

Интересное и дельное предложение. Ведение параллельных записей. В других своих решениях делал это.

Единственно только, - изначально нам неизвестно количество ордеров которые выставит советник. Какой размер задать массиву int?

Поэтому решил взять строку.

Петр, есть такая великая функция, называется ArrayResize(). Она позволяет в моменте выполнения программы увеличивать размер массива.

Причина обращения: