Библиотека для работы с матрицами - страница 2

Работа над библиотекой продолжается.

По замечаниям AlexEro был немножко пересмотрен стиль кода (чуть короче имена переменных в особо выдающихся местах, чуть больше пробелов, более логичная классификация функций, у некоторых слегка изменены имена). Добавлено вычисление матрицы At*A по заданной A (например, для нахождения псевдорешений СЛАУ). Была произведена небольшая оптимизация (не в ущерб качеству и понятности кода). Вынесены некоторые инварианты из циклов, сокращены вычисления. Повторное тестирование (тем же скриптом, что и в первом архиве; заменено имя одной функции) показало некоторое увеличение скорости работы. Обращение матрицы (условия и метод те же, что и в первом посте):

• 100x100 - 922 ms (выигрыш - 62 миллисекунды)
• 200x200 - 7281 ms (выигрыш - 750 миллисекунд)
• 500x500 - 113750 ms (выигрыш - 11265 миллисекунд) :)

Код будет выложен позже.

В соседней ветке был поднят вопрос об оценке обусловленности матриц (как я понял, именно это имел ввиду AlexEro, когда говорил про отношение наибольшего к наименьшему собственных чисел матрицы). К сожалению, с собственными векторами/числами я ещё не знаком, а нормальных описаний алгоритмов я не нашел. Есть вероятность, что разберусь по коду из alglib (используется LU разложение). Вобщем, над этим вопросом я ещё думаю. Если успею сделать всё и сразу (описание, примеры, оценку обусловленности) до начала учебного года - будет здорово.

RIV, если вы заинтересованы в тестировании оборудования - воспользуйтесь скриптом из первого архива (сообщения выводятся во вкладке "Эксперты" терминала). Я в этом не заинтересован, да и свободного времени маловато.

>>  lea

Да интересно было бы ... но народ может не поверить в результат если я сам бы сделал ... 

Когда матричные вычисления и/или модели переступают некоторый порог сложности, любые профи обязаны задать себе вопрос :"ребята, а что мы считаем?" И вот иногда оказывается, что профи-ребята который месяц подряд считают ... шум, или иначе говоря погрешность задания матрицы такова, что сложный алгоритм на ДАННОЙ БОЛЬШОЙ размерности матрицы просто теряет смысл. Оценить это можно разными способами, например обусловленностью. Образно говоря, это нужно чтобы не свихнуть свою модель и не начать видеть в валютных расчётах кольца Сатурна (которых там нет).

http://www.realcoding.net/teach/Matlab/Glava%2011/Index2.htm

" Числа обусловленности матрицы определяют чувствительность решения системы линейных уравнений к погрешностям исходных данных. Следующие функции позволяют найти числа обусловленности матриц.

• cond(X) — возвращает число обусловленности, основанное на второй норме, то есть отношение самого большого сингулярного числа X к самому малому. Значение cond(X), близкое к 1, указывает на хорошо обусловленную матрицу;"

Первое что пришло на ум - 

Dll, в которое есть таблица указателей на объекты. Вам возвращается хэндл,

который используется для всех операций над объектом.

.

int Матрица1 = CreateMatrix(3, 3);

int Матрица2 = CreateMatrix(3, 3);

int Матрица3 = CreateMatrix(3, 3);

MultiplyMatrix(Матрица1, Матрица2, Матрица3);

FreeMatrix(Матрица1);

FreeMatrix(Матрица2);

FreeMatrix(Матрица3);

.

Задание значений поштучное, вероятно, подтормаживало

бы по сравнению с нативным Mql кодом, но это окупилось бы

- скоростью расчетов

- проверкой индексов

использованием возможностей языка C++:

классов, исключений и т.д.

.

Разрешите задать вопрос: почему не был выбран такой способ?

Объем кода класса - больше 100 кб. Кроме того, класс матрицы тащил за собой класс векторов (мое видение vector<>, предназначенное для выполнения мат. операций). Изначально я писал этот код с целью обработки данных во внешней программе, а не с целью привязки к mt4.

Кроме того, был опыт создания библиотеки с функциями-заглушками - один в один с вашим предложением. И этот опыт показал, что проще переписать на mql с учетом его особенностей. Вообще я считаю, что реализовывать подобный интерфейс к объектам - по меньшей мере не серьезно (если уж так нравятся функции - нужно и делать функции, а не "обертки" к методам классов; не ко всем методам можно сделать "обертки").

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

Проверка индексов затруднений не вызывает.

Обработка исключений в классе матриц имхо не нужна - это лишние тормоза, т.к. проверка всех возможных проблем не вызывает трудностей.

Можете попытаться меня убедить в нелогичности моих убеждений.

Мне показалось, что написать интерфейс для dll- это быстрее, нет переделок.

А вообще- насколько мне известно- в случае, если требовалось вызывать код из C,

народ так обычно и делает- пишет на С++ и выставляет требуемый интерфейс на С.

И если конкретно про С- то я на С писать не буду в принципе :-).

Поздно подлючаюсь, но это к сожалению не совсем верно:

1. На нужен обязателно Интел-компайлер, нужна поддержка многопотоковости. Стандартные Visual Studio 2005 и 2008 работают у меня, managed code.

2. В программе это надо не слегка, а ПОЛНОСТЬЮ учитывать, раскидывая вычисления на потоки. Может Linpack это и упрощает, но не в этом суть. ОС раскидает вычисления по ядрам. Как это сделать - посмотрите например документацию MS по ThreadPool.

А тут пример матричных вычислений с Parallel.For:

http://msdn.microsoft.com/en-us/magazine/cc163340.aspx

1. Вот как? Интересно, интересно. Уточняю, коллега - речь идёт о способности САМОГО компилятора раздерибанивать векторные/массивовые задачи по ядрам (точнее по центрам спекулятивной обработки отдельных операций внутри процессора). Речь не идёт про дерибан задачи в паралеллизм ручками программиста по потокам спланированных им threads. Речь идёт о том, что компилер делает ВСЁ ЭТО САМ. Какая версия VS это делает САМА, чтобы linpack безо ВСЯКИХ изменений в тексте считался на 20-30% быстрее? и с помощью каких свичей компилятора? Я жестоко подозреваю, что Вы, коллега, просто неглубоко поняли о чём шла речь.

2. Следует из последнего предложения п.1. Это совсем разные задачи по объёму работы: ИЛИ подключить Интел-компилер и всего лишь задать пару свичей ИЛИ распределить всю задачу по тредам, переписать подпрограммы, синхронизировать их... и так далее в бездну.

Никакая версия VS ниче не делает сама, я это и написал. Если для вас это бездна, то остается действительно только надежда на магию Интела, за 799$ (спасибо за инфу кстати что они такое делают, конечно неизвестно насколько хорошо, но для меня задорого). Во вторых вы все-таки пургу написали про один процессор: "...на один поток (одну программу EXE) всегда работает ОДИН процессор - на расчёт, а второй - на обработку графики GUI (всего два)". Почитайте ссылки которые я добавил и все станет на места.

Дядя хакер, к чему это Ваше мухлевание? У меня там стоИт слово "ИНАЧЕ", (которое Вы дядя хакер преднамеренно скрыли) что является продолжением предыдущего предложения.