Matplotlib 1.1.0

Я строил графики с Metapost, есть даже в статье. Изменить можно всё + Latex-шрифты. Но больно сложно там всё описывать, буду осваивать Asymptote. Китайцы умудряются и в matlab делать угрёбищные графики.

Я не интересовался, т.к. немного зная make оный рецепт получается из 3-х строчек за 45 секунд. Кроме того, конкретный рецепт зависит от статьи. В иной статье, например, данные (экспериментальные) не меняются, а работа идет над обработкой, поэтому имеет смысл поставить в зависимости не файл с данными, а файл с программой и т.п.

Поэтому не вижу ценности в публикации таких рецептов. Слишком каждая задача уникальна. И если знаешь как решить её с gnuplot, автоматически знаешь как с matplotlib.

Я Matlab имел ввиду. В Matplotlib можно вертеть текст. :)

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

что-то я стормозил, и не понял, что имеется в виду матлаб, а не матплотлиб. В матлабе — да, наверное, давно в нем ничего не строил.

>Поэтому Origin.

Что в нем хорошего-то?

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

Тогда почему не octave/matlab? Возможностей всяк побольше. А для быстрых вычислений есть fortran. И для него написано море библиотек.

питон же это что-то промежуточное. Недостаточно быстр и при этом по возможностям уступает octave.

> питон же это что-то промежуточное. Недостаточно быстр и при этом по возможностям уступает octave.

Откуда это всё? Про NumPy / SciPy (те же коды на Fortan обернутые в Python) / scikits и т.п. знаем?

> А для быстрых вычислений есть fortran. И для него написано море библиотек.

Так много библитек, что фортранщики дергают GSL через врапперы. И это вместо того, чтобы освоить Си.

>графики получаются красивые искаропке

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

>И это вместо того, чтобы освоить Си.

А зачем, если новый фортран, вроде лучше? https://bitbucket.org/eric_t/modern-fortran/wiki/Home

NumPy может оперировать блоками памяти, как например views в GSL? (http://www.gnu.org/s/gsl/manual/html_node/Matrix-views.html) Если нет, то он по определению не быстрый.

Вы смотрели исходники octave? Там большинство функций написано тупо «в лоб», то есть производительность там зачастую никакая. numpy написана на Си с хорошим уровнем оптимизации, практически не уступает в скорости ядру матлаба для работы с массивами. Линейная алгебра, FFT известно через что реализовано, поэтому эти вещи везде быстрые.

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

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

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

Я про библиотеки. А для расчётов всегда и фортрана 90/95 хватало. Не понимаю всех этих веяний у нового фортрана.

> не все из этого свободно распространяется и вообще распространяется

Сами ответили на свой вопрос. А с GSL я могу работать где угодно и как угодно. Никаких лицензий под использование на кластерах.

Ну и чудесно. Но в GSL лишь общие математические вещи.

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

>хитрый интересный анализ сделать за несколько минут,

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

и, кстати, в последний раз когда сравнивали, origin неправильно считал fft.

> Матлаб очень дорого стоит, хотя по качеству, удобству и напичканности это одно из лучших ПО для инженеров и учёных.

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

Напичканность - вот за что Mathworks получает свои серебрянники...

Найдите свободные библиотеки с ODE решателями, распределениями вероятностей. Да, можно и netlib многое найти, но всё это не то. Если GSL мало, то есть тот же clapack.

Если знаешь, что её нет, не вижу в этом проблемы. Более того, если это действительно функция уникальная, не стоит больше усилий написать её на встроенном интерпретаторе Си, а для любителей извращений воспользоваться бриджем данных Origin <-> любимый Matlab.

И, таки, он не считает FTT, его считает FTTW, а вот нормализации используются разные, а поэтому надо хорошо понимать, что означают заданные параметры.

Вообще хорошо понимать в принципе всегда полезно, не только в контексте Origin.

> специально спроектированный, чтобы максимизировать стоимость ошибок, их частоту и невозможность нормального статического анализа

Таки ви хотите сказать, что научные публикации, выполненные на Matlab, нужно выбрасывать в мусорку?

> невозможность нормального статического анализа

Это в любых языках с динамической типизацией.

Мне не нравится, что в языке матлаба всё сделано через копирование, это реальный минус (handle для ООП не рассматриваю). Но язык сам по себе удобный для своих задач, ООП реализовано удобнее чем в питоне. Куча тулбоксов, Simulink...

IDE в матлабе удобная. Всё есть «из коробки», даже неплохой профайлер. Редактор, конечно, отстой, автокомплита можно сказать нет и т.п., но общее впечатление от среды положительное. Я с матлабом знаком больше 5 лет, то есть опыта достаточно много.

Я скорее о том, какой ценой они даются.

> Это в любых языках с динамической типизацией.

А в Python 3, например, можно делать хинты. Только не надо говорить про использование Java из Matlab.

ООП реализовано удобнее чем в питоне.

Вот это для меня --- новое слово в языкостроении. Можно развернуть?

IDE в матлабе удобная.

Совершенно отвратная IDE, особенно если учитывая стоимость PyCharm в районе $30. Рефакторингов нет, автокомплит уровня недавно анонсированного на ЛОРе mcedit, отстойный инспектор, кривая навигация (вернее её нет).

От блокнота отличается только наличием тоскливой подсветки синтаксиса и фолдингом.

Куча тулбоксов, Simulink...

Это как раз напичканность, о которой спору нет.

В матлабе ООП сделано ближе к Java. Есть public, private, static, интерфейсы, «евенты» и т.д. Оно более «вылизано».

То, как ООП сделано в питоне мне не нравится. Из коробки приватных данных нет, интерфейсов нет, «енумов» нет, событий нет. Всё является объектами, функции, даже классы - ну круто конечно, но всё это спроектировано как-то странно.

От блокнота отличается только наличием тоскливой подсветки синтаксиса и фолдингом.

Редактор - отстой, я же не спорю. :)

