LINUX.ORG.RU

Длинная математика в rust

 


0

3

Господа растафарианцы, расскажите пожалуйста, если какой-нибудь крейт для раста с длинными числами вроде Integer в хаскеле? Которые неатомарные, но никогда не переполняются? Я чет не могу ничего нагуглить кроме i128. Это, конечно, длинный тип, но конечный, а потому не подходит.

★★★★★

если какой-нибудь крейт

Вся суть разработки на русте.

ЗЫЖ. Юзал из OpenSSL,

anonymous
()
Ответ на: комментарий от anonymous

Ты так говоришь как будто в этом есть что-то плохое

AntonyRF ★★★★
()
Ответ на: комментарий от intelfx

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

рустоманы не умеют в поиск, это и по их телеграммчикам понятно.

Ну и на любой мелкий чих ищут крейт, даже там, где код писать минут 5.

anonymous
()
Ответ на: комментарий от anonymous

Мне кажется это скорее камингаут у них такой. Лишний ровод упомянуть раст в инфошуме. Эдакие кодер-веганы. :)

anonymous
()
Ответ на: комментарий от hateyoufeel

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

anonymous
()
Ответ на: комментарий от anonymous

хохмы хохмами, но это одна из проблем горбатых макак с зудящими пердаками, они не могут остановиться и выбрать какую-то реализацию которая +/- устроила бы большинство и развивать ее. Они хотят быть новаторами, не такими как все, особенными, избранными. Казалось бы, уже есть опенсорс, уже можно всем просто вносить свою лепту, но даже тут горбатые макаки умудрятся пересраться друг с другом, и в лучшем случае форкнуть проект, а в худшем просто начать делать тоже самое, но немного иначе.

anonymous
()
Ответ на: комментарий от Siborgium

Т.е. судя по описанию "стринги, используемые в проекте (a/b/c), у них уже в каждом проекте можно сказать своя реализация строк? Мухаха.

anonymous
()
Ответ на: комментарий от anonymous

дык дело делать скучно и трудно. А лисапед, да побегать по проектам с «have you considered rewrite ___ in rust?» – легко и весело)

P.S. После появления такой должности в этом вашем айти как «Евангелист», думаю давно пора ввести - «Овцы».))

anonymous
()
Ответ на: комментарий от anonymous

Вся суть разработки на русте

Если ты под каждую типовую изобретаешь велосипед, то ты не очень хороший инженер

Aswed ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Нет. Речь о том, что никакая реализация не может безоговорочно уделывать все остальные, потому что у разных реализаций разные задачи.

Siborgium ★★★★★
()
Ответ на: комментарий от Aswed

Если ты под каждую типовую изобретаешь велосипед

Ну у тебя же не типовая. Иначе зачем раст? Типовую можно на скриптах писать.

cloun1902
()
Ответ на: комментарий от cloun1902

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

Aswed ★★★★★
() автор топика
Ответ на: комментарий от Aswed

Ты так говоришь, будто скрипты это что-то плохое

Нет, почему. Наоборот, для типового самое то.

Я собсна раст выбрал потому что числодробилку делаю, а для этих целей он удобнее того же питона.

ок.

cloun1902
()

Пытался найти что-то подобное python’овском decimal, но как выяснилось очень много библиотек просто по-дилетантски сконструированы, у многих даже нет pow (не путать с powi), а у некоторых нет реализации Display/toString. В общем даже если удастся обойти ограничения по функционалу, то упретесь в размер самого decimal.

deterok ★★★★★
()
Ответ на: комментарий от deterok

Пытался найти что-то подобное python’овском decimal

В питоне нет bigint?

 pwsh > 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000n + 1
10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
anonymous
()
Ответ на: комментарий от deterok

Так тебе decimal или bigint? Стандартный питоновский int это и есть bigint, а decimal нужен для точных вычислений при работе с плавающей точкой.

Aswed ★★★★★
() автор топика
Ответ на: комментарий от anonymous

в стандартной библиотеке языка, которая безальтернативно уделывает любую другую реализацию.

такое бывает только в сказке

seiken ★★★★★
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от Aswed

Я имел ввиду именно decimal, ну хорошо, просто предупреждаю что с математикой на rust все не очень пока.

deterok ★★★★★
()
Ответ на: комментарий от Aswed

У меня ещё и все зависимости завендорены, чтоб каргогавно не тянуть.

anonymous
()
Ответ на: комментарий от anonymous

где код писать минут 5

Продемонстрируешь написанную тобой за 5 минут длинную математику? Мы посмеемся.

trex6 ★★★★★
()
Ответ на: комментарий от anonymous-angler

Охренительно лучше. Некоторые вещи очень, очень, очень вредно форкать, изобретать и велосипедить. Их все человечество вместе взятое нормально написать не может.

t184256 ★★★★★
()
Ответ на: комментарий от Aswed

Так тебе decimal или bigint?

А ничего что это одно и тоже, вид сбоку?

no-such-file ★★★★★
()
Ответ на: комментарий от anonymous

Ну да ну да.

Я тут как-то один модулёк вычислительный, тупо конвертнув с помощью f2c и чутка поправив извращения с индексами после f2c, ускорил раза этак в полтора.

