0

我正在尝试通过以下算法通过 vba 生成一堆随机排列：

Function RandNumber(Bottom As Integer, Top As Integer, _
                Amount As Integer) As Integer()

Dim iArr As Variant
Dim i As Integer
Dim r As Integer
Dim temp As Integer
Dim bridge() As Integer

'Application.Volatile

ReDim iArr(Bottom To Top)

For i = Bottom To Top
    iArr(i) = i
Next i
Randomize
For i = Top To Bottom + 1 Step -1
    r = Int(Rnd() * (i - Bottom + 1)) + Bottom
    temp = iArr(r)
    iArr(r) = iArr(i)
    iArr(i) = temp
Next i

ReDim Preserve bridge(1 To Amount)
For i = Bottom To Bottom + Amount - 1
    bridge(i - Bottom + 1) = iArr(i)
Next i

RandNumber = bridge

End Function

本质上是RandNumber它根据用户提供的底部和顶部值随机给出一个排列。示例RandNumber(1,2,1)将是1或2随机的。

现在我正在通过以下例程测试此功能

Sub RandNos()
Dim z() As Variant
ReDim Preserve z(1 To 2560)
For i = 1 To 2560
z(i) = RandNumber(1, 2, 1)
Next i
For i = 1 To 2560
ThisWorkbook.Sheets("Sheet2").Range("A1").Offset(i - 1, 0) = z(i)
Next i
End Sub

令我大吃一惊的是，“随机”数字在 256 次运行后正好重复！（好的，i上面的值 2560 并不完全是巧合。我怀疑在 256 行周围有一些模式，因此取i为 2560）

此外，当我用稍微修改的子程序测试上述函数时：

Sub RandNos2()
For i = 1 To 2560
ActiveSheet.Range("A1").Offset((i - 1) Mod 256 + 1, Int((i - 1) / 256)) = RandNumber(1, 2, 1)
Next i
End Sub

模式消失了。（至少在 256 个值之后重复的模式消失了。不确定是否会出现另一种模式）。

现在根据我的知识，Randomize应该通过生成适当Randomize的种子来控制随机性，并在 vba 中从timer. 所以我的假设是，在第一RandNos()个子程序中，更新发生得如此之快，以至于种子的更新速度不够快。当我使用第二个子例程进行测试时，模式消失的事实，因为在第二个例程中，excel 在工作表中编写代码需要更长的时间，因此给代码一些机会来更新timer随机数的种子 -支持我的假设。

所以我的问题是

  1. 我的假设是否正确。
  2. 我是否仍希望在 Excel VBA 中生成“随机”模式。
  3. 我是不是用错了Randomize这里

提前感谢您对此问题的建议。

编辑：评论中的建议之一是我们应该Randomize只打电话一次。我试过这样做，它似乎工作。但是，我仍然想知道使用Randomize上述方法出了什么问题。

4

3 回答 3

4

在回答您的编辑时，您的假设是正确的。

随机化花费时间并生成种子。种子只是 Rnd 的起点。

但是，请注意 Randomize 不是一对一的，这意味着对于 Randomize 的任何给定输入（即时间），它不会每次都生成相同的种子。您似乎已经发现 Randomize 对于每个给定的输入都有一个由 256 个种子组成的序列。因此，您会得到一个由 256 个数字组成的重复序列，这些数字本来应该是随机的，但显然不是。

参考：Randomize 和 CS 类的 VBA 帮助页面

于 2012-12-03T19:58:18.170 回答
3

你应该只调用Randomize一次。如果RandNos()被多次调用，Randomize则在调用的方法中使用RandNos()。

于 2012-06-17T18:59:26.720 回答
0

只是为了将来参考遇到此问题的任何其他人，我决定尝试“减慢”子例程，以使系统计时器重置。Application.wait效果不佳，但我发现通过debug.print在调用上方包含一个简单的行randomize，它会减慢执行速度，使其不会每 256 次重复一次。这不会显着增加子例程的整体运行时间。对于那些不介意牺牲一点优化以非常简单地修复伪随机性的人来说，这只是一个想法。

于 2017-05-14T02:32:30.290 回答