Вышла библиотека MathGL 2.0

Evgueni еще отличается тем, что в своей книге «Создание иллюстраций в MetaPost» приводит _несоответствующие_ код и результат. Например, как для Рис. 4.2 (стр. 37).

Спасибо за багрепорт. Могли бы и в менее пафосно его предоставить.

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

Посмотрел на рис. 4.2, догадался что огорчило анонима и решил: пусть огорчается дальше, так как для догадливых есть исходники картинок.

Посмотрел на рис. 4.2, догадался что огорчило анонима

Решили ответить в том же тоне? Но если вам все же важен багрепорт, скажу. У пакета graph.mp есть баг/фича, при которой от стрелок за пределами графика рисуются только стрелки-наконечники без соединяющей их линии. Поэтому код

% текст и стрелка за пределами графика
gdrawdblarrow (2,−20)− −(12,−20) withpen pencircle scaled 0.5u;

для догадливых есть исходники картинок.

Причем здесь исходники, если код нерабочий?

Спорить с вами о выборе между Си и Фортран не имеет смысла. Если я в достаточной мере знаком с обеими, то Си для вас - китайская грамота. Чтобы вы опять не свели к недостаткам языков, уточню, что я рассматриваю не язык сам по себе, что является типичным конем в вакууме, а «язык + библиотеки + среда разработки».

Причем здесь исходники, если код нерабочий?

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

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

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

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

А по существу вы что-нибудь имеете сказать?

Какие-нибудь успехи с octave есть?

Примерчик простенький попробовал с MathGL - получилось. Часа 2 искал вменяемые мануалы - ничего не нашел. Пока, до поры до времени, забил на это.

Если вернусь и что-нибудь приличное получится - в ЖЖшке сразу напишу.

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

Текст за шесть лет безусловно устарел во многих местах (MetaPost довольно активно менялся а это время). Я действительно не спешу его исправлять, как и кучу других по банальной причине: на это нужно свободное время.

Кстати, а ебилды уже появились?

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

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

Немного offtop. Скажи, когда «Наглядная статистика. Используем R» появится в реальной продаже? На озоне оно хоть и заявлено по факту у них её нет. В заказе висело с 22го февраля, срок поставки постоянно сдвигали. Пришлось аннулировать заказ.

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

Более того, если память не изменяет, под Windows они тогда использовали lcc, а в последних версиях вроде рекомендуют Visual Studio (Express), в то время как под Linux используется обертка вокруг gcc.

Только это, вы смотрели как оно устроено-то? Объясняю, работает всё это примерно так: матлабовский код преобразовывается по сути в вызовы функций рантайма, часть из которых открыта в MEX API, а потом всё это дело компилируется в бинарник слинкованный с тем самым рантаймом. В итоге, по скорости мы ничего не выигрываем, кроме каких-то миллисекунд, затраченных на генерацию байт-кода.

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

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

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

Интересно повернулась ваша беседа с другим анонимом :-)

Только я так и не понял какие рациональные аргументы за то, чтобы начинать новые проекты на фортране: некроязык с отвратным синтаксисом (впрочем, дитя своей эпохи, без обид), без нормальной поддержки со стороны средств разработки (давайте, расскажите мне про IDE уровня JetBrains для фортрана) и грустной поддержкой компиляторов новых частей стандарта. При этом огромное наследие netlib легко используется из C/C++, да и из интерпретируемых языков через обертки.

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

А симулинк вы тоже на питоне напишете?

Ох, как мы красиво съехали с темы! По матлабу значит вопросов больше нет? Между прочим, на симулинк надо покупать отдельную лицензию (в дополнение к лицензии на матлаб) и нужен он на порядок более узкому кругу специалистов.

И таки да, есть Jmodelica, а для матлабофилов существует xcos (сюрприз!!! написанный специалистами, которые определяют саму предметную область, в отличие от).

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

PS. Сдается мне, что вы даже преобразование Лапласа грамотно написать не сможете на своем питоне.

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

