Есть статьи?

По этой теме

Таким образом можно is signed и прочее организовать через этот enum

Тоесть обобщить его на все типы

big endian little endian

Имплементации могут различаться, поэтому просто через memcpy сераилизовать не получится

Если токен генится со стороны сервера

То все норм будет же

Имплементации могут различаться, поэтому просто через memcpy сераилизовать не получится

С ним нельзя работать как с местом?

Интом*

Местом?

А

)))

Т9

Он такой (:

Хотя т9 давно нет, он ток на кнопочных )))

Но он мутировал в автозамену, которую так и называют т9....

Аш нокию вспомнил

Всплакнул

И Сименс...

Хорошие времена были...

Он ещё и не занимает столько сколько ты написал да?

Интом*

Под капотом это массив чисел, в той последовательности, которая кажется разумной разработчику стандартной библиотеки или в той последовательности, для которой есть оптимальные машинные инструкции для сложения/вычитания/деления Накакой переносимости на бинарном уровне нет, как и нет переносимости у std::bitset или std::map

И ещё надо такую же фигню с флоатами

Под капотом это массив чисел, в той последовательности, которая кажется разумной разработчику стандартной библиотеки или в той последовательности, для которой есть оптимальные машинные инструкции для сложения/вычитания/деления Накакой переносимости на бинарном уровне нет, как и нет переносимости у std::bitset или std::map

а наклыдваются какие-либо гарантии на асимптотику выполнения операций деления\умножения в длинке?

чтобы не получилось так, что библиотеок-писатели могли непотимальный алгоритм запихнуть

И ещё надо такую же фигню с флоатами

С этим сложнее будет, пк не очь хорош с плавающей точкой (:

Если нужна переносимость - докидывайте идеи, вносите конкретные предложения в proposal, приводите доказательста для на всех платформ существует один и тот же оптимальный порядок следования сов

С этим сложнее будет, пк не очь хорош с плавающей точкой (:

Да плевать, хотяб разрешить имеющиеся реализации

Если нужна переносимость - докидывайте идеи, вносите конкретные предложения в proposal, приводите доказательста для на всех платформ существует один и тот же оптимальный порядок следования сов

ты сам прекрансо понимаешь, что такого не будет

Главное обощить

Обобщить*

Типа точность как шаблонный параметр

Пока можно без длинки

а наклыдваются какие-либо гарантии на асимптотику выполнения операций деления\умножения в длинке?

Хорошая мысль, пока не накладывали ограничений. Мне кажется что сложность будет O(N) для всех операций, где N - количество машинных слов. Но у меня нет 100% уверенности поэтому полагаюсь пока что на разумноть имплементаторов

Хорошая мысль, пока не накладывали ограничений. Мне кажется что сложность будет O(N) для всех операций, где N - количество машинных слов. Но у меня нет 100% уверенности поэтому полагаюсь пока что на разумноть имплементаторов

так, насколько я понял из наших давних разговоров, в этой либе длинка будет, так?

просто для длинной арифеметики операция того же умножения далеко не O(N)

Если нужна переносимость - докидывайте идеи, вносите конкретные предложения в proposal, приводите доказательста для на всех платформ существует один и тот же оптимальный порядок следования сов

> оптимальный порядок следования сов украду пожалуй, уж очень хорошо

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

http://e-maxx.ru/algo/fft_multiply

@antoshkka го подкаст?

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

С чего ты решил что в СТД они будут оптимальными?

Фурье же долгое

Нет?

С чего ты решил что в СТД они будут оптимальными?

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

как к тому же std::sort

хоть это и не остановило разрабов libc++

Ну асимптотика это ещё не вся скорость

Ну асимптотика это ещё не вся скорость

да неужели?))

Фурье же долгое

можешь сам написать и бенчмаркать

увидишь, кто быстрее

Более быстрые алгоритмы я не осилю наверное но по-любому что-то есть

Более быстрые алгоритмы я не осилю наверное но по-любому что-то есть

быстрее фурье я не слышал

есть ещё Карацуба, но он проигрывает

Qsort уже не то?

Qsort уже не то?

уже давно

Он даунский карацуба ваш

(:

Он даунский карацуба ваш

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

Там как раз тоже нлог

Нам в вузе до сих пор о нем толдычат , что он крут

(:

Nlogn

увидишь, кто быстрее

на коротких наивное быстрее всего насколько я помню

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

Так как мне оптимальная асимптотика не известна и не известно, будет ли алгоритм с оптимальной асимптотикой всегда эффективнее более наивного алгоритма - оставлю пока как есть :)

на коротких наивное быстрее всего насколько я помню

конечно быстрее. Я думаю, что это всем здесь очевидно

Так как мне оптимальная асимптотика не известна и не известно, будет ли алгоритм с оптимальной асимптотикой всегда эффективнее более наивного алгоритма - оставлю пока как есть :)

оптимальная асимптотика неизвестна никому

ERROR: S client not available

конечно быстрее. Я думаю, что это всем здесь очевидно

ну а смысл тогда асимптотику ограничивать?

ну а смысл тогда асимптотику ограничивать?

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

так как не так всё страшно у фурье там

а на длинных ты выигрываешь нормально так

но это дело нужно бенчить и графики рисовать

а на длинных ты выигрываешь нормально так

ну в длинном кейсе я бы взял gmp и не парился

а на длинных ты выигрываешь нормально так

Не выиграешь

ну в длинном кейсе я бы взял gmp и не парился

а не хочу брать и юзать STL

Ограничение даёт только проигрыш на коротких

чем проигрывать 2% на умножении 128 битных интов

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

а на длинных ты выигрываешь нормально так

при этом никто не мешает на длинном кейсе использовать оптимальный алгоритм

чем проигрывать 2% на умножении 128 битных интов

тоже аргумент, не спорю. Тогда всё скидываем на совесть реализаций

Ничего или проигрыш на коротких?

сделают ли они отдельные версии для длинных

Ничего или проигрыш на коротких?

какое ничего? Ты серьезно думаешь, что нет никакой разницы между наивным умножением и оптимизированным через БПФ?

серьёзно?

сделают ли они отдельные версии для длинных

ну все равно это либо практически переписывать GMP в std либо проигрывать GMP, и тогда на перформанс критикал все равно его брать

ну все равно это либо практически переписывать GMP в std либо проигрывать GMP, и тогда на перформанс критикал все равно его брать

я с радостью затянул бы весь GMP в стандарт

какое ничего? Ты серьезно думаешь, что нет никакой разницы между наивным умножением и оптимизированным через БПФ?

Я думаю что отсутствие ограничения подразумевает отсутствие вменяемой имплементации

Я думаю что отсутствие ограничения подразумевает отсутствие вменяемой имплементации

не всегда

разрабы либ тоже не дураки

Не подразумевает*

а, вот так то да

но это стимул что ли

не зря же на сорт дана гарантия

Но подразумевает проигрыш на коротких

можно было и не давать гарантии про NlogN

Поэтому ничего либо проигрыш на коротких

а, всё, я понял тебя.

Никаких гарантий или гарантия проигрыша

Мой выбор никаких