да еееесть ...
- 2014.09.29
- www.mql5.com
Структурно - каждый элемент дерева должен иметь указания на вышестоящий элемент и нижестоящие.
Физически - массив структур, например. Указаниями выступают индексы массива.
Это не структуры данных, это алгоритмы.
Структурно - каждый элемент дерева должен иметь указания на вышестоящий элемент и нижестоящие.
Физически - массив структур, например. Указаниями выступают индексы массива.
Ну да, один из вариантов. Но у нас же есть ещё ссылки и шаблоны - видел такой пример в статье про синтаксический анализатор (файл Prsr.mqh). Потому и интересуюсь, какой вариант лучше.
- www.mql5.com
Ну да, один из вариантов. Но у нас же есть ещё ссылки и шаблоны - видел такой пример в статье про синтаксический анализатор (файл Prsr.mqh). Потому и интересуюсь, какой вариант лучше.
Там мозг можно свернуть) ООП обычно красивее, но медленнее.
Быстрее только указатели на память, но их в mql нет, насколько я понял.
Там мозг можно свернуть) ООП обычно красивее, но медленнее.
Быстрее только указатели на память, но их в mql нет, насколько я понял.
Тоже думаю больше про массив, но в случае активного изменения дерева (частого добавления и удаления веток) теряется эффективность либо по памяти, либо по времени. И внесение изменений в код может оказаться непростым делом.
В случае изменения дерева ссылки вообще не подойдут - они неизменяемы. Во всяком случае в языке C, вникать в mql-багофишки у меня нет желания :)
теряется эффективность либо по памяти, либо по времени. И внесение изменений в код может оказаться непростым делом.
Ну это нормальное явление, как правило код можно сделать оптимальным или по скорости, или по объему памяти, совместить это удается не всегда.
Лично я в mql подобные вещи делал на массивах, с внесением изменений проблем вроде не было.
Не нашёл на форуме обсуждений реализации этих структур данных. Как их лучше (в смысле скорости исполнения и удобства программирования) реализовать на MQL5 - через массив или ссылки?
Если конкретнее, то интересуют деревья (и леса) общего вида (не бинарные), с вершинами (и/или рёбрами) помеченными простыми структурами.
тут друг спрашивает.... а для какой цели нужны деревья? )))
сами деревья портировать в MQL не сложно , в СБ были CNode и CTree - кажется так назывались
на Хабре было, что почитать - гугл..
тут в общем, если исследовательская работа, то я бы посоветовал бы в сторону SQL подумать - все готово, останется только структуру БД продумать
если нужен тестер с быстрой оптимизацией, то... динамический массив с резервированием по максимальному размеру массива - 3-й параметр ArrayResize() - реально ускоряет, в оптимизаторе проверял
тут друг спрашивает.... а для какой цели нужны деревья? )))
Хочется как-то потоньше поисследовать фрактальную структуру цен, а фракталы - это всегда деревья (L-системы, например).
сами деревья портировать в MQL не сложно , в СБ были CNode и CTree - кажется так назывались
на Хабре было, что почитать - гугл..
Они вроде бы для двоичных
тут в общем, если исследовательская работа, то я бы посоветовал бы в сторону SQL подумать - все готово, останется только структуру БД продумать
если нужен тестер с быстрой оптимизацией, то... динамический массив с резервированием по максимальному размеру массива - 3-й параметр ArrayResize() - реально ускоряет, в оптимизаторе проверял
SQL - всё же для хранения, скорее. Для расчётов лучше с массивами, конечно. Просто подумал, что вдруг кто-то делал что-то подобное.
Хочется как-то потоньше поисследовать фрактальную структуру цен, а фракталы - это всегда деревья (L-системы, например).
По стопам Гудылина?)
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Не нашёл на форуме обсуждений реализации этих структур данных. Как их лучше (в смысле скорости исполнения и удобства программирования) реализовать на MQL5 - через массив или ссылки?
Если конкретнее, то интересуют деревья (и леса) общего вида (не бинарные), с вершинами (и/или рёбрами) помеченными простыми структурами.