scilab vs python, что выбрать? Опции

[shf_05]

добрый день, коллеги.

ранее долгое время применял матлаб для создания m файлов, простенького gui, работы с com портами, файлами.

теперь матлаб для меня закрыт, встал вопрос использовать "бесплатное" ПО, выбираю между scilab и python.
задачи по обработке сигналов, алгоритмы в основном свои, так что интересует в первую очередь удобство визуализации результатов, возможность создания всевозможных фильтров, создание gui b работа с железяками.
посмотрел примеры и того и другого вроде примерно на одном уровне, но может быть это только на первый взгляд?

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

спасибо.

[amaora]

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

[Xenia]

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

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

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

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

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

[shf_05]

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

[Xenia]

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

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

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

[shf_05]

поищите C=A×B или // Left multiplication of this matrix and another
я так понимаю, на примере того, как сделал автор, можно перегрузить оператор * , чтобы он умножал какие угодно матрицы с предпроверкой их размерностей.

[Xenia]

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

Я в собственной реализации перегружала оператор "=", нагружая выполнение операции именно на него, поскольку только в этом операторе известен адрес приемника результата. Тогда как операторы действий "+", "-", "*" возвращают у меня всего лишь малую структуру с адресами обоих операндов, флагами их транспонирования и типом операции (т.е. два адреса и один байт с флагами).

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