Отчечаю почему linux.org.ru - это инструмент, который традиционно использовался на nixах и доступен под GNU лицензией. На сколько мне известно описния на русском в природе не существует.

Что тут скажешь - прочитал и осуждаю.
Луговский, помнится, пропагандировал этот PAW (помимо всего прочего...) как один из лучших инструментов обработки данных.

есть все номера журналов, может отсканировать и выложить, кому нибудь надо?

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

Лучше бы системного администратора. :)

Вам нужно объяснить почему этого делать нельзя?

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

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

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

Кстати, а почему удалили вчера сообщение не подскажете? Вроде с 2000-го года GPL, если уж про Мозиллу пишут здесь, то уж и про это не должно возбраняться. В правилах про "свободное программное обеспечение и OSS" явно написано.

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

Так оно и есть. Другое дело, что это _только_ инструмент, а не решение.

Сабж

Прекратите насиловать труп!

> И если выбор Фортрана понятен, то зачем нужен скриптовый язык я пока не понял.

Я думаю что причины исключительно исторические. С другой стороны Fortran не предназначен для интерактивной работы - его слишком сильно надо менять. Хотя наличие двух языков одна из слабых сторон PAW. В этом отношении ROOT лучше, но там есть свои тараканы в головах разработчиков.

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

PAW предназначен для работы с _очень_ большими объёмами данных :) - gnuplot там захлёбывается, да и подгонка в gnuplot не так развита, да и гистограммы в gnuplot весьма своеобразно прикручены. У всего есть свои плюсы/минусы.

Да собственно о том и разговор. У меня не слишком большие объёмы - ASCII файл не больше двух сотен мегабайт занимает, да и всё, что мне нужно с ним сделать - это картинку построить, может с уровнями. А всё остальное я С-шной программкой сделаю. Так и быстрее (если надо в скриптовом режиме несколько сот файлов обработать) и надёжней.

Кстати, а сам PAW никак тоже на Фортране написан? Или после появления ROOTS достаточно gcc (качество и быстродействие GNU-того Фортрана многие ставят под сомнение) чтобы его собрать?

Да, ещё тема про удаление осталась нераскрыта. :-)

> Да собственно о том и разговор. У меня не слишком большие объёмы - ASCII файл не больше двух сотен мегабайт занимает, да и всё, что мне нужно с ним сделать - это картинку построить, может с уровнями. А всё остальное я С-шной программкой сделаю. Так и быстрее (если надо в скриптовом режиме несколько сот файлов обработать) и надёжней.

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

> Кстати, а сам PAW никак тоже на Фортране написан? Или после появления ROOT достаточно gcc (качество и быстродействие GNU-того Фортрана многие ставят под сомнение) чтобы его собрать?

PAW написан на Fortran и ему для компиляции достаточно g77. Поэтому PAW довольно переносимая программа. Различие в быстродействие в компиляторах для программ анализа IMHO не критично, так как основной тормоз - это человеческий мозг :)

> Да, ещё тема про удаление осталась нераскрыта. :-)

Я могу сказать только одно - удалял не я :)

Под GPL, да не совсем. Некоторые пакеты CERNLIB (в основном монте-карло генераторы) никогда не лицензировались под GPL, ибо их авторы согласия не давали (к GEANT-FLUKA -- так вообще даже исходников нет, а его авторы с тех пор обозлены на "захватчиков кода").

>>Да, ещё тема про удаление осталась нераскрыта. :-)

anonymous_incognito извинялся же уже:
http://www.linux.org.ru/jump-message.jsp?msgid=1634801

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

Понятно - надо мне в форумы заглядывать :)

> Поэтому PAW довольно переносимая программа.

Это не так. Под 64-битные архитектуры сборщики пакетов вынуждены хаки изобретать.

>> Поэтому PAW довольно переносимая программа.

>Это не так. Под 64-битные архитектуры сборщики пакетов вынуждены хаки изобретать.

Ничего сказать не могу, но IMHO под alpha оно было с самого начала.

http://packages.debian.org/unstable/science/paw

Versions: 1:2.14.04-5 [m68k], 1:2.14.04-6 [alpha, amd64, arm, i386, ia64, mips, mipsel, powerpc, s390, sparc], 1:2.14.04-6+b1 [hppa]

У PAW есть и другой successor, не такой раскрученный как ROOT, но тоже весьма умелый -- mn_fit (доступ к COMIS, MINUIT и другим церновским библиотекам прилагается).

> У PAW есть и другой successor, не такой раскрученный как ROOT, но тоже весьма умелый -- mn_fit (доступ к COMIS, MINUIT и другим церновским библиотекам прилагается).

