blocks|key|302011|text|简短的答案是:不要将这些数字打包为浮点数。由于采用IEEE浮点表示法，您将失去准确性。相反，将它们转换为“字符小数”(即字符串)，并将其打包为字符串。如果您确实需要精确度，并且不需要对它们执行数学运算，那么您可能还希望将它们存储为Perl中的字符串。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|302012|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The short answer is: don't pack these numbers as floats. You will lose accuracy due to IEEE floating point representation. Instead, convert them to "character decimals" (i.e. strings), and pack them as strings. If you really need the accuracy, and don't need to perform math operations on them, you may want to store them as strings in Perl as well.

blocks|key|2081322|text|pack的f模板是用于单精度浮点数的，在大多数平台上，它的精度可以达到7位小数左右，而d模板可以提供双精度，并且足以支持15位小数。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2081323|print+unpack("f",+pack("f",12.2));++++++++++#+"12.1999998092651"
print+unpack("d",+pack("d",12.2));++++++++++#+"12.2"

printf+"%25.20f",unpack("f",+pack("f",12.2));+#+"12.19999980926513671875"
printf+"%25.20f",unpack("d",+pack("d",12.2));+#+"12.19999999999999928946"|code-block|syntax|javascript|2081324|entityMap^0|0|4|5|1|17|1|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]|$9|P|A|Q|B|C]|$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|T|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|U|8|@]|D|@]|E|$]]]|L|$]]

<code>pack</code>'s <code>f</code> template is for single-precision floating point numbers, which on most platforms is good to 7 or so decimal places of accuracy. The <code>d</code> template offers double-precision and will be good enough for ~15 decimal places.

<pre><code>print unpack("f", pack("f",12.2)); # "12.1999998092651"
print unpack("d", pack("d",12.2)); # "12.2"

printf "%.20f",unpack("f", pack("f",12.2)); # "12.19999980926513671875"
printf "%.20f",unpack("d", pack("d",12.2)); # "12.19999999999999928946"
</code></pre>

blocks|key|2081326|text|2/10是二进制周期数，就像1/3是十进制周期数一样。它不可能准确地存储在浮点数中，因为它将占用无限的存储空间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2081327|因此，并不是pack引入了错误；它准确地存储了您提供的数字。|offset|length|style|CODE|2081328|$+perl+-E'say+sprintf+"%25.20e",+12.2'
1.21999999999999992895e%2B01

$+perl+-E'say+sprintf+"%25.20e",+unpack+"d",+pack+"d",+12.2'
1.21999999999999992895e%2B01|code-block|syntax|javascript|2081329|只要你使用浮点数，你就不能准确地存储12.2。|2081330|但正如您在上面看到的，您可以使用d+(双精度，接近16位精度)而不是f+(单精度，超过7位精度)来存储足够精确的存储。Perl使用双精度，因此您实际上是通过使用f而不是d引入了精度损失。|2081331|因此，使用d，并对结果进行舍入(sprintf+"%25.10f")。|2081332|entityMap^0|0|6|4|0|0|0|G|1|Y|1|28|1|2C|1|0|5|1|G|F|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@$D|W|E|X|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|Y|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@$D|11|E|12|F|G]|$D|13|E|14|F|G]|$D|15|E|16|F|G]|$D|17|E|18|F|G]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|19|8|@$D|1A|E|1B|F|G]|$D|1C|E|1D|F|G]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|T|$]]

2/10 is a periodic number in binary just like 1/3 is a periodic number in decimal. It's impossible to store it exactly in a floating point number as it would take infinite storage.

As such, it's not <code>pack</code> that's introducing the error; it's faithfully storing precisely the number you provided it.

<pre><code>$ perl -E'say sprintf "%.20e", 12.2'
1.21999999999999992895e+01

$ perl -E'say sprintf "%.20e", unpack "d", pack "d", 12.2'
1.21999999999999992895e+01
</code></pre>

As long as you use floating point numbers, you will not be able to store 12.2 exactly.

But as you can see above, you can store store precisely enough by using <code>d</code> (double-precision, almost 16 digits of precision) instead of <code>f</code> (single-precision, over 7 digits of precision). Perl uses double-precision, so you were actually introducing precision loss by using <code>f</code> instead of <code>d</code>.

So use <code>d</code>, and round your results (<code>sprintf "%.10f"</code>).

I am packing an array of numbers to send via UDP to another piece of hardware using socket programming. 

When I <code>pack</code> the number 12.2 and then <code>unpack</code> it, I get 12.199999892651. As I am working with numbers related to latitudes and longitudes, I cannot have such deviations.

This is the simple script I wrote:

<pre><code>use warnings;

use Time::HiRes qw (sleep);

@Data = ( 20.2, 30.23, 40.121, 1, 2, 3, 4, 6. 4, 3.2, 9.9, 0.1, 12.2, 0.99, 7.8, 999, 12.3 );

$myArr = pack('f*', @Data);

print "$myArr\n\n";

@Dec = unpack('f*',$myArr);

print "@Dec";
</code></pre>

The output is:

<pre><code>20.2000007629395 30.2299995422363 40.1209983825684 1 2 3 4 6.40000009536743 3.20 000004768372 9.89999961853027 0.100000001490116 12.1999998092651 0.9900000095367 43 7.80000019073486 999 12.3000001907349
</code></pre>

Is there any way I can control the precision?

How can I eliminate floating point inaccuracy when I pack and unpack a floating point number?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我打包了一个数字数组，以便使用套接字编程通过UDP发送到另一个硬件。当我pack数字12.2，然后unpack它，我得到12.199999892651。因为我使用的是与纬度和经度相关的数字，所以我不能有这样的偏差。这是我写的简单脚本：use warnings;use Time::HiRes qw (sleep);@Da...

问如何在打包和解包浮点数时消除浮点数的不准确性？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何在打包和解包浮点数时消除浮点数的不准确性？EN