> Есть Mathematica от Wolfram, в которой гораздо больше фич, чем в ROOT

Это разного поля ягоды. Mathematica -- CAS, а ROOT -- (в принципе) 
(massive) signal processing. 

> только коммерческая она и за денежки

За такие деньги лучше купить Reduce. :)

> Но она гораздо прямее, понятнее, удобнее и правильнее

Да, но у нее тоже есть свои проблемы. См.

http://www.cs.berkeley.edu/~fateman/papers/mma.pdf

http://arxiv.org/pdf/cs.sc/0004015

> вот он на людей и бросается и в бреду мечется :)))

А что Вы скажете про автора hep-ph/0202033?

"Во-первых, вычисления в физике (в частности -- в квантовой теории поля) это не только (и не столько) числодробильня. Во-вторых, и для числодробильни FORTRAN плохо подходит."

вроде слова умные знаешь, а Ландау как главную заслугу приписал "интегралы брать научил". Вот бы такого спеца в проганьи, каким был Л.Д. в физике.

>Вот бы такого спеца в проганьи, каким был Л.Д. в физике.

А в чём проблема? Программирование гораздо проще физики. Абсолютно управляемая и предсказуемая среда.

> а Ландау как главную заслугу приписал "интегралы брать научил"

IMHO, создание научной школы -- это и есть одна из самых существенных
заслуг Льва Давидовича.

>А что Вы скажете про автора hep-ph/0202033?

Он на людей не кидается?

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

Гораздо сложнее понять что делать, чем сделать это. Язык не имеет значения. Это вопрос удобства. Для задач физики знание физики первично - всё остальное в лучшем случае плюс или минус десять процентов ко времени.

> А в чём проблема? Программирование гораздо проще физики. 

Вот благадаря такому отношению и имеем кривые поделия вроде $SUBJ.

Чукча не читатель, чукча писатель?

> Он на людей не кидается?

К сожалению, нет.

> Язык не имеет значения.

Неверно.

> Это вопрос удобства. 

Тоже неверно. Программирование на низкоуровневом языке (FORTRAN, C++, etc)
слишком отвлекает от собственно решаемой задачи и требует кучи знаний,
не относящихся к существу вопроса.

> Для задач физики знание физики первично - всё остальное в лучшем случае
> плюс или минус десять процентов ко времени.

И опять неправильно. Физик, не владеющий мат. аппаратом -- это не физик.
Дело идет к тому, что физик, не умеющий программировать -- это тоже не
физик.

> Вот благадаря такому отношению и имеем кривые поделия вроде $SUBJ.

Сделай не кривое - а пока увы и ах. Экспериментальный факт: круто то, что работает. Всё остальное нервно курит в сторонке.

> Дело идет к тому, что физик, не умеющий программировать -- это тоже не физик.

Особо не обольщайтесь сравнивая программирование и математику. Математика это язык, а программирование это набор не сильно сложных технологий.

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

А нах он нужен? Я долго ковырял мозжечёк, но так и не понял куда его прикрутить. ИМХО развлечение для физиков-онанистов.

To Dselect

>> давай - покажи класс - и перепиши ROOT на правильном языке

> Нафиг надо? Есть ведь нормальный софт:

> http://scilabsoft.inria.fr/index.php

А у Scilaba есть ntuple'ы и возможность интерактивной работы с ними? Я что-то при быстром просмотре не заметил. Где про это можно почитать?

> Я долго ковырял мозжечёк, но так и не понял куда его прикрутить.

Мозжечёк, вообще-то говоря, для того, чтобы равновесие держать. Думают обычно другим местом - нет, нет, не задним.

> Особо не обольщайтесь сравнивая программирование и математику.
> Математика это язык, а программирование это 

дискретная математика :)

> набор не сильно сложных технологий.

Покажите мне, где у Кнута (или Дейкстры) есть что-то кроме математики,
и где там "набор не сильно сложных технологий"?

