Final Standings for Contest #3: Bucketsort |
Name | Web site | Entry | |
1. Jonah Cohen and Kirk Meyer | ComAsYuAre@aol.com KirkMeyer@bigfoot.com |
http://jonah.ticalc.org http://www.bigfoot.com/~kirkmeyer/ |
53 bytes |
2. Hideaki Omuro | crashman@affinix.com | http://lfx.org/crashware/ | 55 bytes |
3. Joshua Seagoe | rabidcow@juno.com | N/A | 65 bytes |
4. Mike Heckenbach | mheckenbach@yahoo.com | N/A | 69 bytes |
5. Francis Huang | francishuang@hotmail.com | N/A | 74 bytes |
6. Scott Dial | wrath@calc.org | http://tcpa.calc.org | 97 bytes |
Booby Prizes |
Ever pushing the limits of z80 code optimization, some people like to try doing the same with the rules of the contests. The following people, who actually took the time to do this, get credit here. :) Kirk Meyer and Jonah Cohen - Soon after this contest was first announced, they presented me with a routine which fulfilled all the requirements of the contest, ie. it sorted BC 16-bit integers at location ARRAY, except for one minor detail... it wasn't a bucketsort. Jonah pointed out to me that although the name of the contest was "Bucketsort" and I had clearly given the algorithm in which to implement it on the contest page, nowhere did I say that you must actually use it. You wascally wabbits... :) Since then, they actually have refined the routine so that it's even smaller now, and you can see it here: Bubblesort in 30 bytes, by Jonah Cohen and Kirk Meyer. Hideaki Omuro - When I said that the routine must sort BC elements, I meant BC as in the register pair, not BC as in the hexidecimal value $BC (188). Needless to say, it was a creative interpretation, although he couldn't quite explain how the example on the contest page had only seven elements. Nice try though. $BC element bucketsort in 46 bytes, by Hideaki Omuro. |