是否存在两个嵌套数组之间存在差异的计算有效检查方法？
我有两个2D的int阵列，并且长度相同，但是它们非常大。我想找到两个阵列之间是否至少存在一个差异。
注意：我不需要找出差异是什么，如果至少有一个差异，我只需要返回true，<代码> false 。
现在，我正在使用两个循环通过索引迭代，并检查arr1 [i] [j]！== arr2 [i] [j]，但这需要最差60秒案例由于尺寸。
有更好的方法来进行比较吗？
I have two 2D arrays of ints and are the same length, but they are very large. I want to find if there exists at least one difference between the two arrays.
Note: I don't need to find out what the differences are, I just need to return true if there is at least one difference else false.
Right now I'm using two for loops to iterate through the indices and check if arr1[i][j] !== arr2[i][j], but this is taking over 60 seconds worst case due to size.
Is there a better way to make this comparison?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
只要您维护相关的数据结构（嵌套数组），就不能比这更快，您就必须检查每个元素。
但是，您可能有条件地应用一些特定的优化：
我可以肯定的是，平面阵列更快地索引，您可以使用
i * width + j来维护相似的速度显然并不完全相同。如果其中一个阵列不经常变化，并且是您要检查的参考，那么您可能会通过哈希获得很好的结果。每次更改它时，您都会存储参考阵列的哈希（同样，它不得频繁），并且每次您需要进行检查时，都可以对一个新数组进行检查，您可以进行哈希测试阵列并根据计算的其他计算哈希。请注意，这可以给出误报，因此，如果匹配的哈希相匹配，则需要实际检查每个元素以确保它实际上是平等。
并请注意，以上不是或要实施，两者都会为您带来非常好的结果！
As long as you maintain the data structures in question (nested arrays), you can't get any faster than this, you have to check every element in general.
A few particular optimizations that you may conditionally apply however:
I'm fairly certain that flat arrays are faster to index, and you can use
i * width + jto maintain your accesors similar, though obviously not identical.If one of the arrays doesn't change often, and is so a reference you're checking against, you'll likely get very good results by hashing. You store the hash of your reference array every time you change it (again, it has to not be often), and every time you need to run your check against a new array you can hash he tested array and check it against the other calculated hash. Note that this can give false positives, so if the hashes match you need to actually check every element to make sure it actually is an equality.
And note that the above aren't either-or, implementing both will give you very good results!