Единственное, что я могу сказать это то, что я свои авторские экземпляры получил. То есть физически книга точно есть.

Только я так и не понял какие рациональные аргументы за то, чтобы начинать новые проекты на фортране

В моей области деятельности смысла особого нет, так как окружение (благодаря CERN) полностью дублировано на C/C++ (PAW/CERNLIB->ROOT), а вот когда вы будете заниматься параллельными расчётами, которые длятся месяцами, то вам определённо захочется ускорить их. Вот тут использование Fortran всё ещё весьма популярно. Там довольно много инструментов ориентированных именно на Fortran.

Только это, вы смотрели как оно устроено-то? Объясняю, работает всё это примерно так: матлабовский код преобразовывается по сути в вызовы функций рантайма, часть из которых открыта в MEX API, а потом всё это дело компилируется в бинарник слинкованный с тем самым рантаймом. В итоге, по скорости мы ничего не выигрываем, кроме каких-то миллисекунд, затраченных на генерацию байт-кода.

«легкие» циклы еще как ускорять компиляция должна (увы не на чем проверить уже :). ну и вложенные вызовы функций.

например в R компиляция иногда, при «императивном» написании кода, ускоряет в десятки раз.

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

«легкие» циклы еще как ускорять компиляция должна (увы не на чем проверить уже :). ну и вложенные вызовы функций.

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

А вообще, если JIT хороший, то он будет быстрее нативного кода, потому, что нативный код не учитывает данные с которыми его запустили и, соответственно, не может каждый раз оптимизировать свои пути исполнения ;-) Другое дело, что оного в матлабе не наблюдается.

например в R компиляция иногда, при «императивном» написании кода, ускоряет в десятки раз.

Весьма логично, если, например, у R медленный интерпретатор (не буду судить, с R знаком шапочно), а при «векторном» программировании циклы крутятся на уровне C.

Ясно, но тогда я не понял в чем вы с тем анонимом несогласны (исключая тот факт, что он был груб).

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

Я именно такими и занимаюсь ;-)

Вот тут использование Fortran всё ещё весьма популярно. Там довольно много инструментов ориентированных именно на Fortran.

Я бы сказал, что, к сожалению, до сих пор компиляторы Фортрана генерят очень конкурентный по скорости ассемблер. Но, с другой стороны, у нас время на разработку дороже времени на кластере, так что я изолирую себя от фортрана используя питоновские обертки. Когда последний раз серьёзно профайлил хотспоты были внутри фортрана, так что такой подход вполне жизнеспособный.

а вот когда вы будете заниматься параллельными расчётами, которые длятся месяцами, то вам определённо захочется ускорить их. Вот тут использование Fortran всё ещё весьма популярно. Там довольно много инструментов ориентированных именно на Fortran.

И опять же, причем здесь Fortran? Да подавляющее большинство таких расчетов используют OpenMP для распараллеливания и расчетные библиотеки проходят именно такое тестирование. А будете вы там использовать Fortran или C/C++ - разницы абсолютно никакой, стандарт OpenMP одинаково хорошо ими поддерживается. Как пример, библиотека Intel MKL, её заявленное распараллеливание в 4 потока реализуeтся именно так. Дальнейшее конструктивное обсуждение я вижу только в предоставлении контр-примеров, а не голословные заявления о какой-то серебряной пуле, о чем постоянно твердят фортранщики. Сколько ж можно, мы же не про Хаскелл говорим, а про обычный императивный язык, да с длиннющим хвостом обратной совместимости еще с перфокарточными ЭВМ.

Запускал только базовый пример , сам хотел статью сделать, но после ЕOS, руки никак не доходят.

Вот обсуждения ,я там код выложил вроде: Вышел Gnuplot 4.6.0

Там не совсем то, интересует как вывести массив данных и не только в файл, но и аналогично гнуплоту.

Это нечто вообще на что рассчитано?

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

