R-package Disgrace

(кто знаком со стандартными графическими функциями R - тот поймет ;)).

еще одна обвязка. была всегда в R возможность "дергать" график и показывать диалоги.

Петров Сергей

Добрый день

А как оно по сравнению с root (root.cern.ch), paw? При быстром просмотре, вроде, похожие задачи решают.

С уважением Евгений

Я верно понимаю, что главная задача для которой создавался R - обработка статистической информации?

Петрову- Я не знаю о такой возможности. Да, можно перерисовать график с нуля, но в том или ином виде "объектного" подхода к рисованию графиков в R не существовало (до того как стали использовать grid и основанный на нем lattice). Те для того чтобы сделать zoom нужно затереть весь предыдущий график, а потом снова вызывать plot с соответствующим x/ylim.
Евгению и anonymous. Да, создателями R позиционируется как система для статистической обработки данных (может быть они считают что ее так легче продвигать). Соответственно, в пакетах которые делаются под R есть некоторый перекос (на мой взгляд) в сторону исключительно статистических методов. Например, такого пакета с помощью которого можно было бы анализировать линейные динамические системы (те ПИД контроллеры) - там нет (в отличие от того же Матлаба, где таких библиотек штук три). В то же время R сейчас активно начинают осваивать биологи (пакет bioconductor - в ИМБ РАН судя по mail-list есть пользователи).
Достоинства (плавно переходящие в недостатки) по-сравнению с root/paw - более высокоуровневый язык и более функциональный синтаксис. Честно говоря, от root у меня впечатления самые отрицательные (глюкавость, падучесть, дурацкий toolbox - ИМХО), а с paw - ... Ничего плохого сказать не могу, но в Фортране я весьма слаб.
В стандартном R (к grid это не относится) стараются избегать external pointers и side-effectов - фунции получают данные через параметры и возвращают через return values. Есть gc. Те какие-то элементы функционального подхода имеются. Есть довольно забавная объектная модель - сделанная через closures (environments). Грубо говоря, любая функция является объектом. Классов как таковых нет (хотя сейчас пытаются привить более привычный с++-like синтаксис - пакет methods).
В то же время эта создает оверхеды на скорость выполнения/использование памяти. Кроме того R (пока) чисто скриптовой язык (хотя разработчики поговаривают о том что неплохо бы приделать к нему возможность компилировать в байт-код). Однако это тоже не проблема если критичные участки кода делать в Fortran-e,C. R очеь хорошо интерфейсится с ними (c С++ - туго). Если по ссылке подняться на уровень вверх - то там лежат 2 пакета с портами фортрановских библиотек из Октавы. Порт в одном случае состоял в написании враппера на R, в другом (где потребовался вызов R функций из фортрановской библиотеки) еще дополнительно thunk-а на C.

надо применять стандартное оформление диаграмм и нечего в них ковырятся ;)

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

ПС

кстати простой зом вообще не проблема (в известных пределах, у Вас особенно удобно кстате). просто "растяните" то что R вывел хоть во весь виртуальный рабочий стол, чай не в винде... ;))

R -- это чень удобный для решения вычислительных задачек язык + библиотека методов (в основном статистических, но линейная алгебра, fft и много другого тоже есть) + неплохая визуализация (опять же со статистическим уклоном). Использовал его с удовольствием, пока не столкнулся с проблемой: очень расточительно расходует память. Например, когда нужно что-нибудь сделать с большим количеством данных (50М, профитить наименьшими квадратами), R отжирает 500М или больше. Рылся в документации, но проблему эту решить не смог. Octave такого не делает, потому его и использую, хотя графика в нём бедная.

Немного про вычислительные системы. Языки типа R или octave идеальны для научных вычислений: количество циклов, условных переходов и других конструкций в программах на этих языках можно сделать минимальным. Есть у них один недостаток: нельзя скомпилировать в машинный код, поэтому большие модели считать невозможно. Приходится использовать фортран 90/95, но этот язык недостаточно высокого уровня для научных вычислений, к тому же обладает рядом других недостатков (плохая совместимость между компиляторами различных фирм, отсутствие свободного компилятора и т.д.).

Очень хотелось бы иметь хорошую C++ библиотеку заточенную под вычислительные цели: чтоб массивы определялись как непрерывный кусок данных в памяти, а не как указатель на указатель на указатель на ...; чтоб можно было задавать начальный индекс отличный от нуля; чтоб можно было задавать интервалы (x[N1:N2,M1:M2]=val); чтоб можно было задавать массивы индексов (x[массив]=val); чтоб можно было перебирать элементы массивов циклически (при размере массива N обращение к элементу N+k давало бы элемент k); чтобы были векторные версии всех мат. функций (sin,cos,sqrt, и т.д.); чтоб был интерфейс для всего этого к lapack и другим библиотекам алгоритмов; чтоб была графическая библиотека. На C++ всё это можно реализовать.

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

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

