Question

我需要在文本文件中写几个浮点数并与它们存储CRC32校验和。然后，当我从文本文件中读取浮动时，我想重新计算校验和并将其与保存文件时先前计算的校验和进行比较。我的问题是校验和有时会失败。这是因为相等的浮点数可以由不同的位模式表示。为了完整起见，我将在下一段中总结代码。

我在阅读this CRC32 algorithm后找到了this question。这是它的样子：

uint32_t updC32(uint32_t octet, uint32_t crc) {
    return CRC32Tab[(crc ^ octet) & 0xFF] ^ (crc >> 8);
}

template <typename T>
uint32_t updateCRC32(T s, uint32_t crc) {
    const char* buf = reinterpret_cast<const char*>(&s);
    size_t len = sizeof(T);

    for (; len; --len, ++buf)
        crc = updC32(static_cast<uint32_t>(*buf), crc);
    return crc;
}

CRC32Tab包含与上面链接的文件中的大数组完全相同的值。

这是我如何将浮点数写入文件并计算校验和的缩写版本：

float x, y, z;

// set them to some values

uint32_t crc = 0xFFFFFFFF;
crc = Utility::updateCRC32(x, crc);
crc = Utility::updateCRC32(y, crc);
crc = Utility::updateCRC32(z, crc);
const uint32_t actualCrc = ~crc;

// stream is a FILE pointer, and I don't mind the scientific representation
fprintf(stream, " ( %g %g %g )", x, y, z);
fprintf(stream, " CRC %u\n", actualCrc);

我从文件中读取了如下值。实际上涉及的内容更多，因为文件具有更复杂的语法并且必须进行解析，但我们假设getNextFloat()返回之前写入的每个float的文本表示。

float x = std::atof(getNextFloat());
float y = std::atof(getNextFloat());
float z = std::atof(getNextFloat());

uint32_t crc = 0xFFFFFFFF;
crc = Utility::updateCRC32(x, crc);
crc = Utility::updateCRC32(y, crc);
crc = Utility::updateCRC32(z, crc);
const uint32_t actualCrc = ~crc;

const uint32_t fileCrc = // read the CRC from the file
assert(fileCrc == actualCrc); // fails often, but not always

这个问题的根源是std :: atof将返回从文件中读取的字符串中编码的float的不同位表示，而不是用于将该字符串写入的字符串的浮点数表示形式。文件。

所以，我的问题是：是否有另一种方法来实现我的校验和浮点数的目标，这些浮点数通过文本表示进行往返，而不是校验字符串本身？

感谢阅读！

Answer 1

如果文本文件不必是人类可读的，请使用hexadecimal float literals，它们是完全正确的，因此您不会遇到文本内存值和内存中值之间的差异问题。

Answer 2

从您的评论中可以看出问题的根源：

如果我没有完全弄错的话，这里就没有发生过四舍五入的事情。 %g说明符选择最准确表示数字的最短字符串表示。

这是不正确的。如果未指定精度，则默认为6，对于大多数浮点输入，舍入将肯定。

如果您需要人类可读的可循环格式，%a是迄今为止最佳选择。如果不这样做，您将需要指定至少为9的精度（假设您系统上的float是IEEE-754单精度）。

您可能仍会被NaN编码绊倒，因为该标准未指定必须如何或是否必须打印。

Answer 3

如果您的标准库的浮动到文本和文本到浮动的转换进行了正确的舍入，那么您只需要足够重要的数字来浮动＆gt; text-＆gt;浮动往返是无损的，除非您还有Infs和NaNs，仍然应该是“保值”，不一定是bitpattern保留，因为我认为有无穷或NaN的多种表示。对于IEEE-754 64位双17位有效数字足以使往返相对于实际值无损。

Answer 4

对于具有单个值的多个二进制表示的任何类型，您的CRC算法都存在缺陷。 IEEE 754有两个0.0的表示，即+0.0和-0.0。其他非有限值如NaN也可能很麻烦。

Answer 5

在更新CRC之前规范化您的号码是否可以接受？因此，在保存时，您将得到一个临时字符串版本的数字（使用sprintf或任何匹配您的序列化格式），然后将此字符串转换回数值，然后使用此结果更新CRC。这样，您就知道CRC将与反序列化值匹配。

通过文本文件往返的浮动校验和

5 个答案: