Нужна информация о GNU octave

Я думал, там многое позаимствовано из Матлаба. Насколько серьезные отличия? И да, почему именно он? По мне, Матлаб намного лучше.

Матлаб - платная программа. Вообще, раньше я пользовался mathematica, но хочется попробовать что-нибудь типа бесплатное, тем более лето, время есть на изучение.

http://xgu.ru/wiki/GNU_Octave http://www.linux.org.ru/wiki/en/LOR-FAQ-Scientific

На Library Genesis

Полноценный учебник на русском по GNU/Octave писать элементарно коммерчески не выгодно, поэтому лучше начать с официальной документации.

> Вообще, раньше я пользовался mathematica, но хочется попробовать что-нибудь типа бесплатное, тем более лето, время есть на изучение.

А для каких целей использовалась mathematica? В смысле какие задачи решались? Может оказаться, что показан более другой инструмент.

По-моему, Матлаб куда больше подходит для ознакомления. Все, что есть в хелпе, замечательно работает. В Октаве же подобного никто не гарантирует, да и отсутствия критичных ошибок тоже. Все же, для научных расчетов достоверность результатов - на первом месте, чтобы краснеть за просчеты не пришлось и обнаруживать глюки в самых неподходящих местах.

Я вижу вы уже проинспектировали исходники матлаба, что можете гарантировать его надёжность.

IMHO использование систем анализа с закрытыми исходниками должно стать моветоном в научных исследованиях.

IMHO использование систем анализа с закрытыми исходниками должно стать моветоном в научных исследованиях.

Я тоже так считаю. Но несмотря на ваше и мое мнение, свободные библиотеки (GSL) хуже, чем NAG Fortran Library; Maxima хуже, чем Mathematica/Maple; Octave хуже, чем MatLab. Вы, как понимаю, утверждаете обратное? Рассчитывать на подобное можно будет только, когда Octave или свободные CAS станут настолько же распространенными, как MatLab и Mathematica.

> Вы, как понимаю, утверждаете обратное?

В моей области деятельности свободные инструменты действительно превалируют. Как-то так.

В моей области деятельности свободные инструменты действительно превалируют. Как-то так.

Это замечательно. В моей области (физика) - наоборот. В западных университетах в основном пользуются Mathematica (видел своими глазами), и MatLab у них можно найти. Как Maple, так и Mathematica содержат улучшенный код из Maxima 90гг, открытый код Maxima - из 80х, когда еще критические куски кода не были переписаны с Лиспа на Си. В СПбГУ на физфаке есть курсы, где основной инструмент - MatLab. Возможно, мы говорим о разных инструментах?

> В моей области (физика) - наоборот.

Сюрприз: моя область тоже физика.

Возможно, мы говорим о разных инструментах?

Да, я не использую ни MatLab, ни Mathematica.

Как Maple, так и Mathematica содержат улучшенный код из Maxima 90гг, открытый код Maxima - из 80х,

а) Maxima с тех пор немного продвинулась

б) Мне напомнить что произошло с Macsima? Вы точно уверены, что этого же не случится с Mathematica? А ведь судьба Mathematica зависит ровно от одного человека малость «двинутого» на клеточных автоматах.

>А для каких целей использовалась mathematica? В смысле какие задачи решались? Может оказаться, что показан более другой инструмент.

В основном не сложные расчеты. Работа с массивами данных. Еще немножко циклов и условных операторов. Аналитические способности математики не использовались. Грубо говоря, использовалась как продвинутый калькулятор.

Хочу перестать работать в математике только по одной причине: у меня нет лицензии. Так что смысла нет Матлаб мне ставить.

Ладно, буду wiki читать да разбираться потихоньку. Всем спасибо.

> В основном не сложные расчеты. Работа с массивами данных. Еще немножко циклов и условных операторов. Аналитические способности математики не использовались. Грубо говоря, использовалась как продвинутый калькулятор.

То есть CAS вам как бы и не нужен.

Гляньте тогда в сторону R. Немного тут: http://www.inp.nsk.su/~baldin/DataAnalysis/index.html R — это потенциальный способ избавится при анализе от циклов вообще :)

В моей области деятельности свободные инструменты действительно превалируют. Как-то так.

Да, я не использую ни MatLab, ни Mathematica.

Противоречивые высказывания, вам не кажется?

а) Maxima с тех пор немного продвинулась

Критические части уже переписаны на Си? Сейчас больше надежд на SymPy, где такой подход изначально.