Может, Вы программирование с быдлокодерством (вот его результат и есть
ни к чему непригодные поделия в духе ROOT) спутали?

Сон разума рождает чудовищ

> ИМХО развлечение для физиков-онанистов.

Нет. Физикам это поделие не нужно и практически _бесполезно_. Но 
понимают это немногие, им просто не с чем сравнивать, они думают, что
любой язык такой же низкоуровневый и эклектичный, как C++, и любая 
библиотека столь же непродумана, как и ROOT. А недостатка в паразитах,
готовых шкуру содрать "з братiв незрящих", никогда не было...

Dselect так как на счёт ntuplов в "правильных" инструментах? - так ничего и не услышал :(

@б вашу мать! И тот, кто постил, и тот, кто подтверждал --- шагом марш в пятый класс на урок русского языка!!!

Читать противно....

> так как на счёт ntuplов в "правильных" инструментах?

Поддержки ntuples, XML и прочего bloatware в SciLab нет. И надо ли?

халявы не будет

> Сделай не кривое - а пока увы и ах.

Значит эти г...оны про%$#ли кучу времени и денег, и родили вот это чучело
(при И.В. они б за него точно сели лет на 10 с конфискацией), а я теперь
должен сделать не кривое? Да еще и на халяву? А как насчет пешего
эротического путешествия?

> Экспериментальный факт: круто то, что работает.

Рассуждения "круто/не круто" -- это уровень подростков из ПТУ. Впрочем,
обсуждаемая поделка -- как раз такого уровня.

А на счет "работает"... Знаете, есть байка такая: дескать сел мужик на
стул, а там гвоздь торчит. Мужик: "Ой, ой, ой... А может, оно так и надо?"

> И тот, кто постил, и тот, кто подтверждал --- шагом марш в пятый класс
> на урок русского языка!!!

А код они еще хуже пишут... Не верите -- скачайте и почитайте. Только
советую валерьянкой заранее запастись...

> так как на счёт ntuplов в "правильных" инструментах?

Таких вопросов я сам могу задать сколько угодно:

1) А как на счет ISO C++ в cint?
2) А как у него дела с STL?
3) А partial template ordering есть?
4) Когда, наконец, можно будет пользовать _обычные_ C++ [shared] библиотеки?
  (без камлания с LinkDef.h и прочей хренью)

Дожились - C++ уже стал низкоуровневым.

> Интегралы брать все умеют -- огромное спасибо Л.Д. Ландау. Вот кто бы еще нашелся, чтоб по программированию ликбез провел.

Есть такие попытки:

http://www.inr.ac.ru/~info21/about.htm

Что из этого выйдет --- пока ИМХО неясно, но намерения благие :-)

Не флейма ради, автор проекта --- физик, и пишет на упомянутом выше Обероне.

--

SVK

> надоело, когда в новостях не пишут назначение програмы

Согласен! Равно как и видеть "ширше", "ширее" и т.д. Хотите извратиться в языке? Вам на Воффку!

Модераторы спят?

To Dselect > Поддержки ntuples, XML и прочего bloatware в SciLab нет. И надо ли?

Как бы тебе объяснить: вот есть у тебя десяток параметров в событии. Простейший пример для космики:

costree= new TTree("costree", "LKr Cosmic events");

costree->Branch("R",&rzpd.R,"R/I:Z/I:Phi/I:Data/I:Hit/D:Si ze/I:Time/I:addr/I:Run/I:eratio/D");

И событий таких на заход около ста тысяч. И хочется тебе нарисовать загрузку в зависимости от Phi и Z для R==1&&Size<1000, дабы понять почему данный заход от тысячи других подобных заходов отличается.

root [0] TFile f("cos006536.root")

root [1] costree->Draw("Phi:Z","R==1&&Size<1000"," lego")

Как понял - дальше можно обработку поставить на автомат, но до этого придётся смотреть глазами.

Обычно параметров сильно больше и условия отбора понавороченней. Если ты придумаешь как делать это проще, то этим, возможно, будут пользоваться. А пока за тобой ничего кроме обычных "пальцев" не замечено. То есть идите и учитесь.

