Вышла новая версия пакета для статистической обработки данных R-2.6.0

>>В ROOTe не помешало бы иметь нечо подобное.

Только буква R уже занята.

the last off-topic

>> но зрелище весьма жалкое

> поклонник рющечек?

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

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

>>в ROOTe модуль - это тоже динамическая библиотека

Я как раз пытался объяснить, что R модуль это _НЕ_ динамическая библиотека, а смесь R-скрипта и подгружаемой библиотеки.

>>Возможно ли убедить авторов пишущих R модули, "переписать"
их под ROOT.

На С++? Для этого нужно обладать очень хорошим даром убеждения.

> На С++? Для этого нужно обладать очень хорошим даром убеждения.

Должна быть ещё веская причина :)

> На С++

на C, заменяя, где надо "конструкции языка" оьектами.

IMHO, ROOT надо создавать своё комьюнити. Чтобы подключить чей-то "багаж" нужно изначально работать в рамках этого проекта. Выбрали бы не C++, а R в качестве основного языка ROOT было бы сейчас не догнать.

> как подключиться к процессу?

Можно написать мне на dactylorhiza на гмыло.

===

С уважением, А.Ш.

если только из-за Emacs+ESS, то не стоило. Эта связка замечательно работает и под оффтопиком (не то, чтобы агитирую :) )

Ставить замаешься - не из коробки оно там.

> не C++, а R в качестве основного языка ROOT было бы сейчас не догнать

это не так, конечно. Очевидно, Вы не_до_понимаете приемущества C/C++
в качестве скриптового языка (пример ниже).
на настояший момент ROOT включает в себя пакет TMVA
(написанный статистиками)
http://root.cern.ch/root/html/TMVA_Index.html
http://tmva.sourceforge.net/
который во многом превосходит R аналоги.
А вот и "графика" к нему
http://hyperon.ihep.su/~onuchin/CHEP_2007_Graphics.ppt
(см. паралельные координаты, и это только начало).
Конечно, хотелось бы иметь нечто подобное по
регрессионному анализу и time series и пр. вещам.

А теперь перейдем к примеру.
Тут от кого-то когда-то звучала усмешка "это тот,
который использует C++ для вращения матриц"

IMHO, как раз C++ наиболее подходящий для этого язык.
В R операции с матрицами - есть элементы языка.
В ROOTе, TMatrix - это класс.
И операции с матрицей - это методы этого класса.
Существует огромное количество подклассов матриц :
Hilbert, Haar симметричные, несимметричные, сингулярные и пр.,
а также великое множество алгоритмов их декомпозиции,
перемножения и пр.

В ROOTе все делается естественно - через наследование и
method overloading.
Если кто-то находит более лучший метод обращения
для какого-то типа матриц - он просто создает новый класс
class MyTheBestMatrix : public TMatrix
и overload метод Invert

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

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

не понял данное утверждение

> IMHO, ROOT надо создавать своё комьюнити
http://root.cern.ch/root/images/ftpstats2.gif
http://root.cern.ch/root/images/ftpstats.gif

~ 500 000 downloaded binaries

интересно узнать анaлогичные данные по R

>>включая LAPACK

LAPACK LAPACKу рознь. Базовый LAPCK не оптимизирован. Обычно поверх него накатывают ATLAS - он заметно быстрее получается. R при компиляции можно указать использовать ли встроенный базовый LAPACK (и BLAS в том числе) или внешний ATLAS.

>>500 000 downloaded binaries

А uploaded? Именно по этому параметру можно судить о наличии сообщества, а не банки пиявок.

> ATLAS - он заметно быстрее получается
на сколько я понимаю, что сейчас mainstream -
это параллельные алгоритмы использующие возможности
многоядерных процессоров.
Как в R собираются отслеживать эту "тенденцию"?
Как я говорил, в ROOTe любой пользователь может "подставить"
свой собстевенный алгоритм вращения или перемножения матриц,
ничего не меняя в "основе" языка.

