Здравствуйте, Programador, Вы писали:
SC>>Нет ничего удивительного в том. что на каком-то коркретном частном случае более простой код и даже худший алгоритм окажется лучше универсального кода, написанного по последним достижениям науки. К тому же reference linpack все же не эталон производительности, нужно брать оптимизированные под конкретную платформу варианты, например Intel MKL, AMD core math library.
P>Я сравнивал АЛГОРИТМЫ у меня ровно N^3 операций, у них больше. 2/3*N^3 на LU разложение и там еще на нахождение обратной, итого у них больше получается.
В жизни все как правило не так просто. Например, для решения задачи линейного программирования, например, существует алгоритм с полиномиальной сложностью(метод эллипсоидов), но пользуются все симплекс-методом, который на большинстве реальных задач значительно быстрее. Знаешь сколько статей типа "исследование производительности метода N в применении к матрицам типа M" существует? Их не просто так пишут.
SC>>А код такой я бы если и написал — то точно бы постыдился показывать
P>Да че в нем не так? Уж удобней чем 2 библиотеки тянуть
Как бы это помягче, у меня создалось впечатление, что автор намеренно пытался ввести в заблуждение читателей этого кода. Форматирование и названия переменных просто психоделические, константы типа 1e99 вызывают нервный смех

Что так или не так в самом алгоритме сказать не могу — мне жалко мозг разбираться.
--
Sergey Chadov
... << RSDN@Home 1.2.0 alpha rev. 685>>