Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 24

В каких случах по Вашему мнению лучше всего подходит BigInt?
Комментарий пока не оценивали0
Собственно, про это уже писали:
— для больших числовых идентификаторов
— для точных меток времени
— для реализации BigDecimal
Комментарий пока не оценивали0
При работе с вебсервисами, которые не знают про странные ограничения js.
Всего голосов 2: ↑2 и ↓0+2
При работе с RSA, например.
Комментарий пока не оценивали0
Спасибо за статью, ну тут бы сначала нужно решить проблему с вещественным типом: хранения и отображения данных 0.2 + 0.1 = 0.30000000000000004, 0.2 + 0.1 === 0.3 (false), а то как-то неудобно работать )
Всего голосов 6: ↑3 и ↓30
А как её можно решить в принципе? Эти особенности у вычислений с плавающей точкой были с рождения.
Всего голосов 7: ↑7 и ↓0+7
НЛО прилетело и опубликовало эту надпись здесь
Ну я конечно не спец по компиляторам и хранению данных. Но специально проверил, Visual FoxPro (когда то писал на нем просто много лет) и PostgreSQL работает адекватно, вот пример на PostgreSQL
SELECT 0.1 + 0.2, 0.1 + 0.2 = 0.3
-------------------------------------
0.3 true
Комментарий пока не оценивали0
Ну так там 0.1 — это numeric, а не real. То есть используется фиксированная точка, а не плавающая.
Комментарий пока не оценивали0

psql просто округлил число при выводе.

Всего голосов 2: ↑1 и ↓10

А false округлил до true.

Всего голосов 3: ↑3 и ↓0+3
НЛО прилетело и опубликовало эту надпись здесь
BigDecimal на базе BigInt :)
Комментарий пока не оценивали0
Это проблема вообще не решаема, так как 0.3 нельзя представить как конечное число в двоичном виде. Например, представьте что вы храните числа в ячейке из 5 десятичных разрядов. Как вы в нем запишите 1/3 = 0,(3)? 0.3333? 0.3334? спойлер, никак) Вот точно так же в конечном двочином значении невозможно записать некоторые конечные десятичные числа
Всего голосов 3: ↑2 и ↓1+1
Вообще-то решаема, но очень сложно, созданием новой арифметики вычислений. Хранить такие числа например как (очень грубо говоря) строки типа «1/3».
Вот, кажется, даже реализация есть на PHP:
github.com/brick/math
Всего голосов 1: ↑0 и ↓1-1
нерешаема при сохранении скорости вычислений как у double, если быть точнее
Всего голосов 3: ↑3 и ↓0+3
Какой прок в быстром вычислении того, что 0.3 * 3 + 0.1 !== 1?
Всего голосов 1: ↑0 и ↓1-1
Всего голосов 2: ↑2 и ↓0+2

Статья отличная, язык ***** [очень сложный, противоречивый, с большим количеством неверных решений, которые приходится поддерживать].

Всего голосов 3: ↑2 и ↓1+1
Отдельно хотелось бы добавить еще ложечку дегтя: bigint вызывает ошибку сериализации при JSON.stringify:

let data = { x: 1n };
JSON.stringify(data); // TypeError: Do not know how to serialize a BigInt

В этом тоже есть некоторая здравость… даа. Придется использовать внешние либы.
Всего голосов 1: ↑1 и ↓0+1
В этом тоже есть некоторая здравость

Как я понимаю, json никак не ограничивает точность сериализуемых значений, можно написать хоть {"a": 10000000[ещёстонулей]0000001}, то есть сериализовать BigInt проблемы нет вообще. То есть текст ошибки очевидно врёт.


Проблема в том, что не ясно, как десериализовать конкретное значение, в Int или BigInt, а так как два этих типа абсолютно не взаимозаменяемы, то результат десериализации будет не равен результату сериализации, поэтому сериализацию BigInt решили запретить.

Всего голосов 6: ↑6 и ↓0+6
Спасибо! Согласен, что проблема именно в десериализации. Просто защитились от возможной неоднозначности еще одним TypeError.
Всего голосов 2: ↑2 и ↓0+2

Симметричность JSON.parse/stringify уже и так нарушается, если присутствует объект Date, например. Так что непонятно, почему для BigInt это стало внезапно важно

Всего голосов 1: ↑1 и ↓0+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr