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

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

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

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

спасибо.

Если вы к MATLAB'у привыкли, то надо однозначно выбирать scilab. Тут, по крайней мере, хоть какая-то аналогия будет, а в некоторых местах даже прямая подстановка. Тем более что в пакете scilab есть практически все, что есть в MATLAB.

А чего вдруг MATLAB от вас закрылся? Или это вы от него закрылись в приступе патриотизма?

Ну лицензия на Матлаб не такая уж дешевая.

А зачем же ее покупать-то?

адски плюсую, нужно санировать авторов софта по этой части. А по сабжу я бы выбрал оба, Scilab как математика, а питон всегда пригодиться.

Еще есть Octave. Пока выбирал, чем пользоваться, что-то скачивал, пробовал. Но лучше Matlab быть ничего не может (если не покупать).

У меня впечатление от octave даже лучше чем от scilab. Да и с matlab он пытается быть совместим, в отличии от scilab. Но я пользуюсь в основном самим языком для работы с матрицами, а не библиотеками для прикладных задач.

Питон объединяет великое множество и другого софта, в т.ч.
у scilab имеется питоно-морда
Однозначно питон.
-----------------------------------

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


с этим полностью согласен

Так это любой язык программирования ровно так же "объединяет множество софта", на нем написанного.

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

Например, существуют богатые по возможностям библиотеки для C и/или FORTRAN'а: MKL (Intel Math Kernel Library), IPP (Intel Integrated Performance Primitives), ATLAS (Automatically Tuned Linear Algebra Software), NAG (Numerical Algorithms Group), IMSL (International Mathematics and Statistics Library) и т.п., однако приходится попотеть, чтобы с их помощью хотя бы вектор на матрицу умножить - слишком много в тех функциях параметров, а том числе и малопонятных. Тогда как в матпакетах такого рода опрерации делаются элементарно - записью, предельно близкой к алгебраической.

Во-первых, numPy не что иное как обертки над MKL, ATLAS, LAPACK, BLAS
nagPy ... NAG
PyIMSL ... IMSL

во-вторых, питон это несколько бОльшая сущность в сравнении с "вездесущим" вижуал бейсик на венде.

А бывают ли такие обертки для C++? Чтобы Питон не учить на C++ остаться, но так хитро определить классы (и операторы внутри них) матриц и векторов, чтобы алгебраические операции над ними можно было проиpводить в записи, приближенной к математической? Т.е. обычными 4-мя арифметическими действиями.

Вот только как быть с транспонированием, не знаю, т.к. апостроф С++ переопределить не даст.

P.S. Вопрос не только к Pasha, но и всякому, кто видел что-то подобное в уже реализованном виде. А лучше - еще и пользовался этим.

Как бы обманывать язык смысла нету особого...
Сразу приходят на ум MathCAD и язык APL...
Но маткад - это ж еще и символьные операции.

Короче
http://twt.mpei.ac.ru/ochkov/MAS_KP/mas_kp.html

http://twtmas.mpei.ac.ru/mas/Worksheets/Pendulum_DAE.mcd например

Облачный маткад...

"В связи с санкциями пиратский софт считать трофейным".

Обмана здесь нет, т.к. в языке C++ определение операторов (в том числе и арифметических) в отношении "самодельных" классов - типичная практика, т.к. по умолчанию объект наделяется только оператором присваивания, который реализуется копированием области данных между объектами одного и того же типа.

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

Но поскольку это объекты, то почему бы не определить между ними арифметические операции? Тем более что само понятие "межклассового" оператора именно для этого и было введено.

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

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

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

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

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

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

поставил на ура питон 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
на реализацию которых упирает автор статьи, очевидно реализуются без проблем, поскольку они бинарны, а не тернарны.
Тогда как организовать бинарным оператором операцию умножения в общем случае невозможно, т.к. там продукт может иметь иную размерность, чем каждый из операндов.

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

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

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

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



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

В более прямых языках, коим считаю паскаль, это называется property.
Причем, путаницы из-за ленивого стиля не возникнет никогда, поскольку у нас есть имя класса.

Добавлю свои 5 копеек... Python для меня - открытие года. Фактически убил во мне юзера Матлаба, коим я пользовался более 10 лет...
Есть все что надо - от символьных вычислений и квантовых алгоритмов до мощной графики. Переучиться получилось довольно быстро и весело. Так что рекомендую!

А как на Питоне МК программировать?

Очень просто. Забыть в данном случае о питоне и пользоваться LUA.

Я не знаю. Мне это не надо это уже давно не входит в круг моих интересов.