Так что нихрена он давно уже не заточен.

Тру-ультра-хардкор всё-таки уж лучше на сишечке с плюсами писать. Ну или на Расте, если хочется нового.

А Фортран ценен только тем, что во времена оные на нём 100500 тонн строк кода было написано, которые никто переписывать не собирается, но поддерживать их надо.

WatchCat ★★★★★
()
Ответ на: комментарий от trex6

ты поехавший чтоль? где там про математику за 5 минут? там за «любую проблему, где решение за 5 минут» было. Хотя чего это я. рустомане не умеют читать же. им для этого крейта не завезли

anonymous
()
Ответ на: комментарий от WatchCat

поправив извращения с индексами

Они там изначально вообще в правильном порядке использовались? Первый индекс быстрее меняется.

Для фортрана обычно достаточно хорошие оптимизирующие компиляторы. Процентов в 10% выигрыша на временах больших миллисекунд легче поверить, т.к. на мелких слишком большие погрешности.

которые никто переписывать не собирается

И правильно, нечего переписывать то, что работает. За переписывание денег никто не заплатит.

grem ★★★★★
()

Почему сразу не взять язык, где уже реализован этот тип и всеми активно используется?

grem ★★★★★
()
Ответ на: комментарий от grem

Они там изначально вообще в правильном порядке использовались?

Ты видать никогда не смотрел выхлоп f2c. Там заводится отдельный указатель на -1 от оригинального массива и испорльзуется без изменения индексации, т.к. в фортране индексация с единицы, а не с 0.

Т.е. int a[]; int* b = a - 1; b[1] = 5; (грубо говоря).

И вот в таком случае не факт, что оптимизатор нормально отработает.

Ну и я опускаю случай двумерных массивов, т.к. там то ещё извращение получается.

Они там изначально вообще в правильном порядке использовались?

Ага, проще железа на 100500 килобаксов купить.

WatchCat ★★★★★
()
Ответ на: комментарий от t184256

Нет, не лучше. Тащить библиотеку с кучей разного ненужного (e.g. если тебе нужны только безразмерные рациональные числа, то вся остальная OpenSSL тебе не нужна) и под несколькими лицензиями - какой-то оверкилл.

Это проблему решили крейты: куча мелких компонентов.

ИМХО, многие не так смотрят на проблему гор мусора на crates.io. Когда чего-то нет и вдруг оно становится востребованным, то все бегут изобрести велосипед, да, такого там много. Но из всех велосипедов выживает только тот, который оказался лучшим, может парочка. И дальше изобретай - не изобретай, но выпереть лидера из ниши будет либо тяжело, либо невозможно.

  1. Было когда-то несколько способов сериализовывать данные - да, теперь из живых остался только serde и бэкенды.
  2. Былы десятки крейтов, которые позволяли определять enum-ы ошибок. Упокоились. Потому что изобрели thiserror и anyhow.
  3. Есть, как где-то в треде упомянули, крейты со слегка разными строками, где-то с интернингом, где-то с CoW. Но кто это использует? Правильно - почти никто. Ни разу ещё не встречал ситуации, где бы мне приходилось использовать что-то помимо стандартных строк.
  4. Были попытки изобрести что-то для data parallelism. Умерли. Все используют rayon.

И так далее. И что ещё важно, из-за системы типов без наследования, большинство этих компонентов подходят друг к другу из коробки, с минимальными усилиями или без них вовсе. Жаль, что похоже нет чего-то нормального для безразмерных чисел, но и это напишут, и оно тоже займёт нишу, которую позже будет трудно освободить.

anonymous-angler ★☆
()
Ответ на: комментарий от anonymous-angler

На самом деле эта проблема не уникальная для раста. Этого везде хватает. И везде ситуация примерно одна и та же: поделки померли, а самый лучший велосипед используется массово.

anonymous-angler ★☆
()
Ответ на: комментарий от WatchCat

Ну и я опускаю случай двумерных массивов, т.к. там то ещё извращение получается.

Я как раз про это, так как при конвертации циклы должны быть вывернуты наизнанку. Если были правильно записаны.

Ты видать никогда не смотрел выхлоп f2c.

Нет. Зато как-то переписывал какую-то разностную схему с дельфи на c++, где были вложенные циклы по 3 индексам, которые друг из друга вычитались. Вот тут веселье было при учёте, где нужно единичку вычесть, а где уже нет.

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от grem

так как при конвертации циклы должны быть вывернуты наизнанку.

И это тоже. Но f2c это делает тупо, но извращённо. Т.е. да, он сохраняет поведение, чтобы не пролюбить индексацию, но как мне показалось, сишечный компилятор не может в нормальную оптимизацию на том коде.

И как в итоге f2c->руки->gcc оказалось быстрее gfortran. Sad but true.

Зато как-то переписывал какую-то разностную схему с дельфи

О-о-о, паскалеизвращения. Ну, так-то я ничего не имею против Паскаля как исторического языка, но переводить с него на сишечку примерно то же, что и с фортранчика, да.

WatchCat ★★★★★
()
Последнее исправление: WatchCat (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.