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/