Open fsolleza opened 3 years ago
A simpler alternative is that wherever ClampedRandomWalkDistribution
is initialized by common.CWD(0, 1000, common.ND(50, 1), 0)
, instead, it should be initialized by common.CWD(0, 1000, common.ND(0, 1), 50)
. See for example, pkg/data/usecases/common/usecases/devops/redis.go
Relevant Files
pkg/data/usecases/common/distribution.go
Problem: If you instantiate a
ClampedRandomWalkDistribution
bycommon.CWD(0, 1000, common.ND(50, 1))
, andAdvance()
enough times, you'll constantly generate 1000 at some point. I don't know if this was the intent ofClampedRandomWalkDistribution
but it doesn't seem like that's what was expected. Instead, the expectation was to have a random walk with a mean around 50, but never went below 0 or above 1000.Diagnosis: The problem lies in that the mean returned by the
NormalDistribution
is around 50. This frequently positive value is added to theState
of theClampedRandomWalkDistribution
during eachAdvance()
. At some point,State > 1000
which results inState = 1000
. Because the mean of the underlyingNormalDistribution
is 50, it's unlikely thatState
becomes less than 1000 after this happens.Potential solution:
ClampedRandomWalkDistribution
should always be initialized withcommon.ND(0, stdev)
wherestdev
is the standard deviation needed.ClampedRandomWalkDistribution
should also have anOffset
attribute. If the random walk should be around some mean value, thenGet()
should returnOffset + State
. Adjustments to theMax
andMin
cutoff are also required.Other notes: A similar issue exists with
RandomWalk
however this isn't totally incorrect even if the behavior is not what I think was intended. IfRandomWalk
was initialized withcommon.ND(50, 1)
, thenRandomWalk
will take steps with a mean of +50. As a result,RandomWalk
would be almost always monotonically increasing (withmean >> 0
). Overflow issues not withstanding.