gnuplot 4.6和gnuplot 5.0之间迭代的原因不明 [英] Unexplained differences in iteration between gnuplot 4.6 and gnuplot 5.0

问题描述

在尝试回答涉及需要迭代日期的gnuplot问题时，我被告知我的解决方案不适用于gnuplot 4.6。在调查原因时，我注意到gnuplot 4.6和gnuplot 5.0如何处理相同的迭代构造有一个奇怪的区别。

考虑这两个迭代表达式

 为[i = 396835200：397094400：86400] {print i}为[i = 396835200：397008000：86400]执行
; {print i在$ gnuplot 5.0中，第一个产生
  396835200 
 396921600 
 397008000 
 397094400 
  
，第二次产生
  396835200 
 396921600 
 397008000 
  
但是在gnuplot 4.6中，第一个只生成前两个数字，第二个生成一个额外数字（397094400）。
 
 
 
为什么会这样？根据gnuplot中迭代的定义，gnuplot 5.0的行为是正确的。是否有在gnuplot 5.0中修复的错误？ 
 
 
 
我怀疑它可能与整数溢出有关，但我认为这些数字不足以触发它（它们都很容易适合32位有符号整数）。
 
 
 
我还怀疑迭代中可能有变化，因此使用<来检查上限。在版本4.6和< =版本5.0中，但仍然无法解释这一点（如果这些表达式的4.6输出被切换，它几乎）。
 
 
 
为什么这些版本的版本表现不同？任何对发布说明中的更改或源代码更改的引用都将不胜感激。
解决方案
看起来我设法找到了回答自己。这显然是gnuplot中出现的一个错误，并在5.0版本中得到修复。
 
 
 
实际错误在gnuplot错误报告中报告为错误编号 1429 ，其描述大致相当于我的描述，以及 1358 。
 
 
 
这是在版本中修复的5.0rc1和4.6版补丁级别6。
 
 
 
我不会在这里重复源代码，因为我不知道许可限制，但是有一个变化 next_iteration 函数中的文件 parse.c ，其中添加了一个补丁以防止因将两个大数字相乘而导致溢出（显然需要一个类似的补丁）至少另一个地方）。
 
In trying to answer a gnuplot question that involved the need to iterate over dates, I was told that my solution didn't work with gnuplot 4.6.  In investigating why, I noticed a strange difference in how gnuplot 4.6 and gnuplot 5.0 are handling the same iteration construct.

Consider these two iteration expressions
do for [i=396835200:397094400:86400] {print i}
do for [i=396835200:397008000:86400] {print i}
In gnuplot 5.0, the first produces
396835200
396921600
397008000
397094400
and the second produces
396835200
396921600
397008000
but in gnuplot 4.6, the first produces only the first two numbers and the second produces one extra number (397094400).

Why is this happening?  The gnuplot 5.0 behavior is correct according to the definition of iteration in gnuplot.  Was there a bug that was fixed in gnuplot 5.0?  

I had suspected that it may be related to an integer overflow, but I don't think these numbers are quite large enough to trigger that (they all easily fit in a 32 bit signed integer).

I had also suspected that there may have been a change in iteration so that the upper bound was checked using < in version 4.6 and <= in version 5.0, but that still wouldn't explain this (it almost would if the 4.6 outputs of those expressions were switched).

Why are these do versions behaving differently here?  Any reference to changes in the release notes, or source code changes would be appreciated.
解决方案
It looks like I managed to find an answer myself.  This is apparently a bug that appeared in gnuplot and was fixed in version 5.0.

The actual bug is reported at the gnuplot bug reports as bug number 1429 with a description roughly equivalent to mine, as well as a more detailed explanation of the fix in 1358.

This was fixed in version 5.0rc1 and version 4.6 patchlevel 6.

I won't repeat the source code here, as I don't know about the license restrictions, but there is a change in the file parse.c in the next_iteration function, where a patch was added to prevent an overflow caused by multiplying two large numbers together (and apparently a similar patch was needed in at least one other place).

                        
这篇关于gnuplot 4.6和gnuplot 5.0之间迭代的原因不明的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！