How can his use of $2- be construed as a loss of test integrity? It is used in exactly same way in both cases. If his test had changed ANY code (not possible since he's using the exact same /bcmark alias to test both), then you would be quite correct. But he doesn't, so you aren't.
Who cares if { $2- | dec %i } adds overhead? It's the
same overhead for
any test run; that fact alone factors it out of the benchmark as a consideration. Sure, it might pump up the total numbers, but it will pump them up exactly the same for every test on which that alias is used. Do you mean to tell me that your variables require no allocation of memory? (That's one form of overhead, isn't it?) Jerk's method doesn't...not one variable used, nothing but native identifiers used. Your method also tests variables. (Doesn't memory management count as overhead, too?) Furthermore, both of you are using the stack unnecessarily (more memory management) when you could have just as easily inlined the two algorithms and tested just them inside their own loops (iterating to 47 gazillion) with %start and %end after each.
Qualified remark (not having benchmarked it recently, I am unwilling to presume its veracity): the last time I checked, built-in $identifiers were faster than %variables of any sort.
With respect to your Radix sort (you never mentioned if you were referring to a LDS or MSD Radix sort: is that important to how your LSDs or MSDs are
not going to be sorted into their appropriate buckets?), Theta (you made no mention in there of big-O notation nor even asymptotic bounds, upper and lower bounds of resource usages, though you could have
but won't) and the 5 different methods of testing the sorting algorithm
that you're not going to test: ...
Where was I?
Oh yes, now I remember.
You are not testing $sorttok here, you are testing the RESULT of both the $sorttok and the $gettok it feeds. Then you are comparing the cumulative total time of that ENTIRE algorithm (not just some sorting algorithm you've (heard of|looked up|wrote a thesis on) somewhere) versus the results you achieve in your own algorithm. qwerty is quite right: mIRC isn't going to change its sorting method from one run to the next, nor is it going to spit out what the current sorting algorithm's name to verify/discredit anyone. If the two values were at all close (as your initial 0-result tests indicated), then it would make sense to check a compiled sorting routine's output based on input sorting order (or lack thereof) for further optimizational possibilities/problems.
As it is, they're not even close. :tongue:
