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

по RStudio — читайте релизы. из показательных примеров:
- сейчас поддержка 4.1.0;
- при переходе 1.3 -> 1.4 был добавлен был визуальный редактор RMarkdown.

пакеты тоже неплохо обновлять. Чтобы узнать зачем — читаем news.md по каждому пакету.
подхват новых фич в tidyverse тянет за собой веерное обновление, так что там уж все равно.

в целом, каждый в своей песочнице решает сам. можно и на baseR сидеть до пенсии.

Ну смотрите, есть base R, есть зоопарк пакетов, есть IDE.

Каждый день что-то из этого обновляется.

Какой смысл бежать ставить все самое новое и натыкаться на возможные грабли?

Когда появляется что-то новое, то об этом 100500 раз напишут. Тот же визуальный редактор - ну ОК.

Кому-то он полезен, я маркдаун документы вообще не делаю. Тот же tidyverse постоянно обновляется - какой смысл гнаться за всеми функциями?

Я понимаю там баги какие-то, но опять же: если бы это была критическая проблема, то об этом уже все бы знали. А так в R до сих пор несколько пакетов не умеют нормально считать медиану и квантили, а народ даже не в курсе или всем пофиг.

Производительность тоже такая штука, если увеличится хотя бы в несколько раз, то ОК, но и об этом будут трубить на каждом шагу.

Иными словами, мне непонятна рекомендация сидеть на самых свежих версиях IDE / пакетов просто по факту выхода этих новых версий.

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

Какие то популярные пакеты? (про медиану)

Тоже позиция. Если говорить про продуктив — единственно верная. Для лабораторных внутренних стендов  — весьма неубедительно.

Лично мне все  равно, какой стратегии люди придерживаются, если работу делают эффективно. А вот если делают плохо — тут имеет смысл разбираться.

Надо поискать. У меня в LinkedIn в контактах один биостатистик есть, который R в фарме активно использует. Причем в международной, а не в российской песочнице. Там одна из больших задач - numeric validation софта.

Раньше он топил за R, а потом, видимо, утонул в валидации и много писал о проблемах в R.

Я от него узнал, что оказывается есть 7 или 8 методов расчета медианы. В R исторически используется один из них, но не потому, что лучший, а т.к было проще реализовать. В итоге какие-то пакеты считают одним способом (которые зависят от base), какие-то другим (где самописная реализация).

На глаз это не заметно, но когда вы пытаетесь понять отличия, то вылазят такие особенности.

Всем привет! а кто сталкивался с co-clustering ?

Лучше не  слушать, а читать документацию и статьи. В базовом R метод quantile поддерживает 9 методов расчета:
https://www.rdocumentation.org/packages/stats/versions/3.6.2/topics/quantile
Там же ссылки на статьи, можно разбираться с математикой.

На больших выборках все примерно одинаково, на малых возникают нюансы подсчета.

Про проблемы, кстати, было бы интересно посмотреть.

На 90% уверен, что это не проблемы R, а проблема отсутствия навыков настоящей разработки ПО и малый кругозор по экосистеме R. Типичный сценарий.

Это высосанная из пальца проблема. Конечно, высосали ее буквоебы из FDA с вполне понятными целями

Речь шла о том, что по дефолту. Дескать, неудачный умолчальный выбор

Это не отменяет принципа чтения документации. Истина там и в коде. Остальное — ОБС.

В фарме регуляторным образом 1 программный продукт объявлен правильным, а на все остальные распространили презумпцию виновности

Поэтому нужно воспроизводить аутпут процедур SAS. Не потому, что там все правильно, а потому что там SAS

мне кажется это неправда :) FDA неоднократно заявляла, что принимает результаты в любом софте, если заявитель доказал, что софт нормально считает.

SAS Institute выстроил типичные антиконкурентные траншеи (включая мифологию о том, что только их софт самый каноничный). Ту же задачу numeric validation они точно так же решают, но поскольку SAS родом из одной конторы, то это технически было сделано намного раньше и проблем с этим меньше

знаю, писал даже об этом в блоге. Я про валидацию

Все равно нужно доказать, что все посчитано "как в SAS". А значит изволь купить и пользоваться хотя бы для валидации

глубоко в SAS  не погружался, но тот код, который довелось видеть — это же COBOL на IBM/360, не меньше.

Куда честнее было бы зарелизить какие-то бенчмарки на самые ходовые процедуры

Сотню синтетических датасетов, на которых бы считались описательные статистики, два десятка именных критериев и десяток спецификаций линейных моделей