Вышла библиотека MathGL v 1.5 и программа UDAV v 0.3

отлично! Как допилю неявно заданые функции, надо будет на опенгл рисование перевести, бо намного шустрее.

Вопрос к автору: А можно было в файлике INSTALL написать не ./configure, make, make install а то, от чего ваша библиотека зависит?
И на тему --enable-* Нужно ли их указывать явно, или по дефолту тоже соберётся со всем и вся?

Зависимости вроде и так прописаны везде (в README, на сайте, в документации и пр.): GLUT + не обязательные, но рекомедуемые PNG, GSL, JPEG и TIFF (в порядке убывания приоритета). В будущем жесткую привязку к GLUT уберу.

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

> отлично! Как допилю неявно заданые функции, надо будет на опенгл рисование перевести, бо намного шустрее.

Не уверен. Кроме того, с прозрачностью нескольких перекрывающихся поверхностей у OpenGL БОЛЬШИЕ проблемы.

>Не уверен. Кроме того, с прозрачностью нескольких перекрывающихся поверхностей у OpenGL БОЛЬШИЕ проблемы.

у меня mglGraphGLUT при ресайзе вообще не тормозит, а mglGraphZB заметно лагает при перерисовке :(

>Зависимости вроде и так прописаны везде (в README, на сайте, в документации и пр.): GLUT + не обязательные, но рекомедуемые PNG, GSL, JPEG и TIFF (в порядке убывания приоритета). В будущем жесткую привязку к GLUT уберу.

Сорри конечно, прогу пока не видел. На скриншотах по-моему это Qt? Где это отражено в control файле? В любом случае прога дилжна что-то использовать хотябы xlib или GTK. Тоесть если у меня qt не установлена dpkg даже мне ничего не сообщит?

Source: udav
Section: math
Priority: extra
Maintainer: Dmitry I. Kulagin <dik@kulagin.nnov.ru>
Build-Depends: cdbs, debhelper (>= 5), autotools-dev, libmgl-dev, libgsl0-dev, freeglut3-dev, libgl-dev, libpng-dev
Standards-Version: 3.7.2

Package: udav
Architecture: any
Section: math
Priority: extra
Depends: ${shlibs:Depends}
Suggests: mathgl-doc, mathgl-doc-ru
Description: UDAV is a visualization of MathGL scripting
 MathGL is a free library of fast C++ routines for the plotting
 of the data varied in one or more dimensions. It uses OpenGL
 (www.opengl.org) for the plotting. Also there is a simple window
 interface based on GLUT. This provides high compatibility with
 any operating system (really any which has OpenGL-like libraries).
 .
 UDAV is graphical interface for MathGL scripting

> Сорри конечно, прогу пока не видел. На скриншотах по-моему это Qt? Где это отражено в control файле? В любом случае прога дилжна что-то использовать хотябы xlib или GTK. Тоесть если у меня qt не установлена dpkg даже мне ничего не сообщит?

Нет. Использована библиотека FLTK, никакого отношения к Qt и GTK она не имеет. Хотя согласен, что зависимости надо прописать аккуратнее.

> у меня mglGraphGLUT при ресайзе вообще не тормозит, а mglGraphZB заметно лагает при перерисовке :(

А если попробовать выключить флаг DrawFace ?

> у меня mglGraphGLUT при ресайзе вообще не тормозит, а mglGraphZB заметно лагает при перерисовке :(

А если попробовать выключить флаг DrawFace ?

Чего-то у меня не собирается:

g++ -march=i686 -mtune=i686 -O2 -o udav udav-data.o udav-editor.o udav-main.o udav-mathgl.o udav-option.o udav-setup.o udav-table.o  /usr/lib/libmgl.so -lfltk -lfltk_images
udav-main.o: In function `main':
main.cpp:(.text+0x3e6): undefined reference to `argument_set(int, char const*)'
udav-main.o:(.data+0x450): undefined reference to `sshow_cb(Fl_Widget*, void*)'
udav-main.o:(.data+0x46c): undefined reference to `snext_cb(Fl_Widget*, void*)'
udav-main.o:(.data+0x488): undefined reference to `sprev_cb(Fl_Widget*, void*)'
udav-main.o:(.data+0x4a4): undefined reference to `animate_cb(Fl_Widget*, void*)'
udav-main.o:(.data+0x5bc): undefined reference to `argument_cb(Fl_Widget*, void*)'

>А если попробовать выключить флаг DrawFace ?

Попробую, хотя это по-идее должно ускорить отрисовку полигональных поверхностей, а у меня одни кривые

Она умеет рисовать по готовому массиву, а не по выражению?

Кстати, по поводу OpenGL. Правда ли, что прогамма, делающие вывод графики через OpenGL работает медленнее, чем аналогичная, делающая вывод через DirectX? То есть на платформе Windows OpenGL тормознутее DirectX?

>То есть на платформе Windows OpenGL тормознутее DirectX?

Часто. Потому что производитель видеокарточки хорошо если не плюёт на OpenGL, основные силы затрачивая DirectX. По крайней мере, так было пару лет назад, как сейчас - не знаю.

> Она умеет рисовать по готовому массиву, а не по выражению?

Массив можно заполнить значениями выражения (строковой формулой, без перекомпиляции) и нарисовать.

> Попробую, хотя это по-идее должно ускорить отрисовку полигональных поверхностей, а у меня одни кривые

Попутно он включает упрощенное рисование линий (без сглаживания, аля OpenGL). Можете посмотреть UDAV -- скорость вращения мышкой.

Придумали же имечко. Нечно среднее между udaff и udev. :)

>>То есть на платформе Windows OpenGL тормознутее DirectX?

>Часто. Потому что производитель видеокарточки хорошо если не плюёт на OpenGL, основные силы затрачивая DirectX. По крайней мере, так было пару лет назад, как сейчас - не знаю.

Сдаётся мне это всё про гамез. А если вы пишите своё 3д-приложение, то самое страшное, чего можно ожидать - пара процентов пройгрыша opengl.

а как бы сделать ebuild этой программы?

А если есть набор точек (х;y), отражающих экспериментальную зависимость (например интенсивность от магнитного поля) и находящихся в файле построчно через пробел, то я так понимаю для того чтобы построить зависимость необходимо:

1. Добавить в качестве 3 кординаты например 0 для всех точек

2. Выполнить mgl.Data a("filemane.dat"),

3. Построить gr->Dots(a,"p");

Правильно я понимаю?

> А если есть набор точек (х;y), отражающих ...

Можно проще, ничего не добавляя. mglData a("filename.dat"); // читаем данные a.Transpose(); // меняем размерности местами (графики строятся вдоль 1-ой) gr->Plot2(a); // или любую другую функцию одномерных графиков

Можно и так: mglData a("filename.dat"); mglData x(a.SubData(0,-1)), mglData(a.SubData(1,-1)); gr->Plot(x,y); // или любую другую функцию одномерных графиков

А на скрипте MGL можно еще проще: read a 'filename.dat' plot a(0) a(1) # или любую другую команду одномерных графиков

Точно также можно добавить размер ошибки, изменить цвет, тип маркеров, пунктир и пр.

Пардон, забыл отформатировать текст. Должно быть так:

> А если есть набор точек (х;y), отражающих ...

Можно проще, ничего не добавляя.

mglData a("filename.dat"); // читаем данные

a.Transpose(); // меняем размерности местами (графики строятся вдоль 1-ой)

gr->Plot2(a); // или любую другую функцию одномерных графиков

Можно и так:

mglData a("filename.dat");

mglData x(a.SubData(0,-1)), mglData(a.SubData(1,-1));

gr->Plot(x,y); // или любую другую функцию одномерных графиков

А на скрипте MGL можно еще проще:

read a 'filename.dat'

plot a(0) a(1) # или любую другую команду одномерных графиков

Точно также можно добавить размер ошибки, изменить цвет, тип маркеров, пунктир и пр.

Смотрел я внимательно на эту библиотеку в прошлой версии. Программный интерфейс просто ужасен.

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

Имхо программировать на С++ автор не умеет.

Единственный плюс: графики рисует красиво, но подписи ужасны и текст вообще. Причем если его нарисовать крупно, то заметно, что рисуется лишь контур символов. В 3D графиках оси вдоль которых будут рисоваться координаты автоматически не выбираются (чаще всего выбирают передние оси автоматически). При указании в ручную получаем оси в середине графика (нет ну можно конечно сделать так, чтобы они совпали с краями графика, но почему надо делать это в ручную?). В 2D графиках буквы по непонятным причинам поворачиваются по направлению осей, когда как принято что они располагаются удобным для читателя образом (если явно не указано обратное). В общем, сильно сырой проект с кучей недостатков. А жаль.

Как в ней вообще работать: ищется библиотека libmgl.so.1, такой нет в интернете, а mathGL такой не предоставляет, единственное, что нашел libmgl.so.5, но это же не то

UDAV, python... это серпентарий или нашествие падонкафф?

> Смотрел я внимательно на эту библиотеку в прошлой версии. Программный интерфейс просто ужасен.

Подробнее

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

Пустые функции только для рисования примитивов -- линий, точек, треугольников и четырехугольников. Кроме того, поворот осей координат и сохранения в файл. Все остальное определено в базовом классе. Естественно, что реализация рисования примитивов разная для разных целей -- вот наследники этим и занимаются: OpenGL -- mglGraphGL, растровая картинка -- mglGraphZB, векторная картинка -- mglGraphPS.

Правильная программа ошибок не имеет и обрабатывать ей их не зачем. Ошибки в студию! :) Замечу, что значения NAN - не ошибки. Это способ сказать программе, что эту точку рисовать не надо.

> Имхо программировать на С++ автор не умеет.

И как бы должна выглядеть библиотека по Вашему? Отдельный класс для каждого типа графика? и попробуйте ей тогда пользоваться (реально) :). А кроме того, напишите интерфейс для других языков (C или Fortran).

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

Векторные шрифты все такие -- цена переносимости и быстродействия. Мне уже предложили сделать шрифты с заполнением. Возможно к 1.6 они появятся. Пока можно увеличить толщину линий для большого размера шрифта.

> В 3D графиках оси вдоль которых будут рисоваться координаты автоматически не выбираются (чаще всего выбирают передние оси автоматически).

Не понял. Имеется ввиду автоматический вызов Axis()? А если я не хочу рисовать оси? Уже нарисованное убрать нельзя (только стереть весь рисунок целиком).

Или имеется в виду определение масштабов осей. Последнее заранее определить невозможно, да и вредно. Для ручного определения есть специальные функции XRange, YRange, ZRange, CRange.

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

Вообще-то нас учили, что оси должны быть посередине графика. Если хочется сместить их в угол определите переменную gr->Org = mglPoint(xmin,ymin,zmin).

> В 2D графиках буквы по непонятным причинам поворачиваются по направлению осей, когда как принято что они располагаются удобным для читателя образом (если явно не указано обратное).

Что мешает установить gr->RotatedText = false; Тем более, что поворот подписей вдоль осей считается хорошим тоном при рисовании графика.

> В общем, сильно сырой проект с кучей недостатков. А жаль.

Все вышеуказанное (может кроме векторных шрифтов) недостатками не считаю -- работает как задумано. Еще аргументы о "сыром проекте" есть?

Вообще-то странно. У меня компиляция из исходников обоих пакетов прошла на ура. Проверю.

С трассировкой лучей должно быть красивее, тем более что не в реальном времени.

> С трассировкой лучей должно быть красивее, тем более что не в реальном времени.

Это для рисования теней?

Так кто-нибудь знает, где взять libmgl.so.1

Вопрос о трассировке лучей затрагивает более общую проблему -

зачем вообще ученому в этом десятилетии напрямую общаться с OpenGL?

Не лучше ли на выходе иметь файлы (данных или скриптов) для 3D рисовалок (VRML) или трассировщиков (POV)? И пусть каждый занимается своим делом!

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

Или всё ещё далеко не шоколадно и часто приходится ходить "в рукопашную"?

> Так кто-нибудь знает, где взять libmgl.so.1

Скомпилировать MathGL v.1.5

>Так кто-нибудь знает, где взять libmgl.so.1

Нигде, mathgl 1.5 предоставляет libmgl.so.3

Если у вас возникает такая ошибка, значит, вы запускаете старую версию udav или он у вас собирается со старой версией mathgl Проверьте /usr/{bin,lib} и /usr/local/{bin,lib} на наличие старых версий.

> Вопрос о трассировке лучей затрагивает более общую проблему - зачем вообще ученому в этом десятилетии напрямую общаться с OpenGL?

А никто и не предлагает. Как раз MathGL -- прослойка между данными и устройством вывода (файлом или OpenGL).

> Не лучше ли на выходе иметь файлы (данных или скриптов) для 3D рисовалок (VRML) или трассировщиков (POV)? И пусть каждый занимается своим делом!

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

> В своё время, разумеется, и PostScript из программ на Fortran напрямую создавали - но ведь с ростом мощи машин и развитием ПО затраты времени на такую низкоуровневую возню перестают быть оправданы.

Так MathGL и делает эту низкоуровневую возню. А вот затраты для серьезных рисунков все еще оправданы -- если в массиве несколько сотен точек по каждой из координат (всего несколько миллионов или десятков миллионов) и их хочется "повертеть", да еще и добавить освещение, да еще и несколько полупрозрачных массивов сразу посмотреть ... Вот тут и начинается самое интересное :). По крайней мере Matlab у меня не справлялся в свое время :(.

> Или всё ещё далеко не шоколадно и часто приходится ходить "в рукопашную"?

Ну зачем же. Есть разные программы (и библиотеки: gnuplot, VTK, scilab, octave, labplot, graphplot и пр., еще есть куча платных) построения данных. MathGL одна из них и на мой взгляд очень неплохая :) да еще и бесплатная.

>Векторные шрифты все такие -- цена переносимости и быстродействия. Мне уже предложили сделать шрифты с заполнением. Возможно к 1.6 они появятся. Пока можно увеличить толщину линий для большого размера шрифта.

Кстати, как насчет прикрутить freetype для отрисовки шрифтов? Я в свое время прикручивал его к irrlicht, можно попробовать и в mathgl

> Кстати, как насчет прикрутить freetype для отрисовки шрифтов? Я в свое время прикручивал его к irrlicht, можно попробовать и в mathgl

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

libmgl.so.1 собирается с mathgl 1.5 в /usr/local/lib, однако система ее упорно не видит

Подскажите пожалуйста (я только начинаю программировать). Пример использования GLUT:

int sample(mglGraph *gr, const void *)

{

gr->Rotate(60,40);

gr->Box();

return 0;

}

//----------------------------------------------------- int main(int argc,char **argv)

{

mglGraphGLUT gr;

gr.Window(argc,argv,sample,"MathGL examples",NULL);

return 0;

}

Я хочу нарисовать с помощью sample() что-то (понятно как), затем хочу добавить в то же окно GLUT новый рисунок (допустим пришли новые данные). Как мне это сделать? Как вызвать перерисовку окна с добавлением новых данных?

>libmgl.so.1 собирается с mathgl 1.5 в /usr/local/lib, однако система ее упорно не видит

Проверьте наличие директории /usr/local/lib в /etc/ld.so.conf или в одном из файлов в директории /etc/ld.so.conf.d, если ее нигде нет, то добавте. Затем от root запустите: ldconfig

> Я хочу нарисовать с помощью sample() что-то (понятно как), затем хочу добавить в то же окно GLUT новый рисунок (допустим пришли новые данные). Как мне это сделать? Как вызвать перерисовку окна с добавлением новых данных?

Заменить данные (для функции рисования) и вызвать glutPostRedisplay(); По-моему должно работать. Нажатие любой клавиши (например, пробела) приведет к перерисовке.

> Пустые функции только для рисования примитивов -- линий, точек, треугольников и четырехугольников. Кроме того, поворот осей координат и сохранения в файл. Все остальное определено в базовом классе. Естественно, что реализация рисования примитивов разная для разных целей -- вот наследники этим и занимаются: OpenGL -- mglGraphGL, растровая картинка -- mglGraphZB, векторная картинка -- mglGraphPS.

В базовом классе, я заметил функции writejpeg, writeps и т. п. Только те из них, что не поддерживались классом просто не производили никаких заметных действий. Что очень сбивало с толку. Такого быть в С++ не должно. Наследование создано не для таких фокусов

> И как бы должна выглядеть библиотека по Вашему? Отдельный класс для каждого типа графика? и попробуйте ей тогда пользоваться (реально) :). А кроме того, напишите интерфейс для других языков (C или Fortran).

Нет. Всего лишь четче разобрать кто-что умеет делать и привести интерфейсы классов в соответствие с этим.

> Правильная программа ошибок не имеет и обрабатывать ей их не зачем. Ошибки в студию! :) Замечу, что значения NAN - не ошибки. Это способ сказать программе, что эту точку рисовать не надо.

Допустим моя программа запрашивает некоторое выражение у пользователя, а затем в соответствии с ним заполняет массив для отрисовки (или модифицирует). Если пользователь при вводе ошибся то как моя "правильная" программа должна об этом узнать (от библиотеки).

> Векторные шрифты все такие -- цена переносимости и быстродействия. Мне уже предложили сделать шрифты с заполнением. Возможно к 1.6 они появятся. Пока можно увеличить толщину линий для большого размера шрифта.

Упоминавшийся здесь freetype рисует не векторные шрифты? :) У него гораздо лучше получается. Может все-таки прикрутить его? И дать возможность задавать шрифты вручную (может и можно, но я не нашел как)

> Не понял. Имеется ввиду автоматический вызов Axis()? А если я не хочу рисовать оси? Уже нарисованное убрать нельзя (только стереть весь рисунок целиком).

Нет. Имеется в виду, что при отрисовке 3D графика рисовать оси в центре куба вообще бессмысленно. Все виденые мной остальные программы/библиотеки расставляют числовые значения на передних гранях куба. Это отлично смотриться и, по-моему должно быть поведением по умолчанию для 3D графиков. В 2D графиках текущее поведение вполне нормальное.

> Что мешает установить gr->RotatedText = false; Тем более, что поворот подписей вдоль осей считается хорошим тоном при рисовании графика.

Видимо просто пропустил в документации :)

> Еще аргументы о "сыром проекте" есть?

Есть еще пожелания.

Например не плохо было бы иметь возможность отрисовывать opengl график в собственном окне, а не в glut. Если это уже возможно, то хотелось бы увидеть это в документации.

Может еще чего. Сейчас в голову не приходит.

> В базовом классе, я заметил функции writejpeg, writeps и т. п. Только те из них, что не поддерживались классом просто не производили никаких заметных действий. Что очень сбивало с толку. Такого быть в С++ не должно. Наследование создано не для таких фокусов

Вы имеете в виду абстрактные классы? Мне их использовать не хотелось по следующим причинам: совместимость разных ОС и компиляторов (почти вся серия 1.4.* -- исправление проблем совместимости) + в части наследников все функции не всегда реализованы, а значит пришлось бы их делать пустыми там (лишняя морока). Поэтому почти все virtual функции базового класса объявлены пустыми.

> Нет. Всего лишь четче разобрать кто-что умеет делать и привести интерфейсы классов в соответствие с этим.

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

> Допустим моя программа запрашивает некоторое выражение у пользователя, а затем в соответствии с ним заполняет массив для отрисовки (или модифицирует). Если пользователь при вводе ошибся то как моя "правильная" программа должна об этом узнать (от библиотеки).

Ошибся где? если при определении значений массива, то никак. Причина: все "ошибочные" (равные NAN) точки не рисуются -- это нормальное поведение для исключения области графика (точек) из рисования.

Если человек ошибся в размерностях массивов при передаче в функцию, то довольно подробное сообщение об этом записывается в переменную Message (если она не NULL).

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

Какую еще диагностику надо?

> Упоминавшийся здесь freetype рисует не векторные шрифты? :) У него гораздо лучше получается. Может все-таки прикрутить его? И дать возможность задавать шрифты вручную (может и можно, но я не нашел как)

Задавать шрифты напрямую не очень хорошая мысль. Причина: непереносимость получающегося кода между ОС. Сейчас код выполняемый под Linux, Windows, MacOS дает полностью одинаковую картинку. С собственными шрифтами под каждой ОС все надписи могут "поехать".

Насчет "заполненных" шрифтов я уже писал выше, что работать в этом направлении буду.

> Нет. Имеется в виду, что при отрисовке 3D графика рисовать оси в центре куба вообще бессмысленно. Все виденые мной остальные программы/библиотеки расставляют числовые значения на передних гранях куба. Это отлично смотриться и, по-моему должно быть поведением по умолчанию для 3D графиков. В 2D графиках текущее поведение вполне нормальное.

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

> Например не плохо было бы иметь возможность отрисовывать opengl график в собственном окне, а не в glut. Если это уже возможно, то хотелось бы увидеть это в документации.

Такой возможности нет и не будет. MathGL -- не замена оконным библиотекам. Причина: создание окна слишком различно на разных ОС, а библиотек делающих это уже много (wxWidget, FLTK, GTK+, Qt, GLUT и пр.). Использовать же вывод библиотеки в любой из них довольно легко (пример с GLUT реализован в MathGL, пример с FLTK -- UDAV, пример с wxWidget -- GraphPlot).

> Вы имеете в виду абстрактные классы? Мне их использовать не хотелось по следующим причинам: совместимость разных ОС и компиляторов (почти вся серия 1.4.* -- исправление проблем совместимости) + в части наследников все функции не всегда реализованы, а значит пришлось бы их делать пустыми там (лишняя морока). Поэтому почти все virtual функции базового класса объявлены пустыми.

Я имею в виду, что если у интерфейса объявлена пустая абстрактная функция, например, WriteSVG в классе mglGraph, то если существует не абстрактный класс mglGraphZB, я вполне законно ожидаю, что весь его интерфейс (все public и protected члены) реализованы и работают, так как ожидается. Но при тестировании оказалось, что не все, некоторые не работают. В данном случае это относится именно к функциям вывода. Производные классы должны расширять базовый функциями вывода характерными для них, а не наследовать все подряд.

> Так вроде это и так есть: базовый класс -- общее рисование основных типов графиков и осей + глобальные настройки, наследники -- рисование примитивов + настройка освещения, тумана и прозрачности + положение графика на рисунке + сохранение в файл.

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

> Ошибся где? если при определении значений массива, то никак. Причина: все "ошибочные" (равные NAN) точки не рисуются -- это нормальное поведение для исключения области графика (точек) из рисования.

Это я понял. К этому я и не придирался.

> Если человек ошибся в размерностях массивов при передаче в функцию, то довольно подробное сообщение об этом записывается в переменную Message (если она не NULL).

Ужас. А как узнать, какого размера буфер необходим? Как его затирать? Как проверять ошибку, strlen'ом? В С++ должны быть использованы исключения. Это очень продвинутый и удобный механизм. В С используется код ошибки в возвращаемом значении и обычно дают функцию, которая позволяет получить сообщение об ошибке. В фортране не знаю, но в lapack возвращают код ошибке в out параметре. Все это можно реализовать. Не вижу сложности.

> При разборе скрипта MGL выдается числовой код на предмет ошибки в строке (нет ошибок, неправильная команда, неправильные аргументы).

Подходит, но исключение в С++ лучше.

> Задавать шрифты напрямую не очень хорошая мысль. Причина: непереносимость получающегося кода между ОС. Сейчас код выполняемый под Linux, Windows, MacOS дает полностью одинаковую картинку. С собственными шрифтами под каждой ОС все надписи могут "поехать".

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

> Насчет "заполненных" шрифтов я уже писал выше, что работать в этом направлении буду.

Я понял. Это хорошо. Еще не понравилось, что шрифты чуствительны к размеру сирунка и деформируются вместе с ним. Если я смотрю на экране график и желаю величить его, чтобы рассмотреть получше, то не потому что мне не видна какая-то буква. Шрифты на экране, ИМХО, лучше добавлять постпроцессингом тогда они будут красивые (особенно если их сначала отрендрить с помощью freetype или win32 в текстуру :) ) и независимы от размеров рисунка. При изменении размера рисунка шрифты неизменны. Это относится к экрану, естейственно. Для сохранения в файл это не актуально.

> Не согласен. Положение осей определяется целью с которой Вы их рисуете. Если просто показать диапазон изменения величин, то можно и сбоку. А если показать значение высоты (или ширины, глубины) конкретной поверхности, то строить их надо внутри коробки (в том месте на которое стоит обратить внимание). В частности, для волновых пучков поле обычно спадает к краям и ставить там оси почти бесполезно.

Может быть для каких-то особых применений... Все-таки хотелось бы возможности отрисовать оси по передним внешним граням куба автоматически. Это очень часто необходимо, а определить какие грани будут передними и внешними при поворотах рисунка не тривиально. Более того может оказаться удобным, чтобы оси пересекались не в одной точке, например http://i042.radikal.ru/0801/c0/1b269a031035.png

> Такой возможности нет и не будет. MathGL -- не замена оконным библиотекам. Причина: создание окна слишком различно на разных ОС, а библиотек делающих это уже много (wxWidget, FLTK, GTK+, Qt, GLUT и пр.). Использовать же вывод библиотеки в любой из них довольно легко (пример с GLUT реализован в MathGL, пример с FLTK -- UDAV, пример с wxWidget -- GraphPlot).

А зачем ей быть заменой оконной библиотеки? Окно прогрммист создаст сам. OpenGL инициализирует тоже. А вот отрисовать на поверхности с помощью твойе библиотеки было бы удобно. Если не ошибаюсь opengl такое позволяет (последний раз писал под opengl года 4 назад, может чего и путаю, но меня не покидает уверенность, что так можно).

> Я имею в виду, что если у интерфейса объявлена пустая абстрактная функция, например, WriteSVG в классе mglGraph, то если существует не абстрактный класс mglGraphZB, я вполне законно ожидаю, что весь его интерфейс (все public и protected члены) реализованы и работают.

WriteSVG это единственный пример функции, которая не пуста только в mglGraphPS. Может быть ее действительно стоит перенести только в этот класс (в других она смысла не имеет вроде, хотя можно еще и в mglGraphGL засунуть) ???

> Ужас. А как узнать, какого размера буфер необходим? Как его затирать? Как проверять ошибку, strlen'ом? В С++ должны быть использованы исключения. Это очень продвинутый и удобный механизм.

Буфер нужен маленький (128 байт, вроде даже меньше), стирать легко *Message = 0. Проверять еще проще if(*Message) ... Это все при условии, что буфер определен. Насчет "должны быть использованы исключения" вопрос спорный. Если ищете абстрактную ошибку где-то, то наверное да. При неправильных аргументах функции -- строковые сообщения удобнее (на мой взгляд), поскольку дают информацию где и по какой причине нет графика. Кроме того, эти "ошибки" пользователя не приведут к краху программы (просто график не будет нарисован).

> Еще не понравилось, что шрифты чуствительны к размеру сирунка и деформируются вместе с ним. ..skipped.. Шрифты на экране, ИМХО, лучше добавлять постпроцессингом тогда они будут красивые (особенно если их сначала отрендрить с помощью freetype или win32 в текстуру :) ) и независимы от размеров рисунка. При изменении размера рисунка шрифты неизменны.

Спорное утверждение. Почему в векторном рисунке ДОЛЖНЫ быть растровые шрифты??? Уж если масштабировать, то все (как это нормальные векторные редакторы и делают). Кроме того, растровые шрифты имеют слишком много недостатков (очень плохо масштабируются, сложно сделать "перекрытие" буквы поверхностью, сложно поворачивать, сложно проецировать, и т.д. и т.п.). Я уж не говорю про "крошечные буковки" на увеличенном рисунке или огромные "буквища" на отдаленном рисунке (смотрится ... так себе). По-моему растр. текст в векторной графике скорее признак плохого тона (лени разработчика). Кстати, начинал я, как и многие другие, с растровых шрифтов, но ОЧЕНЬ быстро от них отказался.

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

Рисовать как в Mathematica легко: Axis("xz"); Org=mglPoint(xmax,ymin,zmin); Axis("y");. Кстати, Mathematica далеко не блещет своей графикой и уж точно не является стандартом в научной графике. Определение передних граней легко сделать если знаете углы поворота (поскольку сами их и задаете). Надо лишь сравнить углы (подробнее e-mail'ом если надо).

> А зачем ей быть заменой оконной библиотеки? Окно прогрммист создаст сам. OpenGL инициализирует тоже. А вот отрисовать на поверхности с помощью твойе библиотеки было бы удобно.

Ну если уж окно создано, и инициализация сделана ... то просто вызовите функции mglGraphGL :). Именно "отрисовать на поверхности" MathGL и делает :). А вот создавать и инициализировать окно MathGL точно не будет! (кроме случая GLUT).

> WriteSVG это единственный пример функции, которая не пуста только в mglGraphPS. Может быть ее действительно стоит перенести только в этот класс (в других она смысла не имеет вроде, хотя можно еще и в mglGraphGL засунуть) ???

Я так понял не единственный :). У меня какой-то из классов долго не хотел сохранять растровую картинку, а я долго не мог понять в чем дело. Ошибок не выводилось, хотя хз при таком способе оповещения :). А вот другой класс (mglGraphZB) успешно справился.

> Буфер нужен маленький (128 байт, вроде даже меньше), стирать легко *Message = 0. Проверять еще проще if(*Message) ... Это все при условии, что буфер определен. Насчет "должны быть использованы исключения" вопрос спорный. Если ищете абстрактную ошибку где-то, то наверное да. При неправильных аргументах функции -- строковые сообщения удобнее (на мой взгляд), поскольку дают информацию где и по какой причине нет графика. Кроме того, эти "ошибки" пользователя не приведут к краху программы (просто график не будет нарисован).

Где в документации об этом сказано? Ошибки разные бывают и позволить программисту самому думать что с ними делать -- обязанность библиотеки(если они не совсем внутренние). А то не рисует и пойми почему. Исключения не мешают передавать текстовые сообщения об ошибках. Более того программа с ошибкой не должна вести себя как ни в чем не бывало. Уж пусть лучше крашится (с неперехваченным исключением, например). Как вести себя пользователю, если программа запросила у него параметр для mglData::Modify, он что-то ввел и ничего не произошло. Он ошибся? Программа глючит? Что-то еще? Исключения хороши тем, что их нельзя пропустить. Если в программе что-то случилось она либо самовосстанавливается, либо завершается. Это хорошо. Честно говоря я вообще в первый раз встретил такой способ обработки ошибок и был сильно удивлен :)

> Спорное утверждение. Почему в векторном рисунке ДОЛЖНЫ быть растровые шрифты??? Уж если масштабировать, то все (как это нормальные векторные редакторы и делают). Кроме того, растровые шрифты имеют слишком много недостатков (очень плохо масштабируются, сложно сделать "перекрытие" буквы поверхностью, сложно поворачивать, сложно проецировать, и т.д. и т.п.). Я уж не говорю про "крошечные буковки" на увеличенном рисунке или огромные "буквища" на отдаленном рисунке (смотрится ... так себе). По-моему растр. текст в векторной графике скорее признак плохого тона (лени разработчика). Кстати, начинал я, как и многие другие, с растровых шрифтов, но ОЧЕНЬ быстро от них отказался.

Ты меня не понял. Шрифты должны быть векторные. Я предлагал их рендрить в текстуру (с прозрачностью :) ) непосредственно перед отрисовкой. Так проще всего задействовать стороннюю библиотеку. Маштабировать их тоже надо. Но логично задавать их размер просто читабельным, например 14pt, а не в пикселях (или в чем он? не ясно из документации). А вот рисунок в целом может быть и большим и маленьким. Но мне не надо мелкие буковки на маленьком рисунке и огромные на большом. Вообще чтобы удовлетворить всех лучше уметь задавать размеры шрифтов в пикселях, сантиметрах, пунктах и относительных единицах (по отношению к размеру самого графика). Тогда точно каждый найдет то что ему надо.

> Рисовать как в Mathematica легко: Axis("xz"); Org=mglPoint(xmax,ymin,zmin); Axis("y");. Кстати, Mathematica далеко не блещет своей графикой и уж точно не является стандартом в научной графике. Определение передних граней легко сделать если знаете углы поворота (поскольку сами их и задаете). Надо лишь сравнить углы (подробнее e-mail'ом если надо).

Хм, спасибо за пример. Мне так в голову не приходило :). Может сделать все-таки возможность автоматическтй расстановки осей для 3D? Все-таки это очень часто используемый случай. Еще оси не нужны при отображении поверхностей цветом (map), так как тоже чаще подписи идут по краям.

> Ну если уж окно создано, и инициализация сделана ... то просто вызовите функции mglGraphGL :). Именно "отрисовать на поверхности" MathGL и делает :). А вот создавать и инициализировать окно MathGL точно не будет! (кроме случая GLUT).

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

А вообще очень толковая библиотека может получиться если еще напильником поработаешь! Спасибо!

Кстати, насчет шрифтов, их очень прилично и кроссплатформенно умеет рендрить Anti-Grain Geometry http://www.antigrain.com

Хотя может и не кроссплатформенно. Сейчас посмотрел, а там упоминания freetype и win32

> Где в документации об этом сказано?

В описании класса mglGraph, в ChangeLog.

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

Так библиотека и сообщает почему.

> Более того программа с ошибкой не должна вести себя как ни в чем не бывало. Уж пусть лучше крашится (с неперехваченным исключением, например).

Ну уж если программа будут рушится от каждого случая несовместимых массивов, то я первый ее выброшу (сотру)!

> Как вести себя пользователю, если программа запросила у него параметр для mglData::Modify, он что-то ввел и ничего не произошло. Он ошибся? Программа глючит? Что-то еще?

А что там можно ввести кроме формулы? Кстати, в формулах тоже есть отдельный обработчик на ошибки GetError() :). Кроме того, в ряде случаев специально ввожу NAN для "удаления" части графика.

> Если в программе что-то случилось она либо самовосстанавливается, либо завершается.

Ну программа и "самовосстанавливается" -- график с неверными массивами не рисуется, а все остальное продолжает работать (и рисовать)

> Я предлагал их рендрить в текстуру (с прозрачностью :) ) непосредственно перед отрисовкой.

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

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

Для задания в пикселях, сантиметрах, пунктах и пр. надо знать размер рисунка. А он векторный и растягивается, т.е. смысла нет. А вот относительные единицы это ДА! именно они и используются (по ученому -- a.u.).

Причем во всех функциях печати можно задавать относительный размер шрифта (если числа отрицательные) от указанного в FontSize.

> Правильно, что не будет. Можно в документации в примерах использования изложить и этот способ, а не только с glut? Очень пригодилось бы :)

Ну вроде оно и написано. Попробую еще раз продублировать в паре мест.

> А что там можно ввести кроме формулы? Кстати, в формулах тоже есть отдельный обработчик на ошибки GetError() :). Кроме того, в ряде случаев специально ввожу NAN для "удаления" части графика.

В формуле можно случайно описаться.

> Так библиотека и сообщает почему.

Уж больно неожиданно сообщает. Неужели нельзя это сделать традиционным образом.

> Ну программа и "самовосстанавливается" -- график с неверными массивами не рисуется, а все остальное продолжает работать (и рисовать)

В этом случае восстанавливается не программа, а библиотека. Я если при не правильных данных мне надо послать e-mail, а не пустые картинки рисовать? Программа сама решит, что делать в случае неправильных формул, данных и т. п. Библиотека на себя это брать не должна.

> Для задания в пикселях, сантиметрах, пунктах и пр. надо знать размер рисунка. А он векторный и растягивается, т.е. смысла нет. А вот относительные единицы это ДА! именно они и используются (по ученому -- a.u.).

А в чем проблема? dpi для экрана знает X сервер. В винде он фиксированный. Для растровых картинок его может указать пользователь. Для векрорных -- можно задавать размер финального изображения, которое учитывается при печати/просмотре, несмотря на то, что само изображение может произвольно маштабироваться.

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

Библиотека сообщает об неправильных данных, посмотрите хотя бы mgl2png, mgl2eps, mgl2svg, UDAV. И программа решает что делать дальше (в моем случае вывести на экран). Но это не повод останавливать рисование!

> А в чем проблема? dpi для экрана знает X сервер. В винде он фиксированный. Для растровых картинок его может указать пользователь. Для векрорных -- можно задавать размер финального изображения, которое учитывается при печати/просмотре, несмотря на то, что само изображение может произвольно маштабироваться.

Так опять упираемся в ОС зависимые особенности, а то еще и у человека спрашивать. Кстати, даже под Windows dpi экрана не фиксирован. Это уровень программ рисования (оконных библиотек), а не MathGL.