б) Мне напомнить что произошло с Macsima? Вы точно уверены, что этого же не случится с Mathematica? А ведь судьба Mathematica зависит ровно от одного человека малость «двинутого» на клеточных автоматах.

Не знаю, что станет с Mathematica или Maxima, хотя я вас понимаю. На мой взгляд, проблема Maxima, что она написана на Лиспе, специалистов по которому почти не осталось. SymPy написан на Питоне, поэтому даже вы или я при желании можем добавлять новые возможности. В этом году он представлен и на Google Summer. Но наш разговор был про Maxima и Mathematica, Octave и MatLab.

Гораздо больше пользы будет от изучения Питона. Смотрите в сторону NumPy, SymPy.

> Противоречивые высказывания, вам не кажется?

В каком месте?

Критические части уже переписаны на Си? Сейчас больше надежд на SymPy, где такой подход изначально.

Вы качестве меряете по языку инструмента?

Не знаю, что станет с Mathematica или Maxima, хотя я вас понимаю. На мой взгляд, проблема Maxima, что она написана на Лиспе, специалистов по которому почти не осталось. SymPy написан на Питоне, поэтому даже вы или я при желании можем добавлять новые возможности. В этом году он представлен и на Google Summer.

Аааа, понял. Типа популярный язык популярнее :) IMHO смерть лиспа сильна преувеличина. А при желании новые возможности добавить в Maxima не сложнее чем в SymPy.

Но наш разговор был про Maxima и Mathematica, Octave и MatLab.

Вообще-то, как выяснилось, топикастеру CAS как бы и не особо то и нужен, как и подавляющему большинству научных сотрудников вообще-то. Так что я не вижу смысла ограничивать себя исключительно этими инструментами.

> Гляньте тогда в сторону R.

Интересно, а учебничек на русском может есть какой?

> Интересно, а учебничек на русском может есть какой?

Планировался, но к сожалению похоже не срослось :( Цикл статей по ссылке выше должен был составить примерно 20-25% от итогового объёма.

> Противоречивые высказывания, вам не кажется?

В каком месте?

Вы сначала пытались утверждать про свою область деятельности, но в действительности, это вы пользуетесь свободными инструментами. Последнее утверждение мне понятно, а вот с первым я позволил себе не согласиться.

Вы качестве меряете по языку инструмента?

Нет, но считаю написание критических по производительности мест на Си правильным подходом. А представление матриц в виде лисповских списков ему сильно проигрывает по производительности.

Аааа, понял. Типа популярный язык популярнее :)

Нет, но в сравнении библиотек для научных задач в Питоне больше, в том же Sage. Хотя, конечно, другим может нравиться создавать велосипеды.

IMHO смерть лиспа сильна преувеличина. А при желании новые возможности добавить в Maxima не сложнее чем в SymPy.

Пока Лисп не совсем RIP в основном из-за CAS (Maxima, Axiom). Сейчас его еще пихают в веб, но не с таким большим успехом. Сравнением языков заниматься не хочется. Но в чем-то SymPy уже, наверное, лучше Maxima, да и развивается намного интенсивнее.

> Вы сначала пытались утверждать про свою область деятельности, но в действительности, это вы пользуетесь свободными инструментами. Последнее утверждение мне понятно, а вот с первым я позволил себе не согласиться.

Ваше право, но в моей области деятельности действительно свободные инструменты превалируют и ничего с этим не поделаешь.

Пока Лисп не совсем RIP в основном из-за CAS (Maxima, Axiom).

Вы как-бы кое-что упустили из виду, например, emacs. IMHO Python рипнется или кардинально видоизменится гораздо раньше чем лисп.

Вы как-бы кое-что упустили из виду, например, emacs. IMHO Python рипнется или кардинально видоизменится гораздо раньше чем лисп.

Мне все равно, что лучше - Питон или Лисп. Я изначально сравнивал различные CAS. В защиту Питона - он был создан в начале 90х и до сих пор, как видите, вполне живой. Emacs - это не Common Lisp (чаще всего его называют Лиспом), на котором написана Maxima, в стандарт ANSI Common Lisp входит целый зоопарк функций, CLOS и много чего еще. Elisp намного проще, а конкретно для Emacs используется CEDET. Это не совсем то, что писать на Elisp, куда уж до такого монстра как Common Lisp.

Критические части уже переписаны на Си? Сейчас больше надежд на SymPy, где такой подход изначально.

$ tar atf sympy-0.6.7.tar.gz |grep '\.c'
sympy-0.6.7/doc/apidoc.conf

Гм.

