Re: TDD for numerical algorithms

P.S. there are a lot of slow crappy programs out there, and I would be
willing to bet that more of them were written by folks who thought
they could write a better sort than by those who didn't ;-)

On Wed, May 26, 2010 at 10:00 PM, Adam Sroka <[email protected]> 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.
>
> The interesting thing is that when I keep the design simple I rarely
> have to go there, because I rarely find myself with a too slow app to
> begin with. Of course, I am primarily working with web sites and
> internal business apps. I understand that if you are doing high
> performance graphics for games (Which is what Richard does IIRC)
> optimizing is a bigger part of the job.
>
> I have also done the code kata of test-driving bubble sort. In that
> case I did test-drive a solution, and it ended up looking almost
> nothing like the canonical implementation. But, that feels contrived
> to me, because I know that if my tests are compelling me to sort
> something the real answer is the standard library .sort(). In Java I
> know that is a modified quicksort (or a modified mergesort, depending
> on which library class we are talking about.) I know that it was done
> pretty well by folks who know more about it than I do.
>
> I like the way they put it here:
> http://leepoint.net/notes-java/data/arrays/70sorting.html Writing your
> own sort is good education but poor professional practice. I think
> that is true most of the time for sort, and it is sometimes just as
> true for other algorithms like searches, encryption, random numbers,
> etc. The skill comes in knowing how to recognize the cases where it
> isn't true.
>
> On Wed, May 26, 2010 at 9:11 PM, George Dinwiddie
> <[email protected]> wrote:
>>
>>
>>
>> Adam, et al,
>>
>> Adam Sroka wrote:
>> > 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.
>>
>> I find that test-driving a particular algorithm is sometimes useful.
>> I'll agree that it doesn't feel the same as TDD, though. At the Floyd
>> Code Retreat, Corey Haines called this a form of Test First Development,
>> distinct from TDD. I think I like that distinction.
>>
>> - George
>>
>> --
>> ----------------------------------------------------------
>> * George Dinwiddie * http://blog.gdinwiddie.com
>> Software Development http://www.idiacomputing.com
>> Consultant and Coach http://www.agilemaryland.org
>> ----------------------------------------------------------
>>
>> 
>


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

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/