Комментарии 9
Если {Rmpfr} требуется повсеместно, можно реализовать поддержку {vctrs}, написав десяток функций-прослоек (обычно, довольно тривиальных), после чего этот тип отлично проинтегрируется со всем {tidyverse}-семейством и с пакетами, которые до сих пор на {vctrs} не переехали, но в будущем это сделают.
Добрый день! Очень интересная библиотека, спасибо за статью. Хочу предложить решение этой же задачи, которое основано на предложении в первом абзаце "Метаться в поисках другого инструмента? Тоже вариант". Решение в Wolfram Cloud:
frec[stopval_, n_, x_] := frec[stopval, n, x]=
If[n === stopval,
(stopval - 1) + stopval/(stopval + 1 + x),
(n - 1) + n/(frec[stopval, n+2, x])
]Block[{$RecursionLimit = 4000}, N[frec[2019,1, x]/.x->1, 6000]]
Block[{$RecursionLimit = 4000}, N[frec[2019,1, x]/.x->2, 6000]]
Тут, наверное, надо в задачу погружаться. Откуда такая проблематика.
- В целом аппаратные средства продвинулись неплохо вперед и можно позволить себе иногда не считать биты в угоду скорости решения. Виртуальной машинки 16CPU/128Gb, которая вполне приемлема по цене в enterprise задачах как калькулятор, для многих задач более чем достаточно на этапе исследований.
- Экономия по памяти оборачивается потерей скорости. Конвейер CPU оптимизирован на работу с целыми словами (32 или 64 бит, в зависимости от разрядности CPU). Часто скорость исполнения критичней потребляемой памяти.
- В продуктиве объемы могут быть существенно больше, которые ни при каком раскладе в память за раз не поместятся, поэтому все равно получаются бэкенды.
- В комплексном решении придется использовать внешние платформы, системы и т.д., а у них свои возможности и правила.
- В зависимости от задач можно попробовать использовать character, либы для работы с 8-ми битными изображениями, rcpp и пр.
Раньше, в условиях нехватки памяти, развлекались битвой за биты, сжатием в памяти и пр…
Но сейчас, к счастью, нет уже реальных потребностей — железа достаточно и можно фокусироваться на сути задач, времени получения финального результата, времени продуктивного исполнения.
на практике часто все в задачу упирается.
я в ряде задач использую ascii-character. как раз 8 бит. + регулярки по текстовому представлению для определенного класса задач позволяют решать в одну строку вещи, требующие страницу манипуляций в квадратных таблицах.
а еще есть разреженные матрицы. там эта оптимизация 32 -> 8 / 64 -> 8 ни разу не поможет на больших объемах.
Но изначально речь идет вовсе не об экономии памяти, а о вычислении величин, требуемая точность которых выше точности, обеспечиваемой стандартным представлением чисел с плавающей запятой.
Применение R при вычислениях с неограниченной разрядностью