Видимо, на счет SymPy я здорово ошибся. Сейчас меня закидают гнилыми помидорами :( Это у них только в Some ideas for future development:

rewrite the core to C++ or C or Cython, and use it as an optional module, if the user would like to speed things up (in any case the Python core will always be the default)

В принципе, уже есть sympyx (ядро sympy, переписанное на Cython), и sympycore (форк sympy вроде как с опциональным ядром на C). Оба показывают очень неплохие результаты не только по сравнению с чисто питоновской реализацией sympy, но и с другими математическими пакетами (где-то в гуглогруппах было сравнение). Но судя по всему, оба еще пока не допилены, раз пункт про переписывание ядра до сих пор висит в списке предложений GSOC.

Для численных вычислений (символьные тебе походу и не нужны) можно попробовать python + numpy + scipy.

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

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

Питон не настолько сложен, вон, даже океанологи освоили. Приведу альтернативное мнение отсюда:

First of all: Maple is a wonderful product. Yes, it is. However, when you start writing large-scale applications you are doomed to run into trouble with it unless you are extremely careful and know exactly what you are doing. One important problem with Maple (and any other CAS) is the lack of a standardized up-to-date language. For instance, the concept of Object Oriented design is not present. Quite generally, facilities for encapsulation are poorly developed. Maple's language is dynamically scoped and from time to time you find that Maple's developers messed up with that by not properly declaring variables to be local resulting in obscure (history-dependend) bugs. How are we supposed to write scientific software with the language even the Maple developers have problems to handle? Mathematica and Macsyma face the same problem, by the way.

> Питон не настолько сложен

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

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

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

> Извините, не пойму: вы специально отвечаете на удобные вам вопросы, а остальное игнорируете?

Я отвечаю на важные и интересные с моей точки зрения вопросы. И да — я не считаю отсутствие ООП сколько-нибудь значительной проблемой.

И да — я не считаю отсутствие ООП сколько-нибудь значительной проблемой.

Действительно, а зачем? ООП позволяет самому делать расширения языка и использовать в дальнейшем. В больших проектах, а уже сейчас такие пишут на MatLab/Mathematica, это дает удобную возможность для включения различных модулей, подпрограмм. К счастью, разработчики Фортрана уже прозрели на счет ООП, когда ж прозреют пользователи Maxima и т.п.? Писать большие проекты на нем невозможно, но, я так понимаю, что вам достаточно функций продвинутого калькулятора?

> ООП позволяет самому делать расширения языка и использовать в дальнейшем.

Сюрприз, но есть масса способов сделать это помимо использования ООП. В реале же использование ООП не очень опытными пользователями — это лёгкий способ прострелить себе ногу.

Сюрприз, но есть масса способов сделать это помимо использования ООП.

Ну да, только зачем во все эти современные языки глупые дяди суют это свое ООП? Вы бы им разъяснили, глупым, как надо - глядишь, и польза была бы.

В реале же использование ООП не очень опытными пользователями — это лёгкий способ прострелить себе ногу.

«Enough rope to shoot yourself in the foot» (rules for C and C++ programming) Allen I. Holub. Published 1995.

Сколько ж можно всех пугать этой детской страшилкой?

> Ну да, только зачем во все эти современные языки глупые дяди суют это свое ООП?

Мода, такая мода...

Сколько ж можно всех пугать этой детской страшилкой?

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

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

Ножом тоже порезаться можно, ну что? Это ж не значит, что он не нужен. С ООП - то же самое. Мода - модой, но ничего лучше пока нет.

Я не сказал, что ООП совсем не нужен. Я сказал, что отсутствие ООП весьма незначительная проблема. Для инструмента анализа более важным является наличие удобных структур из коробки соответствующих обрабатываемым данным. В случае, скажем ROOT — это гистограммы и нтаплы (или деревья), R — вектора, а, например, SQL — таблицы.

В случае, скажем ROOT — это гистограммы и нтаплы (или деревья), R — вектора, а, например, SQL — таблицы.

В чем тогда спор, если подобного нет ни в Maxima, ни в SymPy? Тут они в равной степени плохи. И зачем все это в CAS?

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

Единственное достоинство, что осталось, — совместимость с Matlab. Совместимость, если честно, посредственная. И необходимость в ней — вещь спорная.

Так что народ сейчас использует, в зависимости от потребностей и умений, scilab, python, R. По всему этого литературы масса.

Главное определитесь с областью применения. Если мне необходима обработка сигналов, то я и читаю соответственно «Signal Processing With Scilab».