Сама по себе среда удобно спроектирована с точки зрения юзабилити и инструментария.

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

Вот тут представлено сравнение ООП в матлабе с ООП в других языках http://www.mathworks.com/help/techdoc/matlab_oop/brqzfut-1.html

> Есть public, private, static

В Python есть приватные переменные by convention (знак подчеркивания), геттеры, сеттеры, фильтры и чего только нет... В чем ценность именно Java-like способа реализации этих парадигм в *динамическом* языке от меня ускользает.

интерфейсы

Пишите абстрактные классы, язык динамический, чем они не интерфейсы?

«евенты»

...есть в библиотеках, фактически настолько же стандартных как и NumPy, SciPy & matplotlib.

«енумов» нет

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

class Animal: DOG=1 CAT=2

x = Animal.DOG

всё это спроектировано как-то странно

Это относительное утверждение; после прочтения SICP странными будут казаться совсем другие дизайны.

Сама по себе среда удобно спроектирована с точки зрения юзабилити и инструментария.

Я тут детектирую взаимоисключающие параграфы.

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

Получается таки одни библиотеки?

но я не считаю язык матлаба полным отстоем.

Я не вижу в свете выше озвученного, что его отделяет от этого титула, но на продолжении дискуссии не настаиваю.

by convention - это всё же by convention. Реально данные, которые хочется скрыть не скрыть. Не хочется видеть всякий «мусор» в публичных API. Я опять же не спорю, это дело вкуса и в общем то не смертельно. Просто хотелось бы, чтобы было.

По поводу остальных утверждений спорить тоже не буду, единственное, скажу, что «не нужно» - это слишком сильно сказано. Есть PEP'ы в которых разбираются и енумы (http://www.python.org/dev/peps/pep-0354/) и интерфейсы (http://www.python.org/dev/peps/pep-0245/) в питоне, всё это просто не реализовано в стандартной поставке.

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

По поводу среды. Я скажу так. Я бы сравнивал среду матлаба с продуктами 37Signals. Функций по-минимуму, вроде ничего такого, но пользоваться удобно и всё что нужно для задач, решаемых в матлабе, есть, не хватает только более функционального редактора. Для всего остального есть Питон, современные IDE и т.п. :)

Найдите свободные библиотеки с ODE решателями, распределениями вероятностей. Да, можно и netlib многое найти, но всё это не то. Если GSL мало, то есть тот же clapack.

На фортране писал 7 лет. Мне нравились многие функции типа matmul из коробки, как и работа с сечениями массивов. Ушёл на Питон, т.к. в numpy всё это реализовано не хуже, а кроме того общих возможностей больше (мне, скажем, часто приходится парсить текстовые файлы, в Фортране и С это просто ад). И да, в scipy есть решатель (обёртка к фортрановским либам), в numpy --- куча разных распределений. Чем вам фортрановские либы для решения ОДУ не понравились --- право не знаю.

А для расчётов всегда и фортрана 90/95 хватало. Не понимаю всех этих веяний у нового фортрана.

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

как оно, вообще, в сравнении с gnuplot? (вопрос к тем, кто пользуется)

Если пользуетесь как исключительно графопостроителем, то есть и преимущества и недостатки. Если же обрабатываете данные, то однозначно лучше тем, что имеете все возможности numpy. 3D в matplotlib пока слабоват.

> Реально данные, которые хочется скрыть не скрыть.

Если действительно есть глубокие и веские причины скрывать данные так, чтобы это было *невозможно* обойти никоим образом, динамический язык --- неправильное решение поставленной задачи; это относится не к Python, а вообще к любому динамическому языку, включая Matlab.

Если таких причин нет кроме бессознательного желания «как в Java», то средств Python вполне достаточно.

Есть PEP'ы в которых разбираются

Неплохо было бы почитать обсуждения по каким именно причинам они были rejected (hint: потому, что в таком виде эти патерны в динамическом языке не нужны).

