Code center > Solved Bugs
Yet another overflow bug from Testlund
Botsareus:
ok guys here is an example of the last thing I ended up fixing. Please give me an example of how 'Unit Testing' would have helped me in the given situation because I still feel like I am missing something here:
The following code is for the Point2 mutations, the "Botsareus 1/14/2014" is where it crashed before.
--- Code: ---Private Sub Point2MutWhen(randval As Single, robn As Integer)
Dim result As Single
Dim mutation_rate As Single
'If randval = 0 Then randval = 0.0001
With rob(robn)
If .DnaLen = 1 Then GoTo getout ' avoid divide by 0 below
mutation_rate = .Mutables.mutarray(P2UP) / SimOpts.MutCurrMult
'keeps Point2 lengths the same as Point Botsareus 1/14/2014 Checking to make sure value is >= 1
Dim calc_gauss As Double
calc_gauss = Gauss(.Mutables.StdDev(PointUP), .Mutables.Mean(PointUP))
If calc_gauss < 1 Then calc_gauss = 1
mutation_rate = mutation_rate / calc_gauss
'Here we test to make sure the probability of a point mutation isn't crazy high.
'A value of 1 is the probability of mutating every base pair every 1000 cycles
'Lets not let it get lower than 1 shall we?
If mutation_rate < 1 And mutation_rate > 0 Then
mutation_rate = 1
End If
'result = offset + Fix(Log(randval) / Log(1 - 1 / (1000 * .Mutables.mutarray(PointUP))))
result = Log(1 - randval) / Log(1 - 1 / (1000 * mutation_rate))
While result > 2000000000: result = result - 2000000000: Wend 'Botsareus 3/15/2013 overflow fix
.Point2MutCycle = .age + result / (.DnaLen - 1)
getout:
End With
End Sub
--- End code ---
Before I simply had:
mutation_rate = mutation_rate / Gauss(.Mutables.StdDev(PointUP), .Mutables.Mean(PointUP)) and the value was going negative resulting in a negative overflow.
Numsgil:
--- Quote from: Botsareus on January 14, 2014, 05:09:58 PM ---It is just hard for me to write tests using code. Usually my brain is the test. Otherwise it seems like a waste of time for me, example:
a + b = c
Do I really have to test?
--- End quote ---
If you were writing the add function for a processor in machine microcode you'd absolutely want to test this. Does you add function work on positive and negative numbers? Does it handle 0 correctly. Does it handle 1 correctly. If you're using floating point numbers, does it handle infinities and NaNs correctly. If you're just literally typing a + b you probably don't need to test that. But then it's probably part of some larger calculation you should be testing.
Basically, if you're writing a closed algorithm, something that takes data in, does stuff, then spits an output, you should be unit testing it 100% of the time. If you're writing UI, networking, graphics, etc. stuff it's a bit more of a gray area, because it's difficult to isolate your code from random hardware issues and constantly iterating designs. For graphics, for instance, do you do a per-pixel check? What if one of the pixels is a slightly different shade of blue? Is that a failure? But you should definitely be unit testing the smaller pieces that make up the larger whole even then.
...
For the example you have, you'd probably want to break the random away from the function and have the function take as input 1 or 2 random values. Then you can test to see what happens when you pass in negative values. Basically non deterministic factors are the enemy of unit testing. You usually want to isolate them from as much of the code as possible to allow for deterministic testing. Unit testing isn't just a matter of writing the tests, it often requires rethinking how to approach a problem in a way that's amenable to testing. That's usually a good thing, as it forces you to write code in a more modular way and really think through dependencies.
It does take more upfront effort and thought, though.
Peter:
--- Quote from: Botsareus on January 14, 2014, 05:24:13 PM ---Also, how am I supposed to write a test that is designed to fail? There is only one way that
--- Code: ---a + b = c
--- End code ---
and infinite ways
--- Code: ---a + b <> c
--- End code ---
--- End quote ---
First write a test, test will fail, then write the code.
Botsareus:
That is some really good advice, thanks guys.
I will have to print this and read it over a couple to fully get it.
Navigation
[0] Message Index
[*] Previous page
Go to full version