To Dselect

> так как на счёт ntuplов в "правильных" инструментах?

> Таких вопросов я сам могу задать сколько угодно:

> 1) А как на счет ISO C++ в cint?

> 2) А как у него дела с STL?

> 3) А partial template ordering есть?

> 4) Когда, наконец, можно будет пользовать _обычные_ C++ [shared] библиотеки? (без камлания с LinkDef.h и прочей хренью)

1-3 - мне, как человек который с этим работает, на это начхать. Мне нужны инструменты, а не сферические кони в вакууме

4) А в чём проблема? Как это мешает работать с данными? На всякую сборку тратится доли процента от общего времени.

А вот без ntuplов ты захлебнёшься при интерактивном анализе больших объёмов.

> Есть такие попытки:

> http://www.inr.ac.ru/~info21/about.htm

> Что из этого выйдет --- пока ИМХО неясно, но намерения благие :-)

Воз и ныне там -- студентам-физикам программирование не читают вообще,
зато целый семестр посвящен ублюдской поделке ROOT :(

> Не флейма ради, автор проекта --- физик, и пишет на упомянутом выше Обероне.

Софтина (генератор древесных диаграмм), написанная на OCaML:
http://theorie.physik.uni-wuerzburg.de/~ohl/omega/

Так что грамотные люди есть, но их очень мало...

Изобретаем велосипед^W СУБД? А нафиг?

>> 1) А как на счет ISO C++ в cint?

>> 2) А как у него дела с STL?

>> 3) А partial template ordering есть?

> 1-3 - мне, как человек который с этим работает, на это начхать.

О как. Значит, заявки вроде 

> CINT is a C/C++ interpreter aimed at processing C/C++
> scripts. Scripts are programs performing specific tasks. Generally
> execution time is not critical, but rapid development is. Using
> an interpreter the compile and link cycle is dramatically reduced
> facilitating rapid development.

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

> Мне нужны инструменты, а не сферические кони в вакууме

Этот инструмент _ничего_ не умеет.

>> 4) Когда, наконец, можно будет пользовать _обычные_ C++ [shared]
>> библиотеки? (без камлания с LinkDef.h и прочей хренью)

> 4) А в чём проблема? 

Писать с нуля/хакать все C++ либы, так чтоб чудо-инструмент с ними работал
(бо сам он нихрена не может) я не собираюсь, по сему -- ROOT идет в сад, и
остается там как минимум до тех пор, пока для использования библиотек нужны
какие-то лишние телодвижения.

> Как это мешает работать с данными?

> На всякую сборку тратится доли процента от общего времени.

На скриптоложество и хацкерство с C++ библиотеками -- которые прекрасно
собираются компилятором, хоть gcc, хоть icc, но "не нравятся" cint'у --
уходит туева хуча времени.

> А вот без ntuplов ты захлебнёшься при интерактивном анализе больших объёмов.

Возьмите нормальную СУБД и не парьте мозг.

>Писать с нуля/хакать все C++ либы, так чтоб чудо-инструмент с ними работал (бо сам он нихрена не может) я не собираюсь, по сему -- ROOT идет в сад, и остается там как минимум до тех пор, пока для использования библиотек нужны какие-то лишние телодвижения.

У меня вопрос: "Можете перечислить все C++ либы, с которыми не работает ROOT?" При этом хочу уточнить, что ROOT - не единственно CINT, т.е. разделяйте по возможности.

не пойму — плакать или смеяться?

> costree= new TTree("costree", "LKr Cosmic events");