Очень любопытно - действительно довольно развитая система с очень подробной документации доступная из коробуи в Debian. Надо поразбираться.

Но как я понял, что это всё-таки не successor, потому как PAW как mn_fit - это просто морда к CERNLIB, а ROOT декларирует полную от него независимость.

Неточно выразился :). Да, он саксессор как PAW, не как рут. То есть альтернативная морда к цернлибу.

На сколько мне известно PAW практически умер. Основные разрабочики мигрировали в root (В CERN сейчас есть целая команда по его разработке, в рамках LCG project: http://lcgapp.cern.ch/project/). PAW используется в старых экспериемнтах, где переход на root (или что-то другое) экономически/политически не выгоден.

Про root будет третья часть серии. Собственно говоря, в статье этот вопрос рассмотрен.

PAW в довольно большом количестве случаев "удобнее" чем root в качестве интерактивной системы анализа. IMHO она заслуживает рассмотрения хотя бы для взятия основных идей стоящих в её основе на вооружение.

А почему в англицкой версии диск с Федорой 6-й и новой Убунтой , а нас миникс3 :))) столетней давности ???

Задайте этот вопрос представителям редакции: http://linuxforum.ru/?showforum=57

"Очень большого объёма" -- полезное весьма свойство. Учитывая, что та же octave все данные в оперативке держит... А для небольших объемов достаточно и связки octave+gnuplot. Признаюсь, man gnuplot я недокурил, так что юзаю его поверх octave, в стиле matlab.

Введение в PAW == Wvedenie_w_PsichoAktivnijeWeschestwa

По моему опыту, курита надо help в gnuplote, а не man. Да и то, без дополнительного изучения примеров из соответствующей директории в каталоге с документацией многое остаётся непонятный. Зато потом... Изготовление видео использую gnuplot для генерации картинок и mencoder для сборки картинок в нужного формата видео с помощью простейших скриптов совсем не проблема.

Мда, с каким-то японским акцентом получился пост. :-)

не "курита", а "курить", не "непонятный", а "непонятным".

Сорри!

IMHO info в gnuplot вполне внятное. Согласен, что если точно известно что надо нарисовать "на автомате", то gnuplot идеальный инструмент.

> Прекратите насиловать труп!
Согласен.
Евгений, PAW - это прошлое тысячилетие.
Лучше было бы о ROOTе по-русски.
Готов стать Вашим со-автором (Valeri.Onouthine@cern.ch)

> Лучше было бы о ROOTе по-русски.

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

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

P.S. Кстати, ROOT тоже из прошлого тысячилетия :), да и мы с вами :P

А вот кстати появился вопрос к соавтору ROOTа: вы не планируете сделать для него какой-либо сильно облегченный скриптовый язык типа PAWшного? А то очень уж муторно для построения простейшей картинки типа TGraphErrors на 1 TCanvas'e писать строчек 15 -- читать файл, заполнять массив и тп. На PAW такие вещи делаются мгновенно.

> А вот кстати появился вопрос к соавтору ROOTа: вы не планируете сделать для него какой-либо сильно облегченный скриптовый язык типа PAWшного?

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

Rene, против этой идеи, которую когда-то я ему предложил, поэтому все "под ковёр замели".

Кто-нибудь смотрел в сторону OpenScientist? (http://openscientist.lal.in2p3.fr/)

Выглядит многообещающе, обещают поддержку KUIP, Python и Tcl. Но все эти анафемы в адрес Cernlib/ROOT несколько смущают.

> Но все эти анафемы в адрес Cernlib/ROOT несколько смущают.

А вы не смущайтесь - действительно и у CERNLIB/PAW и у ROOT есть слабые стороны. Желание всё это переписать возникает у каждого, кто с этим начинает работать :) В нашей группе есть человек, который создал гораздо более развитую библиотеку для работы с гистограммами XBOOK в противовес HBOOK, но сделать библиотеку и сделать продукт к сожалению две большие разницы. Здесь выживает то, что выжило.

> Rene, против этой идеи, которую когда-то я ему предложил, поэтому все "под ковёр замели".

Очень жаль. IMHO самая слабая сторона ROOT (пожалуй, кроме ещё документации), с точки зрения пользователя для целей интерактивного анализа.

Полностью согласен, по сути дела,
многие его используют в batch-режиме -- запустил,
вылезли картинки. Что-то не понравилось, поправил
скрипт и опять запустил. И так до опупения.
В PAW это гораздо проще делается.
Тогда уж хотя бы сам интерпретатор более богатым сделали.

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