ну и по сравнению с жавовой стдлибой - это вообще ноль

Раз пошла такая пьянка, решил глянуть, что у нас понаписано во всяких core-tools. Вдруг бросится в глаза, что можно выкинуть.
1. числа - всё плохо с BigDecimal/BigInteger. из коробки полно extension для Float/Double/Int, но нет аналогов для BigDecimal/BigInteger. Сиди пиши сам
2. Sequence - здесь более хитрые штуки, которые изначально мы реализовывали руками, но после появления windowedSequence часть кода ушла. Всё равно остаются кастомные сплиттеры (по условию, балансировщик, ...) и аналоги аналитических функций из SQL (скользящие окна, в которых агрегаты пересчитываются с учётом ограничений на контракт функции). Зачем-то сделан свой аналог FlatteningSequence. Возможно его не было в те времена
%)
3. ленивые Tuples
4. curry/uncarry/compose/decompose - вот это вообще подстава, так как приходится писать бесконечное кол-во довольно тупых перегрузок
5. мемоизация
6. recursiveConstruct(constructor: (() -> T) -> T), когда объекту для конструирования нужно передать способ получения себя же готового
7. Деревья/иерархии
8. interface Mapping<K, V> {
 operator fun get(key: K): V?
}, KeyValue<K,V>, ... Всё-таки Map<K,V> это очень жирный интерфейс со строгим контрактом. Как только хочешь сделать что-то ленивое и всякие там copy-on-write сразу хочется вырезать из него всё лишнее (ключи заранее неизвестны, никаких тебе isEmpty, keys, values, ...) Очень жалко, что у Map в Kotlin нет вменяемых предков, так можно было бы не извращаться с адаптерами

1. https://github.com/mipt-npm/kmath/pulls 🤷‍♂️

Но это мультиплатформа. В JVM используете жавовый и не паритесь

да понятно. на самом деле либ полно, но... непонятно почему этого нет в коробке. что за дискриминация BigDecimal/BigInteger. мы работаем в основном с ними

Потому что они только на JVM и с ними на самом деле мало кто работает

и в native думаю тоже. то есть отпадает только JS?

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

Собственно ваша ссылка это оно и есть. Можно узаконить  интерфейсы, а имплементацию уже в каждой платформе делать свою, либо использовать общую межплатформенную.

Только финансы на самом деле. В остальных местах это слишком дорого

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

Любые тяжелые математические операции надо биг числами - это дико дорого. Статистика над большими данными тоже. Вообще слабо себе представляют статистику с точностью 1e-12

Ещё из-за того, что у нас 90% кода на Java, довольно много дурацкого библиотечного кода написано только ради упрощения interop. Но это уже наша боль, тут вряд ли придумаешь что-то универсальное и точно не надо совать это в стандартную библиотеку. Самая частая тема - хочется чтобы код на java был похож на код koltin. То есть, всякие plus, sequence, toMap, ... Возможно это блажь, но из-за этого для java мы понаделали кучу обёрток вокруг inline, чтобы их можно было дёргать

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

Ну идиоматичный код на kotlin вообще не похож на жаву и плохо интеропится

Если вы это лечите биг децималами - это не есть очень хорошо. Скорее надо логарифмировать данные на входе. Но опять, если нет больших данных, то можно использовать что угодно

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

проблему с вычитаниями логарифмированием не решишь

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

ну и такие решения хороши, когда уже модель есть. а если модель меняется постоянно и неизвестно какие вещи захочется завтра посчитать? жалко терять исходную информацию, это же самое ценное