Отвечу честно - не знаю.
Может быть вот так - http://www.lrz-muenchen.de/services/software/mathematik/scalapack/ ?

http://cran.r-project.org/src/contrib/Descriptions/RScaLAPACK.html

>> не C++, а R в качестве основного языка ROOT было бы сейчас не догнать

>это не так, конечно. Очевидно, Вы не_до_понимаете приемущества C/C++

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

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

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

> не понял данное утверждение

Чтобы воспользоваться расширениями R надо было n лет назад выбрать его в качестве языка проекта. У paw одна из основных слабостей - различные языки для интерактива и для написания скриптов. У ROOT эту слабость убрали, но выбрали на редкость неудобный для ведения анализа язык, который фактически свёл основную фишку paw "интерактивный анализ" к нулю. Причём это было, на сколько я понял из Ваших же слов, сделано по "идеологическим" причинам.

Кстати, это, похоже, какая-то городская легенда, что LAPACK не thread-safe. Я в этом тоже был практически уверен, но после непродолжительного гугления стало выясняться, что в последнее время ситуация значительно изменилась. Тут вот http://www.mhpcc.edu/training/workshop/parallel_libs/MAIN.html#lapack вообще утверждают, что для LAPACK -

Target Machines

* Vector processors

* Shared-memory multi-processors

Кроме того, мне вообще не нравится подход давать пользователю удочку, вместо рыбы (говорю это как пользователь), т.е. дать возможность пользователю переопределять матричное умножение доморощенными процедурами мне не кажется правильным. Тем более, что BLAS-LAPACK - это практически "glibc" для матричных вычислений. Нужно быть очень наивным, чтобы думать, что реализация алгоритма быстрого поиска у конечного пользователя получится удачнее, чем у Ульриха Дреппера.

>> IMHO, ROOT надо создавать своё комьюнити

> ~ 500 000 downloaded binaries

>интересно узнать анaлогичные данные по R

Почти в каждом дистрибутиве GNU/Linux есть R Сколько там Ubunty разослали?

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

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

уууух, погналл оффтопик ...

>Ориентация на программистов, а не на тех кто этот инструмент использует >это всегда плохо.

100% согласен, поэтому мы "развиваем" так называемые "editors"
http://root.cern.ch/root/html/GED_Index.html,
которые позволяют кликаньем мышки допиться необходимого
результата

>Не - оно работает как-то и даже как-то развивается, >но всеобъемлющим >это решение не будет никогда, потому что отсутствуют >вменяемые >механизмы добавить своё рабочее расширение для специалиста

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

root[].L my_script.C++
который создает DLL my_script._C.so, и которая, и есть расширение

>и просто отвратительная документация.

отчасти согласен.

>Причём последнее IMHO не изменится >никогда,

есть полное понимание этой проблемы и делаются шаги в исправлении
ситуации. Кстати, "Ваш покорный слуга" :) написал html widget,
http://root.cern.ch/root/html/TGHtml.html
который позволяет парсить и отображать html страницы.
И это первый шаг к online-help.
Заметим, с 2005 года, вся моя деятельность в ROOTe -
чисто альтруистская, которая занимает достаточно
много времени и сил. Деньги мне за разработку и поддержку ROOTa,
к сожалению, не платят.

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

см. предыдущий ответ. Я не вижу проблем в реализации
поддержки русского языка (UTF8/unicode) в ROOTe,
также как и перевести документацию -
все упирается во время (свободное от основной работы)
и деньги (не хочется делать это "забесплатно").

> Ваших же слов, сделано по "идеологическим" причинам.

я говорил, что достаточно легко (1-4 недель моей работы),
к существующему ROOT добавить PAWшные команды,
потому что PAWшный парсер (KUIP) существует и написан на C,
а >90% команд PAW транслируютя в ROOT.
На мое предложение, я получил "указание" не делать этого.
Основные доводы против сводились к "идеологическим соображениям"

> Почти в каждом дистрибутиве GNU/Linux есть R Сколько там Ubunty разослали?

не на 100%, но слышал ROOT, что включили в Debian

