当前位置: 首页 > 面试题库 >

为什么Firestore会舍入64位整数?

范瀚昂
2023-03-14
问题内容

我正在尝试从Firestore数据库中的python程序中存储64位整数。问题在于,似乎最后一位数字已四舍五入。

doc = db.collection('questions').document('0MPvbeTEglD9lbpDq6xm')
ints = [9223372036854775807, 9223372036854775533, 9223372036854775267]
doc.update({
    'random': ints
})

当我查看数据库时,它们存储为:

random = [9223372036854776000, 9223372036854776000, 9223372036854775000}

根据文档,支持64位带符号整数。可能是什么问题?


问题答案:

我不确定100%,但是我的猜测是您看到的是JavaScript整数的大小不是64位。它们实际上更像是53位。由于Firebase控制台是使用JavaScript实现的网络应用,因此它可能无法理解您写入到其中的64位很大的整数。

我建议您使用另一个python程序从文档中读取值,而不要在控制台中检查值。如果它们与您编写的内容相同,那么这里没有真正的问题。您只是不信任控制台中值的呈现。



 类似资料:
  • 问题内容: 最近,我一直在对我公司的数据库产品的写入性能进行一些基准测试,并且发现仅切换到64位JVM可以使性能持续提高20-30%。 我不允许详细介绍我们的产品,但基本上它是面向列的数据库,已针对存储日志进行了优化。基准测试包括向其提供几GB的原始日志,并确定分析它们并将其作为结构化数据存储在DB中所需的时间。CPU和I / O的处理非常繁重,尽管很难说是什么比例。 有关设置的一些注意事项: 两

  • 问题内容: 我正在尝试计算美元金额的折算百分比。在50%的价格下,有时您会得到半分钱,我需要四舍五入到最接近的一分钱。 在Sql中,我的计算如下: 如果采用以下值,则会得到不同的结果: 4.39 2.49 不全面的我得到: 4.39-> 2.195 2.49-> 1.245 取整后得到: 2.195-> 2.19 1.245-> 1.25 有人告诉我这是“银行取整”的一种形式,但似乎影响取整方向的

  • 检查了一些解决方案,但我没有得到预期的结果,这是我的代码; 谢了!

  • 我试图在Java中完善BigInteger,以下是我执行的代码 因此,输出prec1 = 49.32和prec2 = 49.33,对于我的使用情况,我需要始终舍入到49.33,那么除了设置两次比例之外,还有其他方法舍入到49.33吗?

  • 问题内容: 目前,我正在记录东西,并且正在使用带有自定义的格式化程序: 我的问题是微秒为六位数。无论如何,是否需要吐出更少的数字,例如微秒的前三个数字? 问题答案: 最简单的方法是使用切片将微秒的最后三位数字切掉: 我强烈建议切碎。我曾经写过一些对时间戳进行四舍五入而不是四舍五入的记录代码,当四舍五入改变了最后一位时,我发现它实际上有点令人困惑。定时代码在某个时间戳记时停止运行,但是由于舍入的缘故

  • 问题内容: 我有以下代码: 我得到这个值:“ ”,这是 我想知道JavaScript是否处理64位整数,还是我做错了什么? 问题答案: JavaScript使用IEEE-754双精度(64位)格式表示数字。据我了解,这为您提供53位精度,或者15至16个十进制数字。您的数字位数超出了JavaScript所能应付的位数,因此最终得到了一个近似值。 这样并不是真正的“错误处理”,但是如果您需要对大数进