> costree->Branch("R",&rzpd.R,"R/I:Z/I:Phi/I:Data/I:Hit/D:Si
 ze/I:Time/I:addr/I:Run/I:eratio/D");

Хорошая иллюстрация к фразе "физик на любом языке напишет на FORTRAN'е"...

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

Зачем изобретать еще одну СУБД и еще один SQL? Энтузиасты, блин...

> А пока за тобой ничего кроме обычных "пальцев" не замечено.

Я с Вами на брудершафт не пил.

> Хорошая иллюстрация к фразе "физик на любом языке напишет на FORTRAN'е"..

Как бы тебе объяснить: цель не язык - цель физический результат. Поэтому чем меньше надо для этого совершить действий тем лучше. Даже если придётся, как это не страшно, делать это на Fortran.

> Зачем изобретать еще одну СУБД и еще один SQL? Энтузиасты, блин...

Как бы тебе объяснить: СУБД меееедленные, причём сильно и не предназначенные для интерактивной работы.

> У меня вопрос: "Можете перечислить все C++ либы, с которыми не работает ROOT?"

Во-первых,

1) Большинство boost'овских библиотек (http://boost.org/), в частности mpl, 
serialization, graph
2) http://www.oonumerics.org/blitz/
3) http://tvmet.sourceforge.net/
4) http://www.ginac.de/

В общем, практически любая библиотека, использующая шаблоны и STL.

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

> При этом хочу уточнить, что ROOT - не единственно CINT,

А все остальное там -- велосипед.

> т.е. разделяйте по возможности.

Утверждаение состоит в том, что тот язык, который понимает cint -- это
не C++, а какой-то новый язык. И сказки про "стандартизированный язык",
горы софта, на нем написанного,  толпы программистов, его знающих,
сразу идут в /dev/null. На самом деле, ситуация такая: пЫонеры родили 
новый недоязык и теперь _все_ на нем переписывают с нуля. А ЗАЧЕМ?!

> Возьмите нормальную СУБД и не парьте мозг.

PostgreSQL это нормальная СУБД? Сколько она столбцов держит? Какой размер базы по отношению к размеру данных? Какова скорость передачи по сети SQL запросов при получении больших (хотя бы 100000 событий по 1000 параметров) объёмов данных?

>> На всякую сборку тратится доли процента от общего времени.

> На скриптоложество и хацкерство с C++ библиотеками -- которые прекрасно собираются компилятором, хоть gcc, хоть icc, но "не нравятся" cint'у -- уходит туева хуча времени.

Я фигею дорогая редакция - зачем вы всякий хлам в root пихаете? Чего вам там не хватает?

> Как бы тебе объяснить: цель не язык - цель физический результат.

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

> Как бы тебе объяснить: СУБД меееедленные, причём сильно 

1) Такие объяснения следует сопровождать ссылочкой на benchmark, иначе
это демагогия.

2) Ага, а два лихих хлопца из CERN'а, которые и слов "дискретная математика"
не слышали, сели и слабали на коленке такое, что аж летает... в core dump
оно летает...

> и не предназначенные для интерактивной работы.

Ложь.

> Я фигею дорогая редакция - зачем вы всякий хлам в root пихаете?

Вопрос нужно ставить так -- зачем пихать нормальные либы в угребищный
ROOT?

Отвечаю. Мне надоело edit/compile/debug -- думал, что раз есть 
интерпретатор, так дело пойдет быстрее.. Ага, СЕЙЧАС...

> Чего вам там не хватает?

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

Если быстренько... 1) Не могу внятно сказать. 2) Начат в 1996 году. 3) Начат в 2003 году, вырос из Blitz++ (который, кстати, ожил). 4) Начат в 1999 году. По ссылке ниже, команда GiNaC говорит, что CINT работает с GiNaC "out of the box". http://www.ginac.de/TeamProfile.html

ROOT начат в 1994 году. Так что где ещё велосипед...

Но всё, что вы предложили, подходит более для теоретиков, для физики, а не для, условно говоря, тупой обработки данных. Задачи разные, и другие цели преследуются, IMHO. Я как-то просил комплексные матрицы добавить, так мне ответили, что они в hep-ex не очень-то и нужны (не могу возразить), да и если переписывать, то через STL, но никому неохота. Так что под задачи и софт.

