Я работал над несколькими пакетами R для некоторых общих инструментов, которые в настоящее время недоступны в R: блоги, доставка отчетов, ведение журнала и планирование. Это заставило меня задаться вопросом: каковы самые важные вещи, которые люди хотят в R, которые в настоящее время недоступны?
Моя надежда состоит в том, что мы можем использовать это, чтобы выявить некоторые пробелы и, возможно, работать на них совместно.
Я бывший наркоман Mathematica, и одна вещь, которую я очень скучаю, это интерфейс стиля ноутбука. Когда я проводил исследования с помощью ноутбуков, бумаги писали бы сами, как и мой анализ. Но теперь, когда я использую R, я считаю, что документирование моей работы было довольно утомительным.
Для людей, которые не знакомы с Mathematica, у вас есть документы, называемые "ноутбуками", которые могут содержать код, текст, уравнения и результаты выполненного кода (которые могут быть уравнениями, текстом, графикой или интерактивными инструментами). Все может быть аккуратно организовано в стилизованные подразделы или разделы, которые сжимаются. У вас может быть несколько открытых документов, которые интегрируются с одним общим ядром.
В то время как я не думаю, что полномасштабный интерфейс стиля Mathematica совершенно необходим, некоторая интерактивная система документов, которая поддерживала бы текст (для описания), код, вывод кода и выход встроенного изображения, была бы настоящим благом для исследователей.
В реальном времени R-пакет был бы моим выбором, возможно, используя C Streaming.
Также мне нужен более надежный пакет веб-разработки. Ничего такого масштабного, как Ruby on Rails, но немного лучше, чем Sweave в сочетании с R2HTML, который может работать на RApache. Я думаю, что это должно быть большой областью внимания для R в целом.
Я понимаю, что LaTeX - лучшая разметка для определенных академий, но в целом я думаю, что HTML должен быть языком разметки выбора. Больше нужно делать с точки зрения R Web Apps, поэтому приложения могут размещаться на огромной ОЗУ удаленно, а R может использоваться для приложений данных SaaS и других графических решений.
Интерфейсы к любой из новых фальсифицированных баз данных "Web 2.0", в которых используются пары "ключ-значение", а не стандартная RDMS. Неисчерпывающий список (в алфавитном порядке) будет
и, конечно, было бы неплохо, если бы у нас была абстракция DBI. Джефф начинал с RBerkeley, но использовал бэкэнд Oracle BerkeleyDB старшей школы, а не одну из этих новых вещей.
Устройство вывода, которое создает код Javascript, возможно, используя библиотеку протовиз.
как программист и писатель библиотек для коллег, мне определенно не хватало пакет протоколирования, я googled и спросил вокруг, здесь тоже, а затем написал один сам. он находится на r-forge, здесь, и он называется "logging":)
Я использую его, и я, очевидно, все еще его разрабатываю.
Естественный интерфейс к платформе .NET был бы потрясающим, хотя я подозреваю, что это может быть большой проблемой.
EDIT: Выделение синтаксиса изнутри RGui также будет замечательным.
ДРУГОЕ ИЗМЕНЕНИЕ: R.NET теперь существует для интеграции R с .NET.
Существует несколько библиотек для взаимодействия с базой данных в целом, и нет библиотеки ORM.
RMySQL полезен, но вы должны писать SQL-запросы вручную, и нет способа их генерировать, как в ORM. Morevoer, он специфичен только для MySQL.
Еще один набор библиотек, который R еще не имеет, для меня это хорошая система для чтения аргументов командной строки: есть R getopt, но это ничего не значит, например, argparse в python.
A FRAQ для FRedently Asked Questions, a la fortune(). R-help будет так весело: "Попробуйте это, library(FRAQ); faq("lattice won't print") и т.д.
A wiki, который добавляет вики-подобную документацию в пакеты R. У вас есть подкаталог inst/wiki с текстовыми файлами в markdown, asciidoc, текстиль, со встроенным R-кодом. При правильном заклинании эти файлы будут выполнены (подумайте brew и/или asciidoc), а соответствующий вывод будет загружен в данный репозиторий онлайн (github, googlecode и т.д.). Другая функция может помочь синхронизировать изменения, сделанные онлайн, обычно с помощью svn или git.
Неожиданно у вас есть вики-документация для вашего пакета с воспроизводимыми примерами (может даже быть привязана к R CMD check).
EDIT 2012:
... и теперь пакет knitr сделает этот процесс еще проще и более аккуратным
Я хотел бы видеть возможность встраивания другого языка программирования в R более простым способом пользователями. Я приводил это в качестве примера в некоторых реализациях common- lisp, которые могли бы написать функцию со встроенным кодом C следующим образом:
(defun sample (x)
(ffi:c-inline (n1 n2) (:int :int) (values :int :int) "{
int n1 = #0, n2 = #1, out1 = 0, out2 = 1;
while (n1 <= n2) {
out1 += n1;
out2 *= n1;
n1++;
}
@(return 0)= out1;
@(return 1)= out2;
}"
:side-effects nil))
Было бы хорошо, если бы аналогичным образом можно написать R-функцию со встроенным кодом C или lisp (более заинтересованным в последнем).
Собственный интерфейс .NET для RGUI. R (D) Com основан на COM, и он позволяет только обменивать матрицы, а не более сложные структуры.
Мне очень понравился бы профилировщик строк. Это существует в Matlab и Python и очень полезно для поиска битов кода, которые занимают много времени или выполняются больше (или меньше), чем ожидалось. Многие из моих кодов включают в себя оптимизацию функций и сколько раз что-то итерации могут быть неизвестны заранее (хотя большинство итераций ограничены или указаны).
Стек вызова полезен, если весь ваш код находится в R и очень прост, но как Недавно я опубликовал об этом, он требует много усилий, если ваш код сложный.
Очень легко разработать профилировщик строк для заданного бита кода. Наивный способ - индексировать каждую строку (или только предварительно определенные разделы) и вставлять вызов в журнал proc.time() эту строку. В цикле я просто перечисляю разделы кода и сохраняю в двумерном списке значения proc.time для раздела i в итерации k. [См. Обновление ниже: на самом деле это не способ сделать профилировщик строк для всех видов кода.]
Можно использовать такой инструмент для поиска горячих точек, аномалий (например, код, который должен быть O (n), но на самом деле O (n ^ 2)), код, который может извлечь выгоду из memoization (профилировщик строк не говорит вам это, но это позволяет вам знать, где искать), код, который ошибочно находится внутри цикла, и многое другое.
Обновление 1: Вставка линии синхронизации между каждой функциональной строкой немного ошибочна: определение строки кода - это не просто код, разделенный пробелом. Возможность анализа кода в АСТ необходима для того, чтобы знать, где начинаются и заканчиваются операции. Как обсуждалось в некоторых ответах на этот вопрос, для этого есть несколько инструментов (а именно showTree и walkCode в пакете codetools). Простое применение регулярного выражения к исходному коду было бы очень плохим делом.