Язык матлаба неплохо продуман и хорошо справляется со своими задачами.

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

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

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

нужно для задач, уже решенных в матлабовской библиотекой

fixed

вот с матлабом почти не работал (и графики там не рисовал), но возможно, похожесть будет плюсом =) учитывая большую распространённость оного.

Я так понимаю, самый мощный графопостроитель из существующих - mathgl. И биндинги для питона, кстати, для него тоже есть. Но вот только 2.7, для 3-й ветки почему-то нет до сих пор :( В этом плане у matplotlib преимущество...

> Чем вам фортрановские либы для решения ОДУ не понравились --- право не знаю.

Централизованные либы с решателями ОДУ есть у NAG и Intel, не устраивает их платность. Например, как их использовать на кластере? Варианта той же IMSL, про которую так распевал уважаемый товарищ Бартеньев в «Фортран для профессионалов. Математическая библиотека IMSL», под Linux нет. Искать на netlib либы на каждый чих, идущих с куцым readme вместо документации, не имею ни малейшего желания. Какие ещё либы вы имеете в виду?

>он разрабатывался людьми не имеющими никакого отношения к разработке языков программирования

Можно подумать, все языки разрабатывались «профессиональными разработчиками языков программирования». Ларри Уолл - создатель перл по образованию лингвист, Гвидо ван Россум тоже по образованию математик. Язык Си был создан под задачу. Языки программирования разрабатывают люди, которые имеют отношение к программированию и которым чего-то не хватает, у кого-то это получается лучше, у кого-то хуже. :)

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

> Ларри Уолл - создатель перл по образованию лингвист,

Результат, собственно, совершенно закономерный =)

Гвидо ван Россум тоже по образованию математик.

Это так, да не так. Он имел довольно прямое отношение к разработке ЯП и Python не первый его опыт.

Язык Си был создан под задачу.

Язык C был создан Денисом Ритчи (R.I.P), и назван третьей буквой латинского алфавита не случайно. Денис имел непосредственное отношение к разработке ЯП и большой стаж, что, собственно, и определило наследство C, несмотря на все его недостатки.

Языки программирования разрабатывают люди, которые имеют отношение к программированию и которым чего-то не хватает, у кого-то это получается лучше, у кого-то хуже. :)

Вот с этим согласен на 100% (и всё равно, тем у кого хуже, шаловливые рученки таки хочется порой укоротить).

>Большой — это какой? ss@hyperblade-master:/share/home/ss/Nano3D> ls -l *.plt -rw-r--r-- 1 ss users 654581299 2011-10-20 22:40 Nano3D-90.plt

Закопает любой постпроцессор на педоне

(8,5млн FE внутрях)

я бы строил в mayavi

Там рисование идёт через VTK но на больших объёмах данных не спасает даже это

объясни, что такое этот *.plt?

Закопает любой постпроцессор на педоне

чего куда закопает?

И потом, «there is no silver bullet», конечно.

>объясни, что такое этот *.plt?

файл с данными в формате постпроцессора который умеет 8.5 млн FE :)

чего куда закопает?

процесс визуализации

Постпроцессор на петоне (например Salome) с рисованием через VTK просто тупо умирает если я выведу просто сетку для вышеприведённого файла :)

Про какую либо обработку данных речи уже не идёт

И потом, «there is no silver bullet», конечно.

Чего только не придумают чтобы объяснить почему не могут выкопать котловам своим любимым децким совочком :)

Наверное котлован не той системы :))

> Наверное котлован не той системы :))

Наверное тем, чем копают котлован не очень удобно есть мороженное =)

>Наверное тем, чем копают котлован не очень удобно есть мороженное =)

Тут как раз не тот случай :) Я же не предлагаю строить простенькие плоские графики с помощью pV3 :)

Секрет прост, просто петон очень нравица конструкторам совочков :)

Origin конечно хорошо, но теперь не знаю на что его заменить в своей лаборатории. :(

> А питон уже научился быстро работать?

Для программ, которые один раз пишутся и один раз исполняются - не критично. Даже так: написание их, скажем, на си заняло бы столько времени, сколько написание и исполнение/отладку на питоне.

> Как там с трёхмерными графиками и большими массивами данных? Недотягивает?

С трехмерными графиками - все хорошо. А коль нужны большие массивы данных, то си с фортраном в руки и марш на кластерник, и питону там делать нечего.

> Origin конечно хорошо

qtiplot?

Ну и что? И вышла библиотека. Да их таждый день пачками выходит! Это что новость для главной?

Я, если честно, вообще не понял, что ты предлагаешь, или что ты считаешь, что тебе предлагают: matplotlib к постпроцессингу ~10^7 FE никоим образом не применим и проектировался для других задач (а именно --- простая графическая библиотека для Python с похожим на Matlab API), а кто пытается применить или втюхать кому-нибудь с такими целями явно ССЗБ.