Re: TDD for numerical algorithms

On Mon, May 24, 2010 at 8:47 PM, Jim Murphy <[email protected]> wrote:
>
>
>
> ----- Original Message -----
> From: Adam Sroka
> To: [email protected]
> Sent: Monday, May 24, 2010 10:24 PM
> Subject: Re: [refactoring] TDD for numerical algorithms
>
> On Mon, May 24, 2010 at 6:35 PM, Richard <[email protected]> wrote:
> >
> > How would you use TDD to implement the Mersenne twister random number
> > generator? <http://en.wikipedia.org/wiki/Mersenne_Twister>
> >
> > In particular, I'm curious as to what kind of test cases you would write.
> >
>
> It's the wrong question. TDD is an evolutionary process. Like all
> evolutionary processes it is impossible to reverse engineer it for any
> non-trivial problem. That is to say: there is no good answer to the
> question "What set of tests do I need to write to arrive at the given
> solution?"
>
> That said, there are certainly any number of sets of tests for which
> Mersenne Twister is a potential solution. There may even be some set
> of tests for which it is the simplest possible solution. And, any
> given set of tests that could be solved by this algorithm could also
> be used to test drive a solution that may or may not be as effective
> and may or may not trivially resemble the given solution.
>
> I disagree with this answer. If a customer comes to you and wants a Mersenne Twister coded in, say, C++, you can't very well give him/her something else as a "potential solution". You could discuss the requirement for the particular algorithm with the customer, and offer possibly simpler, cheaper alternatives. But if the customer says "I want X", you either build X or you find alternate employment.
>

That's a strawman. TDD is a problem solving activity. "Write a
Mersenne Twister in C++" is not a problem to be solved. It is a
scribing activity. If you are smart you will just download one from
the web.

FWIW, I will happily find a job other than that one.

> To respond to the original question, when a specific algorithm is involved I believe you need to provide additional means to query the state of the process, and then test that the desired state has been reached after each step of the algorithm. On the other hand, if all that is required is an equivalent algorithm, you would need to determine what "equivalent" means and test for that.
>

Presumably there is some problem to be solved for which Mersenne
Twister is one possible solution. If you are familiar with
implementing Mersenne Twister you can start test driving towards a
solution and pretty quickly determine whether or not Mersenne Twister
is the simplest one. However, it is unlikely that you can guarantee,
for any non-trivial problem, what the answer will be.

It's like the bowling game. There are any number of possible ways to
solve the bowling game, and some of them are very simple. If you test
drive it you will probably get a different answer each time (I do.)
That is why asking the question, "what is the set of tests that will
drive me to /this/ solution to the bowling game?" misses the point by
a few miles.

BTW, testing intermediate state in order to drive a particular
implementation is not TDD. TDD is concerned with the behavior of the
objects in your system. Could I write a test that says, "line 6 of the
program shall say ..."? Sure I could, and it would compel a particular
implementation, but it would not even resemble TDD.


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

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/