А уж графики и до фига чего ещё умели строить либы и утилы аж для Иксов 80-90-х годов.

// Gharik

А вообще, если JIT хороший, то он будет быстрее нативного кода, потому, что нативный код не учитывает данные с которыми его запустили и, соответственно, не может каждый раз оптимизировать свои пути исполнения ;-) Другое дело, что оного в матлабе не наблюдается.

Шеф, imtermediate bytecode процессоры-ускорители прям, я смотрю, как для тебя вовремя придумали, задержались всего на -10 лет.

Несомненно, человечество - говно и заслуживает тотального уничтожения, но до твоих роботов - как Азимову до эльфов.

Только я так и не понял какие рациональные аргументы за то, чтобы начинать новые проекты на фортране: некроязык с отвратным синтаксисом (впрочем, дитя своей эпохи, без обид)

вы не умеете этих кошек готовить

, без нормальной поддержки со стороны средств разработки (давайте, расскажите мне про IDE уровня JetBrains для фортрана)

да легко http://www.eclipse.org/photran/

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

вполне неплохо http://gcc.gnu.org/wiki/Fortran2008Status intel, absoft и portland тоже уже подтягиваются

При этом огромное наследие netlib легко используется из C/C++, да и из интерпретируемых языков через обертки.

да вызывайте хоть с брейнфака, дело в том что цели при создании языков преследовались разные c/cpp/java etc - для системного программирования fortran - это математика, однозначность и ясность языка и скорость

Я например использую фортран совсем не из-за наследия. За последние 15 лет довольно плотного использования фортрана (плазма, полупроводники, и теоретическая АМО физика) я использовал с netlib наверное только lapack да несколько спецфункций. Почему? Все основные элементы содержатся в очень простой форме _уже_ в языке а не в библиотеках и это дает возможность быстро читать и писать надежный код. Не надо создавать и просматривать структуру классов, и не надо переживать как все это будет компилироваться следующим поколением компиляторов. Модули позволяют очень удобную организацию кода (и никаких хидеров сер!) Да только всевозможные включая экзотические операции с массивами и их сечениями из коробки уже выносят фортран далеко вперед. А допиливание coarrays вынесет его еще дальше. И при всех изменениях стандартов (последний здесь ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1830.pdf) язык остался таким же простым и понятным. После первой же лекции comp physics через пол часа нулевые студенты уже писали у меня структурированые программы с модулями, функциями, а крутых спецов сишников (я не фашист, на выбор даю си или фортран) пришлось учить хотя бы не терять точность в мат формулах.

вполне неплохо http://gcc.gnu.org/wiki/Fortran2008Status intel, absoft и portland тоже уже подтягиваются

Но только ни один из них полностью не поддерживает даже Fortran2003.

я использовал с netlib наверное только lapack да несколько спецфункций. Почему? Все основные элементы содержатся в очень простой форме _уже_ в языке

Если вам нужны только матрицы, не нужны спецфункции, ОДУ решатели, то пожалуйста. Ну уж вычислять матрицы можно на любом языке. Ну и что, что нет в языке? Зато все есть в LAPACK, clapack, lapack++. Мне, может, спецфункции важнее, а в Фортране их нет. Там и числа пи даже нет, функции косинуса и синуса подключаются как внешние. Да фигня это, а не язык, любая обширная мат. библиотека и то лучше.

Да только всевозможные включая экзотические операции с массивами и их сечениями

Полноте, барин, какие еще экзотические? Уже лет двадцать всем известные.

А допиливание coarrays вынесет его еще дальше

Так ведь нет же еще.

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

вы не умеете этих кошек готовить

Дело вкуса, конечно, но таки в 2012 году хочется красивого синтаксиса.

да легко http://www.eclipse.org/photran/

Ладно, не IDEA, конечно, но для сельской местности сойдет. Признаю, что слил по этому пункту.

