From: Austin Ziegler Date: 2005-06-13T06:57:47+09:00 Subject: Re: python/ruby benchmark(don't shoot the messenger) On 6/12/05, Isaac Gouy wrote: > Austin Ziegler wrote: > -snip- > > Never *once* have I needed to implement an Ackermann function. Not > > once. In my entire career. I look at the crap that is on alioth and > > there's very little that represents common use. There's some neat > > things -- the new DNA transformation ones -- but exactly how many > > people will actually be using that in their work? > Never once needed to implement a recursive function? Not an Ackermann recursive. Only simple recursive. Most of the time, I haven't even needed that. There's an important point there. Indeed, I have sometimes gone in and changed recursive into iterative because it was too expensive to implement as recursion. But what are you really testing with this? If you want to test stack winding and unwinding speeds, then you're probably testing the wrong thing here. If you're testing something else, it's not clear. And that's the damnable thing about the whole alioth shootout -- you refuse to take an editorial stance anywhere (well, sort of) on the interpretation of the numbers, leaving them to stand on their own -- which leads to people making stupid assumptions about them. You state that you refuse to take an editorial stance, but you end up doing so -- both by what tests you accept for the shootout and by what implementations you'll accept. I stand by what I said, though: the alioth shootout is a waste of everyone's time. Frankly, I think it would be better if it were just taken down. > Some details are always specific to a problem domain and application, > but the same representations and approaches are used across problem > domains and across applications - yes the details are from DNA sequence > analysis, but the programs process ascii strings and hashtables. Perhaps. But more often than not, the approaches aren't perfectly portable. -austin -- Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca