AP
js начинает округления раньше
Size: a a a
2020 May 18
VG
уверен, что у него просто не %.5f ?
AP
ну типа такого, видимо, да...
AP
l = 99999999999.0123 + 0.00231432423
l.toPrecision(25)
"99999999999.01461791992188"
VG
даблы одни и те же в обоих, ага
AP
ага, это нам не перл6
AP
но вот где я с этим сталкивался и что делал...
YS
нормальное, не очень большое число, это около 18-19 знаков
в double 15 значащих знаков
YS
за пример с xor спасибо
AP
я помню что-то такое именно в жс я тоже страдал, там, кажись, округления намеренно загрублены, чтобы пользователи меньше удивлялись дабл-арифметике и в результате у меня даблы не точно передавались на сервер.
AP
и тоже в итоге передавал эти даблы как строки
AP
но именно перлу было плевать, я не проверял вероятность того, что прислали загрублённый вариант, после того, как починил жс
AP
то есть, проблема, что если дабл не привести к туПерсижн, то получается:
l = 99999999999.0123 + 0.00231432423
99999999999.01462
JSON.stringify({l: l})
"{"l":99999999999.01462}"
AP
то есть, в джейсоне из жс будет более округлённый вариант, чем он был бы в других яп. фиксить надо жс.
YS
дело не в жс
perl -le 'print 1234567890.123456;'
1234567890.12346
YS
double выше своей головы не прыгнет в любом языке
AP
то есть, в джейсоне из жс будет более округлённый вариант, чем он был бы в других яп. фиксить надо жс.
хм. хотя может я и не совсем прав:
$ perl -MJSON -E '$l = 99999999999.0123 + 0.00231432423; say encode_json({l=> $l})'
{"l":99999999999.0146}a
Yevhen Sabodash
в double 15 значащих знаков
Кстати, если вам надо валидировать JSON, то по стандарту никто ни double ни int64 не гарантирует.
YS
я и не надеюсь, поэтому ожидаю строку
AP
Yevhen Sabodash
я и не надеюсь, поэтому ожидаю строку
в общем, это довольно специальный случай. блин, я не помню таки что за трабла с даблами у меня была...