>>Я не вижу проблем в реализации поддержки русского языка (UTF8/unicode) в ROOTe

Валерий, вы как-то года 2 или даже три назад, тоже на ЛОРе спрашивали своего оппонента, как он хочет, чтобы была реализована поддержка русского в root-е через pango или "как в KDE". Видимо эта диллема так и осталась неразрешимой.

>поддержка русского в root-е через pango или "как в KDE".

все гораздо проще - средствами X11 & win32 API.
Конечно, хотелось бы иметь также что-то типа QtLinguist ..

> не на 100%, но слышал ROOT, что включили в Debian

В Etch нет, в Lenny похоже тоже. Но со временем, естественно, будет. ROOT чуть не упустил эту возможность.

>Возможно ли убедить авторов пишущих R модули, "переписать" их под ROOT. На сколько я понял, отношение R-собшества к ROOT по крайней мере скептическое.

Невозможно. Возможности убогонького недоязычка C++ и рядом не валялись с тем, что умеет делать R. Отношение не скептическое, а объективно-брезгливое.

> уууух, погналл оффтопик ...

IMHO не офтопик - это обсуждение отличий в модели развития.

>>Ориентация на программистов, а не на тех кто этот инструмент использует это всегда плохо.

> 100% согласен, поэтому мы "развиваем" так называемые "editors" http://root.cern.ch/root/html/GED_Index.html, которые позволяют кликаньем мышки допиться необходимого результата

Вот что мне всегда не нравилось в ROOT больше чем его документация, так это "editors". Это IMHO камень на пути автоматизации. Такие "костыли" в перспективе только усложняют и увеличивают время на анализ. Хотя позволяют занимать время "работой". IMHO, естественно.

>> Не - оно работает как-то и даже как-то развивается, но всеобъемлющим это решение не будет никогда, потому что отсутствуют вменяемые механизмы добавить своё рабочее расширение для специалиста

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

> root[].L my_script.C++ который создает DLL my_script._C.so, и которая, и есть расширение

Я в курсе как это делается. Это не то. Это свалка своих пользовательских функций, а не расширение.

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

>>и просто отвратительная документация.

>отчасти согласен.

>>Причём последнее IMHO не изменится >никогда,

>есть полное понимание этой проблемы и делаются шаги в исправлении ситуации. Кстати, "Ваш покорный слуга" :) написал html widget, http://root.cern.ch/root/html/TGHtml.html который позволяет парсить и отображать html страницы. И это первый шаг к online-help.

Это к сожалению опять же не то, хотя это лучше чем отсутствие документации вообще (я не в коем случае не умоляю Ваши достижения). В случае ROOT проблема подкрадывается со стороны классов, которые делают документацию "разорванной". Непрерывность отсутствует "ny designe".

> Заметим, с 2005 года, вся моя деятельность в ROOTe - чисто альтруистская, которая занимает достаточно много времени и сил. Деньги мне за разработку и поддержку ROOTa, к сожалению, не платят.

Верю. И IMHO плохо, что так получилось. Централизованное развитие ушло вместе с финансированием, а распределённая разработка так и не поднялась.

В пору новый ROOT начинать, например, на основе R :) - добавить туда эффективные ntuplы (в большинстве случаев достаточно просто ntuplов) и, уверяю вас, много людей уйдёт с лёгкостью в этом направлении с ROOT.

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

> см. предыдущий ответ. Я не вижу проблем в реализации поддержки русского языка (UTF8/unicode) в ROOTe, также как и перевести документацию - все упирается во время (свободное от основной работы) и деньги (не хочется делать это "забесплатно").

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

>> Ваших же слов, сделано по "идеологическим" причинам.

> я говорил, что достаточно легко (1-4 недель моей работы), к существующему ROOT добавить PAWшные команды, потому что PAWшный парсер (KUIP) существует и написан на C, а 90% команд PAW транслируютя в ROOT. На мое предложение, я получил "указание" не делать этого. Основные доводы против сводились к "идеологическим соображениям"

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

>которые позволяют кликаньем мышки допиться необходимого

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

