2

首先,我要解决的问题是为始终保持均匀分布在范围内的值提出更好的表示:

0.0 <= x < 1.0

这样做的动机是尝试减少用于存储此数据的字节数(应用程序受大量内存和 I/O 带宽限制)。目前使用的是 32 位浮点表示,16 位浮点被证明不够准确。

我最初的想法是尝试将数据存储在 16 位整数中并简单地使用该方案:

x/(2^16 - 1) [x is an unsigned short]

为了保持算法大致相同并保持使用相同的浮点硬件操作(至少一开始),理想情况下,我希望继续将此小数表示转换为浮点表示,执行操作,然后转换回分数表示进行存储。

显然,在这两个完全不同的、不精确的表示之间来回会损失精度,但对于我们的应用程序,我怀疑这可能是一个可以接受的权衡。

我做了一些研究,看看目前有什么可能给我们一个很好的起点。开创性的“每个计算机科学家应该知道的关于浮点运算的知识”一文 ( http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html ) 让我看了其他一些文章, “超越浮点”(home.ccil.org/~cowan/temp/p319-clenshaw.pdf)就是这样一个例子。

谁能指出人们在其他地方使用的可能满足这些要求的其他表示示例?

我担心表示精确性的任何潜在收益(我们目前通过使用这个特定范围浪费了大部分浮点格式)将完全被从小数表示到浮点的四舍五入的要求所抵消-指向并再次返回。在这种情况下,可能需要直接使用这种小数表示进行算术运算才能从这种方法中获得任何好处。关于这一点的任何建议会有所帮助吗?

4

3 回答 3

4

不要使用2^16-1. 使用2^16. 是的,您的精度会稍微降低并浪费您的0xFFFF,但您将保证在转换为浮点时不会损失精度。(相反,当从浮点转换时,您将损失 8 位尾数精度。)

精度之间的往返转换可能会导致某些操作出现问题,特别是逐步求和数字。如果可能,请将您的定点值视为“脏”,并且不要将它们用于进一步的浮点计算;更喜欢从输入重新计算而不是使用定点形式的中间结果。

或者,使用 24 位。使用这种表示形式,只要您的值不下溢(即,只要它们高于2^-24),您就不会失去任何方向的精度。

于 2013-11-10T15:10:41.547 回答
1

1/x 不会在您的范围内分布不均吗?1/2 1/3 1/4 ..你不想代表1/2以上的数字吗?

这种事情在 Netcdf 中做了很多来对数据进行编码以节省空间。

const double scale = 1.0/65536;
unsigned short x;

x 中的任何数字实际上都是 x*scale

有关使用比例和偏移的更通用方法,请参见 NetCDF 中的示例:http ://www.unidata.ucar.edu/software/thredds/current/netcdf-java/tutorial/NetcdfDataset.html

于 2013-11-10T13:38:38.010 回答
0

查看此页面的“打包数据值”部分:

https://www.unidata.ucar.edu/software/netcdf/docs/BestPractices.html#Packed%20Data%20Values

于 2015-10-19T21:37:44.237 回答