Добрый день

Не совсем понял, что вам надо, но может быть это подойдёт?

http://proj-clhep.web.cern.ch/proj-clhep/

Для анализа, когда скрипт можно после отработки собрать программу root вполне адекватен (root.cern.ch)

С уважением Евгений

Добрый день

Спасибо за объяснение, может быть гляну попристальней. Приятно, что это GNUсный проект и если он выживет, то превратится в полезный инструмент.

По поводу root я согласен что GUI там никакой. GUI там пользовать и не надо. То что он там прилеплен - это дань моде не более того, а вот вычислительный код и идеи были взяты из cernlib/paw, поэтому с этим пакет вполне можно работать, но, боже упаси вас, никакого GUI :).

Чем хороши paw и root, что они могут работать с огромными объёмами данных: ntuple в два миллиона записей не является чем-то особенным и вполне поддаётся анализу на писюке средней паршивости.

С уважением Евгений

P.S. И лицензия у root не GNUcная - что, конечно не является особой проблемой, но возникают некие опасения на развитие в будущем.

Глянь на http://www.boost.org. Там что-то намутили на математические темы.

А если охота избавиться от указателей - STL. Со всеми современными C++. Не знаю как для вычислительных затач - а для алгоритмических - есть почти всё, что надо

Evgueni, adarovsky

спасибо

2Evgueni

Ну не совсем и "никакой" уж GUI в ROOTe.

очень удобный для подключения в C++ код.

Я тут вчера спровоцировал полемику в R-help мэйл-листе на тему что такое R в смысле его классификации. Ответов достаточно много - можете посмотреть там или через некоторое время этот тред на своем сайте размещу.
Вот, например:

Basically, R is an implementation of the S language, changed in a couple
of faiyl modest languages.

If it weren't for the fact that S allows variables to be added to, removed
from, and renamed in stack frames during execution, it would _almost_ be a
functional language wearing an imperative mask. R doesn't let stack frames
(also known as activation records) to be changed like that, and uses
lexical scoping instead of the rather odder rule that S uses.

S is a dynamically typed language, in the spirit of APL and Lisp.
(Or of Matlab/Octave)

As for lazy evaluation, S is a rather weird hybrid. When you call a
function, the arguments are bound to "promises" (basically a triple of
expression parse tree, evaluation environment, and cached value if known)
which is just like lazy evaluation except for making the parse tree
available as well. However, assignment to variables is always strict;
if you assign to a local variable you know that its value is NOT a promise.
R has preserved this feature of S, which is actually rather important to
the way S is used.

и так далее в том же духе.

yvv (*) (2003-07-17 00:48:40.755165)
>> чтоб массивы определялись как непрерывный кусок данных в памяти, а не как указатель на указатель на указатель на ...;

matrix в R именно так и хранится - columnwise как в Фортране.

>>>Например, когда нужно что-нибудь сделать с большим количеством данных (50М, профитить наименьшими квадратами), R отжирает 500М или больше. Рылся в документации, но проблему эту решить не смог. Octave такого не делает, потому его и использую, хотя графика в нём бедная.

А подумать?

?lm.fit
...Value:

a list with components

coefficients: `p' vector

residuals: `n' vector

fitted.values: `n' vector

effects: `n' vector; ......

weights: `n' vector - only for the `*wfit*' functions.

rank: integer, giving the rank

df.residual: degrees of freedom of residuals

