【问题标题】:Intl formatting of huge floating point numbers大浮点数的国际格式化
【发布时间】:2017-08-26 03:59:43
【问题描述】:

我试图更好地理解为什么大数字、可能具有较大精度的处理不一致,特别是在 JavaScript 及其本地化工具(例如 ECMA-402/Intl)中。我假设这与使用浮点数有关,但我想了解限制在哪里和/或如何避免这些陷阱。

例如,使用 Intl.NumberFormat:

console.log(new Intl.NumberFormat('en-US', { minimumFractionDigits: 3, maximumFractionDigits: 3 }).format(9999999999990.001)); // logs 9,999,999,999,990.000

let test1 = 9999999999990.001
console.log(test1);  // logs 9999999999990.002

我如何才能找出这些数字开始不一致的地方?有某种限制吗?当我增加小数精度时,该限制是否会改变,例如:

let test2 = 9999999999990.0004;
console.log(test2) // logs 9999999999990

【问题讨论】:

标签: javascript ecmascript-intl


【解决方案1】:

有什么限制吗?当我提高小数精度时,这个限制会改变吗?

是的,是的。 JavaScript 中的浮点数本身存储在 64 位空间中,这意味着它们可以表示的精度有限。请参阅this answer 了解更多信息。

我如何才能找出这些数字开始不一致的地方?

将您的“数字文字”以字符串的形式传递给函数,并检查该字符串在强制转换为数字并返回时是否返回正确的文字:

function safeNumber (s) {
  if (String(+s) !== s)
    throw new Error('Unsafe number!')
  return +s
}

let safe = safeNumber('999999999999999')
console.log(safe)

let unsafe = safeNumber('9999999999990.001')
console.log(unsafe)

【讨论】:

  • 这很棒而且内容丰富,但我真正想做的是提前了解这些“不安全”数字在哪里。如果我使用国际格式来格式化货币,我需要知道,此时我的值不会反映它们的“真实”值。换句话说,什么适合 64 位空间(小数点前的限制和小数点后的限制)......除非我理解错了!
  • 15 位有效数字。见stackoverflow.com/questions/1379934/…
猜你喜欢
  • 1970-01-01
  • 2010-11-20
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多