Максимум куда дотягиваются мои шаловливые руки - это общение с кучей аппаратуры Agilent/rohde&schwarz по GPIB. Раньше у меня это студент на Matlab делал, но мне всегда казалось что это не comme il faut... так что теперь все работает под python

Я правильно понимаю, что для этого нужен только бесплатный Питон, и всё? А если передавать заказчику программу управления прибором, то им тоже нужно будет установить питон?

Нужно еще как минимум pyVISA Так же это дело может потребовать NI-VISA библиотеки (бесплатые) установить отдельно. У меня это работает и под Windows и под Mac

У меня нет заказчиков, работаю для себя В принципе, всегда можно установить эти вещи, на них нет особо ограничений.
Так же известно что можно скомпилировать код python в исполняемый exe файл и делать установку python. Для этого есть много утилит и не только для Windows. Как это будет работать c дрйверами и аппаратурой, я не знаю.

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

Какую версию Питона предпочитаете использовать?


Хорошо, что кто-то додумался всю эту тучу пакетов и библиотек для Питона, да еще и с нормальной IDE,
скомпоновать в один дистрибутив, ориентированный на научные вычисления. PythonXY

ХУ нету под линь
Закономерный вопрос про ХУ vs Анаконда
Кто владеет вопросом?

а также, совсем недавно пересел на spyder, доволен как слоняка.
Кто мне может объяснить, чем спайдер хуже указанных анаконды и ху?

Спайдер окружение (Scientific PYthon Development EnviRonment), которое использует PythonXY.
У меня он запускается под виндой вместе с PythonXY.
Просто под Линуксом надо самому собирать все в кучу, насколько понимаю.
Поэтому не совсем понятен вопрос «чем спайдер хуже xy?».

Случайно два раза отправилось.

Теперь понятно.
ХУ чтоб ставить нужна венда, а ее, скажем так, нету.

А до того включал geany, в терминале запускал ipython
аццкие муки творчества на больших массивах данных.
Уровень конечно супер.


А про анаконду кто что может сказать?

Я пока использую Python 2.7 + Anaconda + PyCharm CE или iPython (под настроение). Не спрашивайте почему Наверное, потому что все и так работает.

На сколько понимаю, вопрос про смешанную арифметику (матрицы-вектора), но не очень понимаю в чем проблема. В с++ можно определить операторы, не являющиеся членами класса и принимающие два разных аргумента

//умножение матрицы справа на вектор
vec operator*(const mat& left, const vec& right);
//умножение матрицы слева на скаляр
mat operator*(const double& left, const mat& right);

ну и т.п.

Смешанная арифметика реализована в библиотеке it++, http://sourceforge.net/projects/itpp/, это достаточно простая и не очень быстрая (из-за отсутствия ленивых вычислений) библиотека, LAPACK-BLAS используются. Но мне ее вобщем хватает. Не хватает только размещения маленьких матриц на стеке, матрицы и вектора всегда создаются в куче. Для использования лучше брать последний код из git. Релизы у них очень старые. Для сборки используется cmake.

Если ищете производительности и навороченности, то лучше смотреть в сторону armadillo, http://arma.sourceforge.net/, Тут все - отложенные вычисления, использование BLAS-LAPACK, матлаб-подобный синтаксис. Есть несколько проблем - не все поддерживается для матриц с произвольными типами данных внутри (для double, std::complex<double> проблем нет, но есть скажем для int), сложноватый код (широко используется шаблонное метапрограммирование) для тех, кто не очень ориентируется в с++. Впрочем, использование библиотеки проблем не вызовет.

Что-то не пойму. Попробовал я pythonXY.
А там spyder какой-то настолько убогонький и вообще как-то оно неудобно в использовании, что мне стало грустно. Spyder для линукса гораздо функциональнее.

Интересная тема. Обожаю Matlab со всеми его плюшками для обработки и визуализации экспериментальных данных, GUI и прочими прелестями. Однако, дико бесит отсутствие мультизадачности, как в C++, на котором раньше создавал программы для работы с периферийными устройствами. Банальный пример: нужно отправить данные в периферию и ждать результата измерений, но делать это не в основном трэде чтоб вся GUI не висла, а в фоне. Такое в матлабе невозможно кроме случая прикручивания C-шной библиотеки с отдельно написанным трэдом.
Посему изучаю переход на что-нибудь совмещающее в себе матлабовскую лёгкость в обработке данных, красивую визуализацию и мультитрэдинг. Видимо, это будет Phyton, но не хотелось бы еще один язык изучать.