вполне неплохо http://gcc.gnu.org/wiki/Fortran2008Status intel, absoft и portland тоже уже подтягиваются

Красные пункты No везде там, как и на странице по 2003-му стандарту, а PGI и прочие так вообще к 2020 году подтянутся... Это ли не грустно? Если нет, то что грустно?

fortran - это математика, однозначность и ясность языка и скорость

Ну конечно... Хаскель это математика, чего это там такого математического в фортране?

Про ясность я сказал, читать противно, но дело вкуса, конечно, а насчет однозначности, так и Си будет однозначным, если undefined behaviors не использовать.

Модули позволяют очень удобную организацию кода (и никаких хидеров сер!)

Нет хедеров? Вот это достоинство! Офигеть! А как нормальные интерфейсы публичных API определять? Правильно, к 2003-ей версии стандарта кое как вкостылили их аналог назад.

Да только всевозможные включая экзотические операции с массивами и их сечениями из коробки уже выносят фортран далеко вперед.

Это какие такие экзотические операции, слайсинг что-ли? Сейчас проще назвать язык, в котором их нет.

(я не фашист, на выбор даю си или фортран)

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

крутых спецов сишников пришлось учить хотя бы не терять точность в мат формулах

Чего-то я не понял, а на фортране что, итеративные разности близких значений с плавающей точкой и т.п. к потере точности в формулах не приводят?

Шеф, imtermediate bytecode процессоры-ускорители прям, я смотрю, как для тебя вовремя придумали, задержались всего на -10 лет.

Привет, специалист по эльфам! И сколько iMtermediate bytecode процессоров-ускорителей я получаю на килограмм матлаба?

Чего-то я не понял, а на фортране что, итеративные разности близких значений с плавающей точкой и т.п. к потере точности в формулах не приводят?

Типичные ошибки юных сишных студентов это даже не округление а ошибочная работа с целыми числами в мат выражениях вместо чисел с плав точкой и непонимание сколько значащих цифр надо показать в output (сомневающиеся выводят то 15 то 17 значащих а остальные кажись машинально %f\n), фортранисты же более осторожные и пишут сразу 1.0_dp/288.0_dp или хотя бы 1.0d0/288.0d0

О библиотеке MathGL, когда то пробовал, все довольно прилично, спасибо Алексею за труды. Хотя мне все еще проще написать скрипт к gnuplot или gle а потом его запустить в нужное время в нужном месте, в хозяйстве она пригодится наверняка.

Пока дошел вот до чего:

function plot_MGL1D(X, Y, m, Text, name)
% рисуем график при помощи mathGL, если name != null - сохраняем
% X, Y - массивы координат точек графика
% m - структура mathgl, переданная пользователем (без нее не работает)
% Text - необязательное поле - структура вида
%		Text.Title  - заголовок графика
%		Text.xLabel - подпись оси X
%		Text.yLabel - подпись оси Y
%		... что-нибудь еще можно будет воткнуть
	if(size(X) != size(Y) || size(X,1) != 1 || size(Y,1) != 1)
		printf("Error! X and Y have different or bad sizes!\n");
		return;
	endif
	L = size(X, 2);
	g = m.mglGraph();
	x = m.mglData(L);
	y = m.mglData(L);
	for i = 1:L
		x.SetVal(X(i), i);
		y.SetVal(Y(i), i);
	endfor
	Title = "Sample plot";
	yLabel = "axis Y"; xLabel = "axis X";
	if(nargin > 3)
		if(isfield(Text, 'Title'))  Title  = Text.Title;  endif
		if(isfield(Text, 'xLabel')) xLabel = Text.xLabel; endif
		if(isfield(Text, 'yLabel')) yLabel = Text.yLabel; endif
	endif
	g.Title(Title);
	g.Label('y', yLabel, 0);
	g.Label('x', xLabel, 0);
	Xr = m.mglPoint(); Yr = m.mglPoint();
	m.mglPoint_x_set(Xr, min(X)); m.mglPoint_y_set(Xr, min(Y));
	m.mglPoint_x_set(Yr, max(X)); m.mglPoint_y_set(Yr, max(Y));
	g.SetRanges(Xr, Yr);
	g.Axis();
	g.Box();
	g.Plot(y);
	g.ShowImage('feh');
	if(nargin == 5)
		g.WritePNG(name);
	endif
