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

[shf_05]

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

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

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

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

спасибо.

[amaora]

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

[Xenia]

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

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

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

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

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

[amaora]

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

Я говорю о "compile time" оптимизациях, то есть во время выполнения уже не будет производится умножения на ноль или единицу. В фильтре Калмана таким образом можно много операций исключить. Симметрия матриц ковариации тоже помогает делать меньше вычислений, и память экономит. Но руками под каждую задачу это делать долго, и ошибок много.

...

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

Если посмотреть на boost обертку над blas то становиться понятно, что есть много вариантов операции *, поэтому они определены через свои названия а не символом умножения.