>к существующему ROOT добавить PAWшные команды

Это не поможет, поскольку язык PAW довольно убог и является по сути просто набором команд. R -- это смесь APL и Scheme (я имею ввиду семантику, а не синтаксис).

>Если кто-то находит более лучший метод обращения

В R ecть ООП, не такое, как в C++, но оно есть. Для примера можно посмотреть на реализацию пакета Matrix. http://cran.r-project.org/src/contrib/Descriptions/Matrix.html

>>к существующему ROOT добавить PAWшные команды

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

Не "просто набором", а "набором удобных команд". Сеё есть принципиально разные вещи, тем более в paw есть два языка не считая SIGMA. Не к тому, что KUIP идеален, а к тому, что он вполне достаточен для многих процедур, хотя очень плохо, что он не развивался.

anonymous (*) (07.10.2007 21:13:19) - а ведь если бы вы написали только:

------- > Очевидно, Вы не_до_понимаете приемущества C/C++ в качестве скриптового языка (пример ниже).

Их нет. Ни одного. C++ - отвратительный скриптовый язык. ------

Было бы всё нормально. Или сказали, что мол собеседник не слушает аргументов, а так, что называется "люди жалуются".

> а о том, что С++ слишком многословен для интерактивной

"великий и могучий" тоже очень сложный язык, однако
желающие могут обходиться 20 словами. То же про C++,
ну, если сложный он для вас - "говорите на C", который проще, чем R.

думаю, самая наболевшая проблема в ROOTe - это документация,
точнее отсутствие системы позвляющей пользователям находить
"ответы на достаточно простые вопросы" и online help.
btw, главная "жертва" всего этого сами разработчики ROOTa,
и в первую очередь сам Rene Brun, который тратит
огромное количество времени отвечая на бесконечно_повторяющиеся
одни и те же вопросы.

Система должна быть расчитана на несколько уровней
пользователей и должна быть "самораскывающейся" , "что-то типа google". + learning by excesize.

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

Несомненно, необходимо "как-то спрятать" от anonymousов
лишние подробности и восможности языка и системы.
20-50 команд (не больше, чем в PAW), однокликовых действий -
это все, что нужно 70% people (к сожалению, им другого в жизни не дано).
Необходимо, и это в процессе, реструктуировать систему,
оставив минимум классов. Все остальное "on demand'.
См. программную речь Rene на CHEP2007

Необходимы, аналоги CPAN, wiki и "distributed community"

Необходима локализация.

> и документации (очень важно)

см. http://root.cern.ch/root/html/THtml.html -
это лучшее, чем то, что я когда-либо видел (на пример, Doxigen).

К сожалению, у разработчиков н ехватает времени на документацию.
IMHO, в нормальном проекте необходимо держать несколько тестеров
(я думаю 1.5-2 на 1 разработчика) и документалистов ...
про промоутеров и манагеров - я не говорю :)

> Возможности убогонького недоязычка C++ и рядом не валялись

узнаю профессора :)

>ну, если сложный он для вас - "говорите на C", который проще, чем R

Многословный != сложный. Ассемблер очень прост, например. Но никто не пользуется им без особой необходимости. Причина проста --- слишком много писанины для выполнения довольно примитивных действий.

>> и документации (очень важно)

> см. http://root.cern.ch/root/html/THtml.html - это лучшее, чем то, что я когда-либо видел (на пример, Doxigen).

Мне так казалось, что я достаточно внятно сказал, что это скорее пример как не надо делат документацию. У perl с его примитивной pod-документации ситуация много лучше.

> К сожалению, у разработчиков н ехватает времени на документацию.

Тогда эти разработчики просто работают в пустую. Следует это понимать.

> Несомненно, необходимо "как-то спрятать" от anonymousов лишние подробности и восможности языка и системы. 20-50 команд (не больше, чем в PAW), однокликовых действий - это все, что нужно 70% people (к сожалению, им другого в жизни не дано).

