Автор: kondrat
Ну, в общем, в основании должна быть матрица (n+1) x (m+1) (индексация 0...n, 0...m) над ней с целью выращивания более сложных причинно следственных связей строится измерение размером n умножить на m. Над ним н квадрат умножить на м квадрат и т.п. в начале перебора использоваться будут не все элементы, но отводить под них память динамически не охота. А вот перебирать это хозяйство волшебно просто. |
|
Так и не отводите память - а каждый раз заново перевычисляйте нужное надлежащее значение при доступе к нему.
Если, конечно, оно вычисляется попроще, чем через что-то типа скалярного произведения строки одной матрицы на столбец другой. Т.е. какой-нибудь and двух и более элементов (в общем, что-то типа "галочки" наличия связи от ... к ..., вычисляющейся логическими операциями) хранить не нужно, его можно просто посчитать в любой момент, когда в этом значении возникнет необходимость.
Ну и Вы не сказали ничего о том, зачем/что перебирается. Может, там пригоден хороший алгоритм (типа того же Флойда-Уоршелла, который ищет кратчайшие пути в графе между любыми двумя вершинами), который, кроме этого, выражается через быстрые матем.функции (того же Флойд-Уоршелла можно выразить через операции произведения матриц - а быстрые версии библиотеки BLAS ("стандарта" для высокопроизводительной работы с векторами и матрицами) сейчас есть для всех распространённых процессоров).
Т.е. непонятна собственно "алгоритмическая нагрузка" на Ваши данные - например, её пропорция между общим числом обращений к памяти (чтений и/или записей) и общим числом вычислительных операций. При существовании готовых оптимизированных решений для кучи типовых (под)задач, которые могут быть применены и будут существенно быстрее самописного кода.