collide函数的循环中一个奇怪的错误

[Tashkent]

@xiao灰灰 我只把不会引起精度误差的部分做了向量化

[swmore]

我算是身经百战了. 1.5 * 一个单精数应该不会带来一个特别明显的精度损失. 可能就跟double的加法差不多.
另外神威的单双精在寄存器里格式是一样的.

另外16年PAC组委会也傻逼呵呵的非得给一个单精程序让优化大家最后向量化的精度都hold不住.
然后我还证明了他们的数据不足以在单精下hold住精度, 为此我还用Java的BigDecimal重写了一遍程序验证了到底是谁的程序不准, 然后他们一时半会不改.
然后我辛辛苦苦调了半天运算顺序终于调到了跟他们一样的误差, 结果他们又把程序改成双精了 .
办优化比赛这种事情, 我认为, 用单精其实有风险的.

其次, 如果你觉得单精有问题, 可以尝试用gmp啊, BigDecimal啊之类的超高精数学库算个结果出来打组委会的脸.

[popo]

@Tashkent 首先collide函数的向量化我是做过的，与主核的精度误差是可以达到要求的，此外，1.5*value 这个我真的不知道有什么误差。如果你真的有疑问，上实验上数据。

[xiao灰灰]

@popo 我碰到的问题和楼主的问题类似，
问题简述一下，这是加入从核计算后collide.c的最后一步计算Nodes的过程，此时最后跑完的程序的结果是被验证程序认证为correct的。但如果将其中的1.0改成1.0f。

最后的结果验证程序认证为wrong。err.log基本和楼主的一样。

[xiao灰灰]

@tashkent 好的，感谢，我也是在这里卡住了，

[xiao灰灰]

@popo
这是只改这一处最后程序结束后生成的err.log。

[popo]

@xiao灰灰 说实话我真的不知道1.0f，编译器会给翻译成什么（ps:真的想测试，在外面定义个float型变量float one=1.0;）。此外，1.0 在寄存器里的形式是0x3ff0 0000 0000 0000 (单双精度是一致)（这个事实你可以好好查查文档）。所以我就搞不懂了为什么你们说把1.0的精度改一下，就发生精度大逆天的事。建议你可以把相应的函数翻译成汇编看看，看看1.0f翻译是否有问题。

[xiao灰灰]

@popo 额，我只是陈述一个遇到的问题，当然也可能是代码写的不行，竟然发生了这么大逆天让官方都搞不懂的事，还是感谢你的建议。

[popo]

@xiao灰灰 额，我也是陈述一个事实，有问题讨论很正常。如果真的觉得程序有bug，小例子+实验数据，我们会去check我们的程序的。有的人把问题放上来，没示例没数据，贴上一个不明所以的图，所以问题的诊断肯定不准确。当然为了隐私，也可以在bbs上私聊。

[lannnnn]

此回复已被删除！