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

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

Так какие проблемы с растром гененирующимся в рантайм на лету? Можно подробнее?

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

Так в чем проблема сообщать так, как принято (С++ -- исключения, С и Фортран -- возвращаемое значение), а не так как получилось?

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

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

Я так понял, что в разнесении функций вывода в соответствующие классы, я убедил?

Что насчет режима автоподбора осей для расстановки меток?

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

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

Хорошо в следующей версии будет inline функция для установки размера шрифта по заданному размеру (в пунктах) и dpi при текущем размере картинки.

> Я так понял, что в разнесении функций вывода в соответствующие классы, я убедил?

Нет. Скорее это повод дописать SVG экспорт в оставшихся двух режимах :).

> Что насчет режима автоподбора осей для расстановки меток?

Что имеется в виду?

> И почему все-таки не использовать стороннюю библиотеку для отрисовки шрифтов?

Де факто собираюсь. Но сначала конвертор в примитивы, а потом уже их рисование.

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

По времени ... я думаю месяц или два. С отчетами РФФИ почти разобрался, вот пару статей отправлю и займусь шрифтами :). А с произвольным системным шрифтом скорее всего не выйдет (по крайней мере в ближайшее будущее).

> Так в чем проблема сообщать так, как принято (С++ -- исключения, С и Фортран -- возвращаемое значение), а не так как получилось?

Насколько я помню exception прерывает выполнение программы/библиотеки?!? т.е. если оно возникает, то вообще НИЧЕГО рисоваться не будет, а не только график с неправильными массивами. На мой взгляд это слишком.

В том, что бы добавить переменную GraphError с числовым кодом (фактически дублирующую Message) Вы меня убедили.

> Насколько я помню exception прерывает выполнение программы/библиотеки?!?

o_O Яволь

> ообще НИЧЕГО рисоваться не будет, а не только график с неправильными массивами. На мой взгляд это слишком.

Есть мнение, что лучше никакого результата, чем неправильный результат.

> Насколько я помню exception прерывает выполнение программы/библиотеки?!? т.е. если оно возникает, то вообще НИЧЕГО рисоваться не будет, а не только график с неправильными массивами. На мой взгляд это слишком.

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

Обычно (в теории обязательно) фукции дают следующие гарантии по исключениям:

1. Если в функции произошло исключение, то прогрмма находиться в произвольном корректном состоянии.

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

3. Функция не порождает исключений.

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

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

Например,

class mgl_parce_error: public mgl_error
{
 private:
  int l;
  std::string message
 public:
  mgl_parse_error(int line, const std::string & msg):
    l(line), message(msg)
  {
  }
  const std::string & msg()
  {
   return message;
  }
  const int line()
  {
   return l;
  }
};

И где-то в коде при парсинге:

throw mgl_parse_error(line, ") expected before +");

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

> Например,

> class mgl_parce_error: public mgl_error

и чтобы mgl_error был производным от std::runtime_error :)

Уже сделал переменную WarnCode, которая содержит код предупреждения пользователю о неправильных данных. Фактически аналог Message.

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

> Уже сделал переменную WarnCode, которая содержит код предупреждения пользователю о неправильных данных. Фактически аналог Message.

Все равно плохо. Лучше, конечно (а то как узнать что в программе случилось программным путем, текст парсить?)

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

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

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

P. S. Могу помочь с кодом. Только времени у меня совсем не много, но тем не менее.

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

А если распределение поля не нарисовалось? Зачем нам граница? А вот с исключениями мы
можем сами решить, что важно, а что нет. Ниже два примера, первый, когда все неважно,
второй -- все важно. Сочетать можно как угодно что-то важно, а что-то не важно :).

Пример кода, который все равно будет рисовать в случае ошибки:

{
 try { mgl-><что-то рисуем>; } catch(mgl_error & e) { std::cerr << "Warning: " << e.msg() << std::endl; }
 try { mgl-><еще что-то рисуем>; } catch(mgl_error & e) { std::cerr << "Warning: " << e.msg() << std::endl; }
 try { mgl->WriteJPEG(...); } catch(mgl_error & e) { std::cerr << "Can't save file; reason: " << e->msg() << std::endl; }
}

Пример кода, который завершает программу при первой же ошибке:

{
 try
 {
  mgl-><что-то рисуем>;
  mgl-><еще что-то рисуем>;
  mgl->writeJPEG(...);
 }
 catch(mgl_error & e)
 {
  std::cerr << "An error occured while plotting: " << e.msg();
  exit(1);
 }
}

И таких вариантов можно придумать до бесконечности.

> > Уже сделал переменную WarnCode, которая содержит код предупреждения пользователю о неправильных данных. Фактически аналог Message.

> Все равно плохо. Лучше, конечно (а то как узнать что в программе случилось программным путем, текст парсить?)

Оптимально. Иначе как Вы собираетесь exceptions в C/Fortran'е обрабатывать? Кроме того, у меня нет уверенности в переносимости под разные компиляторы и платформы.

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

Программист и теперь может решить, прерывать рисование или нет. Спор идет о действиях по умолчанию. Excpetions хороши когда ошибка серьезная, так что все дальнейшее смысла не имеет. И в этом плане они лучше чем abort() или exit(). В случае если только лишь выдается предупреждение, то они почти бесполезны.

Пример: у компилятора есть опция считать все warnings ошибками. И часто Вы с ней компилируете? Особенно когда надо написать мелкую программку, а не большой долго-живущий проект?!

> А ты по образованию физик или математик? В тебе чуствуется алгоритмист, а не разработчик. Без обид только. Просто библиотека очень неплоха, но есть мелочи, которые просто не дают ее использовать.

По образованию физик-теоретик (нечто среднее между физиком и математиком :) ).

Насчет алгоритмиста -- я стараюсь обкатывать мысленно, на себе, на окружении разные варианты (возможности) кода -- это и по истории SVN видно. И выбираю тот который мне кажется более логичным (красивым, стройным :) ), дает больше возможностей и МЕНЬШЕ затрат от конечного пользователя. Идеально -- человек указал файл, написал построить данные (в сумме 2 строчки) и график готов, если хочется улучшить, то ЧУТЬ-ЧУТЬ поправил и опять готово. Именно поэтому, например, большинство (почти везде) стилевых параметров графиков задается строками, порядок аргументов (интерфейс) у всех функций схожий (по-крайней мере вначале) и т.д.

Насчет кода помощь приветствуется. И некоторые вставки (в основном из совместимости) от других людей в коде уже есть. А со временем и у меня всегда проблемы ... :(

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

> Оптимально. Иначе как Вы собираетесь exceptions в C/Fortran'е обрабатывать?

Для С пишется что-то вроде:

extern "C" int mgl_WriteJPEG(mglGraph * gr, ...)
{
 try
 {
  gr->WriteJPEG(...);
  return 0;
 }
 catch(mgl_error & e)
 {
  return e.errcode();
 }
}

Для Fortran похоже.

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

А вот это совсем напрасно. Все весьма переносимо. как с точки зрения компиляторов, так и с точки зрения платформ.

> По образованию физик-теоретик (нечто среднее между физиком и математиком :) ).

Очень заметно :) . Я вообще-то тоже, н по роду занятий пришлось много программировать.

> Насчет алгоритмиста -- я стараюсь обкатывать мысленно, на себе, на окружении разные
варианты (возможности) кода -- это и по истории SVN видно. И выбираю тот который мне
кажется более логичным (красивым, стройным :) ), дает больше возможностей и
МЕНЬШЕ затрат от конечного пользователя. Идеально -- человек указал файл, написал
построить данные (в сумме 2 строчки) и график готов, если хочется улучшить, то
ЧУТЬ-ЧУТЬ поправил и опять готово. Именно поэтому, например, большинство
(почти везде) стилевых параметров графиков задается строками, порядок аргументов
(интерфейс) у всех функций схожий (по-крайней мере вначале) и т.д.

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

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

В целом Вы правы. Стиль работы действительно почти такой -- сначала прикинуть график на одном примере, потом запустить его на всю серию(-и) данных и выбирать/анализировать картинки. К статье еще проще -- почти каждый график уникален (должен показать какую-то одну особенность). Так ведь вся научная графика такая :| .

По поводу коробочного варианта: все равно он ориентируется на некоторый более менее узкий диапазон применения. И проверку входных параметров там надо делать независимо от библиотеки рисования. Не будет же этот "коробочный вариант" только рисовать? нужна еще и обработка, расчет и пр. Соответственно и обработка ошибок там будет много раньше.