> 1) Такие объяснения следует сопровождать ссылочкой на benchmark, иначе это демагогия.

На бенчмарк говоришь. Бенчмарк смотри на рутовском сайте. Если бы ты работал и с root и более менее большой БД, то таких глупостей бы не говорил.

>> и не предназначенные для интерактивной работы.

> Ложь.

Ну, нарисуй мне один столбец с произвольным условием из тысячи столбцов в таблице в сто тысяч строк - зацени тормоза. Я это делать умею и в root и в PostgreSQL. Я это прошёл, так как это было необходимо реально для работы. Сильно сомневаюсь, что вы сумеете это сделать в случае СУБД с налёта, а вот с root вы с этим справитесь за пол дня.

извиняюсь за грамматику - стар стал, пора пользоваться speller,
и за стиль - никак не вырасту из коротких штанишек.

Прошу прощения что вмешиваюсь в столь горячий спор, но у меня несколько вопросов по заюзыванию CINT-а в прикладном софте, например таком как бух-учёт. Он IMHO, идеально подходит для запуска внешних расчётных процедур, как в 1С... Ну а скорость, - какая скорость нужна бух-ру ? :-) Но что-бы это реализовать, мне нужно подцепить к нему либу IscDbc.so из ODBC драйвера FireBird-a, и прикрутить CGI, как в Ch-e из http://www.softintegration.com/. Вопрос: Можно-ли эти (и возможно другие) возможности _вкомпилить_ в CINT, собирая его из сырцов, и если да, то как и где взять сырцы для CGI ?

Удачи !

> Но что-бы это реализовать, мне нужно подцепить к нему либу IscDbc.so из ODBC драйвера FireBird-a

Что-то с БД было, но можно и написать свою библиотечку c необходимыми функциями (ведь не всё же надо), а сборку сделать как-то так

#собираемая shared библиотека
ROOTLIB := $(LIBDIR)/libKDB-root.so
#имя импортируемого класса - необходимы $(DICTCLASS).h
#и $(DICTCLASS)LinkDef.h инклуды
DICTCLASS := kdb-root
#словарик
DICTCXX := $(DICTCLASS)Dict.cxx
#инклуд файл для словарика
DICTH := $(DICTCLASS)Dict.h
#собранный словарик
DICTOBJ := $(TEMPDIR)/$(DICTCLASS)Dict.o

rootlib: $(ROOTLIB)

#сборка shared библиотеки для использование в root-скриптах
$(ROOTLIB): $(LIBFILE) $(DICTOBJ)
$(CMDPREFIX)g++ -shared -o $(ROOTLIB) $(DICTOBJ) $(LIBFILE) -lpq -lcrypt

#сборка словарика
$(DICTOBJ): $(DICTCXX) $(DICTH)
$(CMDPREFIX)g++ -c -fPIC `root-config --cflags` $(DICTCXX) -o $(DICTOBJ)

#генерация словарика
$(DICTCXX): $(DICTCLASS).h $(DICTCLASS)LinkDef.h
$(CMDPREFIX)rootcint -f $(DICTCXX) -c $(DICTCLASS).h $(DICTCLASS)LinkDef.h

-lpq и -lcrypt - для общения с PostgreSQL

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

gSystem->Load("/space/KEDR/stable/lib/libKDB-root.so");

Валерий, здорово. ( :) )

Ты вот что скажи, какого фига под Win32 используется win32gdk ? Что, нельзя было TGWin32 реализовать без этого чуда, напрямую используя WinAPI без промежуточных чудо функций gdk_new_lalalalala ???? Я так понимаю, при Файне так дело и было, зачем же приделали win32gdk? Возникает впечатление, что это сделано просто потому, что кому-то "так удобно" и теперь все от него зависят. Что-то добавить или изменить - гемор, какого черта я должен ковыряться в забористом win32gdk ? Вот у меня недавно проблема возникла, упирается все в win32gdk и мое нежелание ковыряться в нем. Бертран обещал помочь, но воз и ныне там.

ТП