Re: TDD for numerical algorithms

Anthony Williams <[email protected]> Tue, 01 Jun 2010 08:44:35 +0100
Newsgroups gmane.comp.programming.refactoring
Message-ID <[email protected]>
George Dinwiddie <[email protected]> writes:

> Adam Sroka wrote:
>> That's a nice distinction, and I would put it similarly. It is a form
>> of Test First, but it is not TDD.
>> 
>> I have done that before, but it is not usual for me. I generally
>> ignore algorithm design preferring to focus on the business problem
>> exclusively until I have some performance need that compels me to
>> optimize. Then I would use a profiler to find bottlenecks, write some
>> performance tests around those bottlenecks, and optimize them until
>> the performance tests passed consistently.
>
> Optimization is not the only reason to choose a particular algorithm.

It certainly isn't. Random number generators often have very different
distribution and randomness properties, for example.

> In the morning session in Floyd, I co-TDDed three different approaches 
> to Conway's Game of Life.  

And TDDing Mersenne Twister is no different to TDDing the Game of
Life. In each case you have a set of rules for determining the
subsequent state from the prior one. In the case of Game of Life, all
the state is exposed in the game map, but in the case of Mersenne
Twister there is both the internal state and the visible sequence of
random numbers. TDDing Mersenne Twister would therefore need access to
the internal state.

As with all TDD, the tests would be a sequence of "given state X,
operation Y produces state Z". The precise implementation is not pinned
down, just the input and output states. I don't know the details of the
Mersenne Twister algorithm but I presume there are more interesting
tests than just specific input and output numbers. Otherwise you just
end up with one big table-driven test --- these input states map to
those output states.

Maybe you could split the implementation up a bit, with the final
tempering being tested separately from the sequence generation, for
example. For more complex algorithms there may be lots of sub-parts that
can be tested in isolation.

Anthony
-- 
Author of C++ Concurrency in Action     http://www.stdthread.co.uk/book/
just::thread C++0x thread library             http://www.stdthread.co.uk
Just Software Solutions Ltd       http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/