Heh, you don't get it, you never will. As in many times in the past, the point is lost deep in your technical, 'advanced' but essentially irrelevant and misleading explanations. Let's examine a part of your code that contains the most serious error:
var %start = $ticks
.echo -q $jerk_min(%nums)
var %end = $ticksYou record the $ticks difference from just one run of $jerk_min(%nums) and you expect accuracy... guess what, /bcmark 1 max1 <list> (and max2 for many inputs) always reports 0 milliseconds on my computer. %end - %start will always be 0, so you don't record
anything. Apparently, my computer needs less than a msec to run /max1 <some list> (or $jerk_min(%nums) for that matter). 10000 * 0 = 0 though. On a fast computer, you could end up with %jerk_ticks being 0 when your benchmark ends. If you don't understand what I'm saying and why what you did is wrong there's not much that I can do. However, this is the first thing you should be taught in your benchmarking class.
Regarding $2-, yes, $2- adds a little overhead but it's a very small error factor; I was aware of it and certain that this error wouldn't alter my results, I just used it because I think /bcmark is a handy and reliable way to benchmark various aliases. Besides, your code also benchmarks an irrelevent item, the %nums variable (remember that you call $jerk_min(%nums) and not $jerk_min(1 2 3 5748 32154 7843) for example). Do you think it's ok to include %nums in the benchmark but it's not ok to include $2- or you just didn't notice? You can change my code around and benchmark the "real thing" but the results won't change.
As for the rest of the blabla about Radix algorithms etc, they have nothing to do with the issue. Sorting is done in C, it's pretty much a constant-time routine compared to mirc script. But we've already been through that...