endfunction

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

И в Fortran и в Си типизация нестрогая, поэтому и там и там результат вычисления 1/2 может получиться как 0.

Уфф, сколько всего здесь написали.

Действительно поэлементно присваивать можно, а с присваиванием матриц что-то сломалось.

Для графика {x,y} достаточно указать оба массива:

g.Plot(x,y);

«Косячит» он в этом случае. Вот что получилось при попытке нарисовать график командой

plot_MGL1D([-1 1 1.5 2 10 11 13 13.3],[1 2 3 4 5 6 7 8],mathgl, 1, "/tmp/plot.png")

А еще mathgl хорошо сегфолтит октаву. Вот это

plot_MGL1D([1 1.5 2 10 11 13],sin([1 1.5 2 10 11 13]),mathgl)

*** glibc detected *** octave: free(): invalid next size (fast): 0x00000000019560b0 ***

А udav будет и дальше выходить в одном архиве с mathgl, или отдельно?

«Косячит» он в этом случае. Вот что получилось при попытке нарисовать график командой

Не косячит — индексы в MathGL с 0 начинаются, а присвоение идёт с 1 ... вот первая точка и не определена. И вылет скорее всего с этим же связан (для скорости не было проверки на границы массива — сейчас включу и пошлю в SVN).

Да, вместе. Уж больно они близки.

А и правда. Заменяем строки 19 и 20 на

		x.SetVal(X(i), i-1);
		y.SetVal(Y(i), i-1);

А можно все-таки сделать поведение mathgl в октаве более близким к самой октаве? Т.е. чтобы индексы с 1 начинались; чтобы не нужны были все эти типы mglGraph, mglData, mglPoint; чтобы не нужно было в функцию, использующую mathgl, передавать явно объект mathgl; чтобы для печати достаточно было сказать mglPlot(x, y) (где x и y - массивы октавы, а не какие-то непонятные типы данных)???

И документации по использовании mathgl в октаве нет вообще. А функции там отличаются от обычных mathgl'ных.

P.S. Вышеупомянутый сегфолт именно из-за индексов и происходил.

А можно все-таки сделать поведение mathgl в октаве более близким к самой октаве? Т.е. чтобы индексы с 1 начинались;

В принципе можно, только это в настолько многих местах используется, что сразу и не возьмусь всё поправить.

чтобы не нужны были все эти типы mglGraph, mglData, mglPoint;

Ммм, а как иначе хранить настройки графика и всю информацию о массивах? Насчёт mglPoint — можно убрать, но часто группы из 3-х чисел удобнее передавать структурой.

чтобы не нужно было в функцию, использующую mathgl, передавать явно объект mathgl;

??? Вот это меня тоже удивило. В питоне достаточно выполнить «from mathgl import *» и все функции/структуры mathgl загружаются в общую область.

чтобы для печати достаточно было сказать mglPlot(x, y) (где x и y - массивы октавы, а не какие-то непонятные типы данных)???

С типами данных как всегда проблема — они слишком разные, даже в рамках одного языка программирования (это причина большого числа mglData::Set() в С++). Скорее для этого надо бы написать набор скриптов в самой Octave (наподобие приведённого выше).

Заодно и мне будет интересно какие варианты вызова наиболее востребованы :).

Тут есть ещё один момент — в существующем варианте легко рисовать в несколько разных графиков/окон одновременно. Если же сделать глобальную переменную типа mglGraph, то такая возможность пропадет.

Кстати, а вот этот вариант http://mathgl.sourceforge.net/doc_en/mathgl_en_12.html#Animation с окошками работает?