Veusz 3.0

Veusz — программа построения научных графиков

Так называемая «наука» не нужна. Особенно с графиками. Изобретение западной цивилизации разврата и разложения, она только обслуживает общество потребления и будущую технократическую дистопию, её существование должно быть прекращено.

Вся необходимая человеку истина находится в Боге и в Природе.

Слишком толсто :)

А кто доверти виндовс серьезные данные если ты не в США?

Нет, и Бог тогда тоже не нужен, только природа, твоя - жрать да срать в коментах ;)

Гм. Ну как бы нет. Это не абы кто, а топовые ученые с отличной наукой, публикациями в PNAS, Science Advances и прочих Q1. Просто у них уже свои выстроенные публикационные пайплайны, которые сложно натягивать на наш стиль работы.

Это не абы кто, а топовые ученые с отличной наукой

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

Просто у них уже свои выстроенные публикационные пайплайны, которые сложно натягивать на наш стиль работы.

Слишком политкорректно ты выразился. Это называется «осилили только Origin и не хотим нормальные инструменты, нам насрать на то, что мы делаем».

Херня. Все используют R И ROOT.

Максимум у старых теоретиков.

И сколько сотен графиков ты так потыкаешь за один час времени, например?

Окей, олдскульные ребята с фортраном пользуются и HBOOK/PAW.

Эта хрень умеет обрабатывать ROOT-деревья? Если нет - что в ней вообще можно чертить? Выходы в ASCII?

Я тоже использовал вначале qtiplot (аналог origin), пробовал SciDavis (форк qtiplot) и Veusz, но потом вдруг понял зачем все это если есть pgfplot? Для любителей TeXа, вроде меня, это оно самое. Делают численный файл графика в Mathematica и потом обрабатываю в pgfplot. Возможности у него огромные, получаются отличные картинки. Но проект поддерживаю, кому-то все равно покажется удобным, а значит работа была не зря.

А надо комбайны, что ли?

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

версия 0.9.8.9 года 2011 эдак вполне себе лежит в виде исходников

Крафчу научные графики на R в среде RStudio и доволен

Не нашёл, можно ли в Veusz построить касательную? И найти точку пересечения линий, графиков или касательных?

Везёт, я под виндоус решил глянуть, но ни 2.2, ни 3.0 не запустились. Поиск ошибки вывел на 2 бага, которые до сих пор открыты и обсуждение ясности не вносит: то ли ему python 3.4 в системе подавай, то ли ещё что-то. А с какими зависимостями автор программы собирал бинарник, он не поясняет, а само приложение просто падает без каких-либо логов или собственных окошек.

Кстати, как основной автор и руководитель проекта он в любой момент может поменять лицензию. Сюрприз-сюрприз!

с качеством «готовое к публикации»

Всегда удивлялся - почему все это ПО для построение графиков «для публикации» выдает такие стремные рисунки по умолчанию?

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

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

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

Линусу Торвальдсу расскажи.

Сейчас он не основной автор проекта и кода.

Не знаю что там было на форуме, вики только упоминает о каких-то разногласиях в целях проекта и способах его монетизации, после чего появился Scidavis.

Исходники qtiplot на самом деле никому не нужны, что можно видеть и на примере исходников scidavis - никто толком его не развивает, хорошо, что хоть мелкие баги правят ещё. Всё гораздо только кричать «даёшь исходники!».

А на примере тех же fbreader и coolreader видно, что больше всех переживающее за наличие «исходников» сообщество до сих пор не в состоянии сделать для первого двухстраничный режим просмотра, а во втором случае добавить простенькую каталогизации книг, взяв её пусть даже из первого. Стоит авторам переключиться на другой проект, так об открытых исходниках самые активные возмущенцы сразу забывают.

Появилась страничка с 3D примерами, раскрывающая новые возможности.

https://veusz.github.io/3d/

Сейчас он не основной автор проекта и кода.

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

Не знаю что там было на форуме

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

Исходники qtiplot на самом деле никому не нужны

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

что можно видеть и на примере исходников scidavis - никто толком его не развивает

На примере qtiplot также видно, что он толком сам не развивается.

зачем собирать, если есть бинарники?

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

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

зачем собирать, если есть бинарники?

Затем, что бинарников нет.

толком не толком, а изменений там больше, чем в scidavis.

Ага. Дополнительные фильтры приколхозил разработчик.

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

