Про питон ничего сказать не могу, но Scilab вполне пригоден для моделей малой и средней сложности. Он довольно шустрый и начиная с 5.4 обзовелся нормальной мордой, неплохая стандартная библиотека (полная поддержка матричных вычислений, фильтрация/свертка/Фурье, а остальное можно сделать самому, открыв книжку по ЦОС ). Моделировал на нем алгоритмы приёмника/передатчика, считал интерполяторы/дециматоры, соединял все это добро с HDL симулятором, работать можно. Из явных минус в сравнении с матлаб: нет fixed-point функционала, нет симулинка, нет встроенных функций помехоустойчивого кодирования (ну это проблема для меня была, не мог я сделать на нем полной модели приёмника, а кому то может и не важно это совсем )

Сообщение отредактировал serjj - Dec 26 2014, 13:48

А, так это вполне нормальная практика. Я Вас просто недопонял.
Скажем, мне С++ не близок, но в паскале такое не стесняюсь делать.

ну маета с установкой питона!

поставил на ура питон 3.4 x64, после этого библиотеки matplotlib ipython и т.п. ни в какую не хотели вставать, и visaul studio express всех мастей поставил и SDK со всевозможными компиляторами (не пробовал только mingw и gcc, полагая, что под WIN 7x64 лучше использовать компилятор от MSVS), пробовал советы из инета - все безрезультатно.
в итоге - установил пока pyzo2014a, правда не знаю насколько это универсальная штука
коллеги, посоветуйте, пожалуйста (!) наиболее совместимую конфигурацию - версия питона, компилятор, так, чтобы созданное ПО работало в т.ч. и на других машинах - речь о WINx (чаще всего 7x64), планирую применять matplotlib, ipython, notebook...

Python 2.7 + VCForPython27
Python 3.4 + Visual C++ 2010 Express

Приличных оберток не видел, но есть alglib от Сергея Бочканова, где есть попытки прикрутить операторы куда нужно. Поскольку там уже все в классах, то, наверное, можно попытаться расширить список операций под свои нужды.

Про Alglib давно знаю и даже коллекционирую ее версии на ftp, однако стиль использования этой библиотеки мне сильно не нравится. Т.е. меня-то интересуют именно варианты "прикручивания", а не библиотеки, которые выполняют работу. Тогда как Alglib сильно "недокручена", поскольку требует явного вызова функций.

Умножение двух матриц, на мой взгляд, должно выглядеть (на C++) так:

где: RealMatrix - класс с конструктором, аллокирующий для матрицы место в памяти и запоминающий обе ее размерности.
А дальше идет сплошная алгебра, по записи мало отличающаяся от математической.

В сущности все три операции (*,+,-) совершенно тривиальны - их самой написать проще, чем библиотеки подключать. А потому проблема состоит только в том, чтобы компилятор компилировал непосредственно алгебраическую запись типа C = A * B, превращая ее в вызовы функций неявно. А вот такого "счастья", которое предлагает мне Alglib, мне задарма не надо:
Жуть! Даже не верится, что это C++. Впечатление такое, что авторы библиотеки этого языка не знают, если настолько последовательно игнорируют его возможности.

почему бы хотя бы не например ?

взять питон - дак вообще судя по всему для массива и матрицы у него значок * разное значит - как бы не запутаться вовсе...

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

я имел ввиду, если использовать Numpy http://wiki.scipy.org/NumPy_for_Matlab_Users

Интереснее было бы компилировать код в алгебраической записи (на matlab языке или ином) в оптимальный код на C. Так, чтобы использовались известные свойства матриц. Например разреженность может заметно сократить количество операций при умножении. Матрицы могут быть симметричными, диагональными, ортогональными и т.д. Все это можно использовать при генерации оптимального по быстродействию (или другому критерию) кода. Давно ищу что нибудь подходящее. Самому за такое браться, серьезная задача.

Может заинтересует SMath?
http://ru.smath.info/

Те кто занимаются графикой (OpenGL/D3D), играми и близкими к этому задачами давно уже так делают. А сейчас с использованием новых стандартов наверно улучшили свои решения, сам я давно уже не слежу, что там происходит. Но у них обычно фиксированные размерности не выше 3, геометрия.

Если матрица диагональная, то ее хранят в векторе . А такие свойства, как симметрия и эрмитовость, обычно не позволяют ускорить операции сложения, вычитания и умножения, поскольку для этого требуется, чтобы ОБА операнда обладали таким свойством. Что же касается разряженных матриц, то это скорее не алгебраическая проблема, а ... "процессоростроительная", т.к. касается только того, способен ли FPU быстрее выполнять бинарные операции, если один из операндов нулевой. Причем, в электронной реализации (а так же на FPGA) такая проверка операндов на нулёвость не привела бы к замедлению арифметики с прочими числами, поскольку признак нулёвости регистра всегда можно сделать схемотехническим, экстренно отменяющим выполнение операции. Но если процессоростроители этого не предусмотрели, то проверять каждый операнд на нулёвость в программе будет не менее накладно по времени, чем честно умножать на нуль.

Тем не менее, я веду речь исключительно об удобстве использования арифметических операторов в матрично-векторных выражениях и ни о чем другом, т.к. всё другое традиционно производится через явные вызовы функций, а не средствами операторов. И если уж у вас обе матрицы настолько заковыристые, что их произведение через ухо вычислять быстрее, то и не пользуйтесь тогда операторами, а вызывайте для них функцию, которая вычисляет результат через ухо.

В конце концов, языки высокого уровня родились вместе с Фортраном, когда стало допустимо записывать арифметические операции посредством четырех операторов (+,-,*,/), используя скобки, и именно это вызывало бум! Потому как с помощью явного вызова функций можно было бы припеваючи продолжать жить на ассемблере.

Отсюда и вопрос мной поставлен так: допускает ли механизм определения операторов языка C++ определить их для матриц и векторов таким образом, чтобы три операции (+,-,*) над ними имели естественно-арифметический вид записи? Если да, то почему это до сих пор не сделано производителями библиотек линейной алгебры? А если где-то уже сделано, то где именно?

Xenia вы искали это?
http://www.quantstart.com/articles/Matrix-...The-Source-File

Нет, этого я не видела. Но даже и с вашей подачи не могу найти в этой статье место, где бы автор производил умножение C=A*B в операторном виде. Слишком ж там кода много вывалено, что пример, если он и был приведен, то там утонул.

Тогда как операции типа
A+=B
A-=B
на реализацию которых упирает автор статьи, очевидно реализуются без проблем, поскольку они бинарны, а не тернарны.
Тогда как организовать бинарным оператором операцию умножения в общем случае невозможно, т.к. там продукт может иметь иную размерность, чем каждый из операндов.