qr: the QR decomposition, see `qr'.
...
Итого, как минимум, линейная подгонка (y~a1*f1(x)+...+am*fm(x)) создает по 3*m вектора длиной 50М. Так что 500М еще не предел
Предложение подумать заключается в следующем-
На самом деле данные можно порубить на Z кусков гораздо меньшей длины и проделывать линейную подгонку на каждом из этих участков. Затем пользуясь полями qr и coefficients восстановить Y_ls и X_ls. И так для каждого куска. Коеффициенты для всей кривой уже можно найти решая систему mxm (Y_ls_1+...+Y_ls_Z)=(X_ls_1+...+X_ls_Z)*coeffs. При желании можно распараллелить (пакеты для pvm mpi в R имеются).
С нелинейной подгонкой (y~a1*f1(x,c1,...,ck)+...+am*fm(x,c1,...ck)) несколько хуже но не намного. Разделять на участки также можно - вычислять a1-am и из них вычислять ошибку и передавать результат на следующую итерацию поиска с1...ck.

2 geekkoo:

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

>> matrix в R именно так и хранится - columnwise как в Фортране.

Вот-вот, именно. А в C они хранятся не так, поэтому R больше подходит для научных рассчётов чем C, жаль только его в машинный код компилировать нельзя. >> А подумать?

Само собой ...

lm методы встроенные в R отпали сразу т.к. требуют гораздо больше 500М (они хранят кучу всякой информации). QR декомпозиция делалась вручную (т.е. использовался встроенный QR метод). Но это не столь важно, 200М отжирается уже при чтении данных (50М) в память.

Разбиение данных на куски и решение N задач работает, если структура данных позволяет это сделать. Например, если есть множество точек в пространстве, параметр в которых меняется со временем, можно его профитить в каждой точке. Однако не любая задача позволяет разбить данные на какие-то логические куски. А конечный результат будет зависеть от способа разбивки.

Рациональное раходование памяти (как в octave) позволяет избежать этого гемороя. Хотя как язык программирования мне R больше нравится. Если бы он ещё и компилировался...

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

Петров Сергей

PS R хорош мощным синтаксисом позволяющим в пару строчек запихать сложный алгоритм статрасчетов по практически любой проблеме. мощность по объему обрабатываемых "в лоб" данных скорее всего просто стояла на втором месте.

Вот попробовал на своем PIII/196MB поработать с большими векторами-
вроде бы все честно, если учесть что Vcell в R занимает 8 байт.
Массив из 6М элементов типа double занимает 46МБ, простые операции с ним (умножение, передача в качестве параметра в функцию) к дополнительному расходу памяти не приводят
> mem.limits(1000000,150000000)
nsize vsize
1000000 150000000
> gcinfo(T)
[1] FALSE
> gc()
used (Mb) gc trigger (Mb) limit (Mb)
Ncells 205228 5.5 407500 10.9 26.8
Vcells 40339 0.4 786432 6.0 143.1
> l<-seq(1,3000000,0.5)
Garbage collection 3 = 0+0+3 (level 2) ...
202197 cons cells free (49%)
24.9 Mbytes of heap free (98%)
Garbage collection 4 = 0+0+4 (level 2) ...
202198 cons cells free (49%)
47.7 Mbytes of heap free (67%)
Garbage collection 5 = 0+0+5 (level 2) ...
202197 cons cells free (49%)
47.7 Mbytes of heap free (40%)
Garbage collection 6 = 0+0+6 (level 2) ...
202200 cons cells free (49%)
71.4 Mbytes of heap free (60%)
> length(l)
[1] 5999999
> gc()
used (Mb) gc trigger (Mb) limit (Mb)
Ncells 205242 5.5 407500 10.9 26.8
Vcells 6040344 46.1 15398409 117.5 143.1
> l<-l*2
> gc()
used (Mb) gc trigger (Mb) limit (Mb)
Ncells 205242 5.5 407500 10.9 26.8
Vcells 6040343 46.1 15398409 117.5 143.1
> q<-function(x){x*3}
> l<-q(l)
> gc()
used (Mb) gc trigger (Mb) limit (Mb)
Ncells 205255 5.5 407500 10.9 26.8
Vcells 6040349 46.1 15398409 117.5 143.1
> k<-q(l)
> gc()
used (Mb) gc trigger (Mb) limit (Mb)
Ncells 205257 5.5 407500 10.9 26.8
Vcells 12040348 91.9 15498784 118.3 143.1

2geekkoo Опа!!! А похоже garbage colection это как раз то что нужно... Я и не знал, что вручную вызывать нужно (в доках этого нет :( ).

В любом случае, спасибо за подсказку.

Вообще-то, я gc() применял просто, чтобы показать расход памяти. gc на самом деле автоматически вызывается, когда будет использовано количество памяти большее, чем указано в колонке trigger (этот параметр как раз и настраивается с помощью mem.limits). В R, впрочем, еще такая функция есть как gctorture, которая вызывает garbage collector после каждой операции с памятью. Думаю не нужно объяснять, почему она так называется ;).
А самая классная документация для R - это r-help mail-list. Народ там (среди которых полно core developers) весьма лояльный и rtfm-ится посылают крайне редко и то в экстренных случаях.

а если все такие умные и гордые :)

Есть ли бесплатный пакет для численного решения интегральных уравнений. Хотелось проверить решение, а сходу готового не находится.

Петров Сергей

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

очень устал исправлять "опечатки и неточности" в листингах Верланя и Сизикова.

Петров Сергей