Вроде нормально сглаживание там работает. Или на чём-то специфическом спотыкается?

Как нет бинарников, есть же!

Ну и чего тогда переживаешь? Бери и используй последнюю общедоступную версию.

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

Есть тут те, кто пробовал? Легковеснее matplotlib?

Вот только анализ на питоне не делает никто. Зачем ждать вечность если есть FORTRAN/C++?

Вроде нормально сглаживание там работает. Или на чём-то специфическом спотыкается?

Вот пример ненормального сглаживания в scidavis. Ничего специфичного. Простая парабола построенная по набору точек x от "-5" до «5» с шагом «1». В обоих случаях включен антиалиазинг. Надписи о названиях программ и о границах добавлены в GIMP. Одна из них повествует о том, что видимой верхней и правой границы рамки на самом графике не было. Она таинственным образом появляется при экспорте, например, в png.

Оба графика приведены к одному виду.

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

Для построения графиков по уже готовым данным скорость не является хоть сколько-нибудь лимитирующим фактором. Питон де факто сейчас является безальтернативным клеем для C++ модулей (Fortran — это либо легаси, либо очень специфичные параллельные задачи, который опять же легаси), так что говорить, что анализ на python никто не делает является довольно глупой ошибкой (подсказка: это я рассказал как делается анализ в коллаборации ATLAS).

Строить ли итоговые графики с помощью cxx-скрипта или py-скрипта — это вопрос исключительно предпочтений конкретного человека/его настроения/предыстории.

Python более удобен в случае написания процедуры, которая выдаёт итоговый результат по одному запуску скрипта. А cxx удобен тем, что изначально его легко начать сбросив туда набор уже проверенной цепочке интерактивных команд ROOT, а потом долго сокрушаться когда оный безнадёжно разрастается.

Fortran — это либо легаси, либо очень специфичные параллельные задачи, который опять же легаси

Какой-то бред. Не знаю ничего, что так же легко и быстро работает с I/O как FORTRAN, и это качество вкупе со скоростью числодробления является определяющим во многих задачах. И почему HBOOK до сих пор лучше ROOT-а?

Питон де факто сейчас является безальтернативным клеем для C++ модулей

Поэтому его не используют в нормальных коллаборациях? ATLAS — это смешно, там питон используют полтора хипстера с подворотами. ALICE/CBM/SHINE/COMPASS/FOPI/HADES/MPD/BM@N - там такой херни нет.

анализ на python никто не делает является довольно глупой ошибкой

Анализ на python никто не делает и графики в своём уме никто им не рисует.

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

Чем он более удобен? Тем, что постоянно не работает, требует какие-то модули и крэшится? Я как-то переписывал чужой пихонокод на обычный shell чтобы всё-таки задача выполнялась правильно: оказалось, что так получается быстрее и прозрачнее и работает не только на машине автора.

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

ROOT в интерактиве? Воу... Даже не знаю что сказать.
Кстати, когда он безнадёжно разрастётся? У меня программа плюётся сотнями _разных_ графиков и гистограмм для десятка разных систем и энергий, но пока за сотню строк так и не вышла.

И почему HBOOK до сих пор лучше ROOT-а?

Это не так. Файлы, которые генерит HBOOK — это ужас-ужас-ужас. Для создания больших нтаплов следует принимать весьма нетривиальные действия без особых гарантий на успех. Раньше с этим проблем не было, но сейчас объём сохраняемых данных увеличился в миллион раз (оптимистично). Сложность структуры данных тоже серьёзно возросла и CERNLIB для этого давно не хватает. Несмотря на переусложнённость ROOT альтернативы ему сейчас нет.

Анализ на python никто не делает и графики в своём уме никто им не рисует.

Во первых и делает, и рисует — тому есть масса успешных примеров. Во вторых никто не мешает использовать ROOT для отрисовки прямо из python.

Тем, что постоянно не работает, требует какие-то модули и крэшится?

Скорее всего вы просто не умеете его готовить.

ROOT в интерактиве? Воу... Даже не знаю что сказать.

Скажите, что вы не имеете опыта в современных анализах. Это будет честно. Да, он для этих целей в каком-то смысле менее удобен, чем скажем R, но использовать его в интерактиве (ну или для запуска коротких скриптов) можно.

пока за сотню строк так и не вышла.