"Однокликовые" люди не нужны. Я серьёзно. Не нужно ориентироваться на идиотов, потому что в этом случае инструментов сможет пользоваться только полный идиот. ROOT позиционируется как профессиональный инструмент и он должен быть удобен для профессионалов, а не для программистов и не для "однокликальщиков".

> Необходимо, и это в процессе, реструктуировать систему, оставив минимум классов. Все остальное "on demand'. См. программную речь Rene на CHEP2007

Во первых для того чтобы смотреть лучше ссылку дать (нет желания исследовать где это и как лежит), во вторых ROOT это IMHO не поможет. Выход - прикрутить ntuplы к R (кроме шуток).

>лучше ссылку дать
http://indico.cern.ch/materialDisplay.py?contribId=275&sessionId=28&a...

>Выход - прикрутить ntuplы к R (кроме шуток).

Здравая идея, я думаю энтаплы в стиле PAW вполне могут быть прикручены. Когда я говорил, что мне нравится рассматривать гистограммы в R, я имел ввиду не стандартную реализацию, а самодельную (гистограммы в стиле PAW) на основе векторов, которую я сделал, потратив один вечер. Тогда я и осознал всю мощь языка R. Понятно, что для массового использования она не годится,но тем не менее базовые операции (cuts,+,-,*,/,fit,rebin,plot) были реализованы (заняло это всего около 200 строк) и свою задачу я тогда на основе этого дела решил. Жалко нет времени серьезно этим заняться.

> если только из-за Emacs+ESS, то не стоило. Эта связка замечательно работает и под оффтопиком (не то, чтобы агитирую :) )

Как то мне пришлось своп в машинке добавлять до 2 гиг когда я попытался посчитать данные одного асутп. Сейчас разве виндовс версия преодолела ограничение на размер виртуальной памяти?

> на настояший момент ROOT включает в себя пакет TMVA (написанный статистиками)

вы давно не смотрели на R :) там появилась оболочка для датамининга, все что написано в описании TMVA она делает.

> Выход - прикрутить ntuplы к R (кроме шуток).

зуб даю (С) блин хоть и жалко ...

все что не хватет R это возможность работать с огромными матрицами/дата фреймами не средствами виртуальной памяти ОС.

>Выход - прикрутить ntuplы к R (кроме шуток).

благодаря C++ итерпретатору в ROOTe реализован
"автоматический streamer" (aka automatic serialization),
т.е. для любого класса автоматически генерится read/write методы.
Это позволяет писать/читать обьект(иерархию обьектов)
в файлы в системно_независимом бинарном формате, aka ROOT I/O.
ntulplы, trees реализованы на основе этого.
Не знаю, возможно ли нечто подобное в R.

> Жалко нет времени серьезно этим заняться.

Выложить под открытой лицензией с кратким описанием и сообщить в списке рассылки. Я не думаю, что это много времени займёт. За основу вряд-ли, естественно, возьмут, но идею я думаю подхватят.

>> Выход - прикрутить ntuplы к R (кроме шуток).

>все что не хватет R это возможность работать с огромными матрицами/дата фреймами не средствами виртуальной памяти ОС.

На самом деле проще всего реализовать ntuple в виде расширения на С с необходимым набором операций. Возможно, это менее гибко, но если хочется выжать из компьютера все что можно, то о гибкости (на уровне манипулирования собственно всем энтаплом) надо забыть. Бесплатный сыр только в мышеловке :). Тем не менее манипуляции с различного рода выжимками (типа гистограмм, построенных из энтапла) можно без особого ущерба реализовать прямо в R и получить все преимущества от этого.

> т.е. для любого класса автоматически генерится read/write методы.

Ну и нафига это? Нужны ntuplы, а не read/write методы для классов. Это пример абсолютно ненужной универсальности :(

> Не знаю, возможно ли нечто подобное в R.

Через ROOT почему бы нет. ROOT ведь свободен - вот и можно его задействовать для доброго дела :)

> 2Evgueni
какие впечатления от "программной речи"?
http://indico.cern.ch/materialDisplay.py?contribId=275&sessionId=28&a...