У вас либо очень простая и не нужная программа, либо вы чего-то не договариваете. Например, что данные до скармливания этой программе уже подготовлены. Просто рисовать графики — это легко. Сложно понять а) что нужно нарисовать, б) какие у того, что нарисовано, систематики и наконец, в) как эти систематики прикончить...

ROOT альтернативы ему сейчас нет

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

Во первых и делает, и рисует — тому есть масса успешных примеров. Во вторых никто не мешает использовать ROOT для отрисовки прямо из python.

В перечисленных выше коллаборациях не знаю ни одного.

Скорее всего вы просто не умеете его готовить.

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

но использовать его в интерактиве (ну или для запуска коротких скриптов) можно.

Можно, но не вижу в этом особого смысла. Разве что проверка на коленке записи в root-файл.

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

Конечно подготовлены. Правда всё равно программами на FORTRAN/C++ с использованием некоторых библиотек из поставки рута — разносить рисование и основной код это такой хороший тон.

Для построения графиков по уже готовым данным скорость не является хоть сколько-нибудь лимитирующим фактором.

Только если тебе не нужно построить 10 000 графиков в высоком разрешении и склеить мувик. Питон в этом плане и близко не стоял, gnuplot это наше всё

Fortran — это либо легаси, либо очень специфичные параллельные задачи, который опять же легаси

Далеко не легаси, просто очень специфичный.

Только если тебе не нужно построить 10 000 графиков в высоком разрешении и склеить мувик. Питон в этом плане и близко не стоял, gnuplot это наше всё

Согласен, что это отдельная задача, которая требует специалиpованных инструментов. Другое дело, что если инструмент грамотный, то его можно вызывать из Python. И да, я представляю что такое gnuplot и я с его помощью написал систему медленного контроля, которая каждые пятнадцать минут генерит тысячи графиков на протяжении уже более чем десять лет, но IMHO конкретно для анализа данных это неудобный инструмент.

Далеко не легаси, просто очень специфичный.

Специфичный тут фактически эквивалентен легаси, как и все эти оптимизирующие языковые компиляторы разрабатываемые 30+ лет.

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

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

В перечисленных выше коллаборациях не знаю ни одного.

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

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

Конкретно эта проблема не является специфичной для Python. Я наблюдал (да чё уж там и сам время от времени писал) ужасный код и на Fortran, и на C, не говоря уж о C++. Есть и более жуткие языковые примеры. Python тут особо не выделяется. Плохую программу можно написать на любом языке программирования.

Правда всё равно программами на FORTRAN/C++ с использованием некоторых библиотек из поставки рута — разносить рисование и основной код это такой хороший тон.

Зависит от ситуации. Анализ данных вещь временами крайне сложная и нелинейная. Часто удобно и полезно, чтобы всё выдавалось автоматически в результате работы одного скрипта. Максимум двух (собственно отбор данных выполняемый на гриде и анализ уже отобранных событий локально).

Специфичный тут фактически эквивалентен легаси, как и все эти оптимизирующие языковые компиляторы разрабатываемые 30+ лет.

Да, но на этом всё строится. Взять тот же BLAS.

как и все эти оптимизирующие языковые компиляторы разрабатываемые 30+ лет

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

Это у нас из-за провала в численности научных сотрудников среднего возраста из-за 90-x получилось так, что «ветераны» ещё помнят FORTRAN 77 (90 им было уже без особой надобности учить) и в лучшем случае немного модифицируют свой давно отлаженный код, либо достаточно ещё молодые, которые в институте скорее всего учили C и C++ (в МАИ, слышал в середине 2000-x был Фортран, но не знаю какой) и что-то дописывают к старому коду или пишут в целях изучения.

Но такая ситуация только на пост-советских территориях. В Западной Европе и США продолжают его активно использовать. Если бы это было не так, то и развитием стандарта не занимались бы.

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

Никто не мешает использовать уже имеющиеся библиотеки из удобной среды. На чём они написаны совершенно без разницы.

Да и начинать с нуля нет ничего плохого: инструментов для разработки в том числе под не-x86 хватает, а подрубить можно и фортране код и на Си. Вон даже nvidia подвязалась не так давно.

Вон даже nvidia подвязалась не так давно.

Гхмм. Они пустили Fortran в видеокарту? Интересно. А ссылку можно?

https://www.pgroup.com/

самый низ страницы, где копирайт. Нвидиа в каком-то году купила компанию и теперь это её подразделение. Поддержка cuda тоже имеется.

Спасибо.