Distributed.net Starts New Project
drydorn writes "Today, distributed.net will officially begin its next distributed computing project. Visit their Optimal Golomb Rulers project page for more details. Their first ruler length will be 24 marks, known in D.net lingo as OGR-24. " And, remember, your mantra: I must sign up for Slashdot Team. I must crack keys. You can grab your client here, which includes documentation on installation, what clients do, etc. etc.
I've been getting sick of RC5-64 (over 2 years now, and no end in sight) and SETI just doesn't interest me. Finally, a contest I can sink my teeth into AND has real, usable results.
After the huge publicity surrounding SETI@home and the various arguments for and against it we've now got a project which has *real* astronomical applications.
OK OK I will concede that SETI@home has a small chance of finding alien life, but, the chance is still remote and the amount of data that they are processing is miniscule compared to what we really need to be doing to seriously have a chance.
Large OGR's will of course help improve the sensitivity of Long Baseline arrays and other sensors, and therefore improve the quality of data produced. So... who knows - maybe running your CPU on this will help the search for extra terrestrial intelligence more than running seti@home.
Personally I'm waiting for distributed.net to help the Spaceguard foundation save the world from cosmic hazards so that other alien races will have someone to talk to in the future.
Perhaps annother way for companies to generate revenue would be to include sufficiently generic distributed computational software with their clients. This kind of app could also appear in web pages as a Java applet. (I would, of course, advocate an option to turn it off, and "nice"ing of all processing) Imagine what kind of stock market analysis or data mining one could do with ICQ or yahoo.com so enabled. Companies would pay good money for access to such a powerful processing force.
Thank you for not thinking.
If you are interested in genetic programming take a look here for more info.
--
Hmm... And all this time I thought that 'Hemos' was Jeff Bates, now you claim that 'Hemos.' is Jeff Bates. I, sir have met Jeff Bates, and you are no Jeff Bates. ;o)
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
The distributed computing project I'd most like to see get of the ground is The Tierra Project.
This project is exploring digital evolution. Start off with a bunch of organisms and breed them with genetic algorithms. See how they fare.
Then, and this is where it gets interesting, an organism can migrate from one host to another, possibly taking better advantage of the environement there. What kinds of digital ecologies will appear? What kinds of emergent behaviour will be encountered?
It's actually much more complex than that. If you're curious, I recommend reading the introduction.
--
I just checked the d.net homepage and it now says that they're starting on tuesday.
Wonder what happened there, I guess I'll have to go onto irc and ask.
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
If all you can do is compare two keys at a time, to tell which one is bigger, then any sorting algorithm has a worst case of O(n lg n). And, since there are already algorithms that achieve this worst case, yes, we've found the best there is.
Not really. Quicksort has the same worst case and "average" (from a analytical, random input standpoint) performance as mergesort, but yet quicksort performs better "in practice". Worst case or even average case analysis doesn't tell you everything.
Does anyone know if D.Net's OGR client uses some sort of eligant mathematical technique, or is it just another brute force effort?
That's wrong. Mergesort is O (n log n) worst case. Worst case quicksort is Omega (n^2). And to make it worse, common implementations of picking the pivot element (first element, last element, median of the first three elements) have sorted inputs as their worst case (that is, they produce their own worst case input). Even if you pick a pivot at random, there is a non-zero chance you always pick an extreme, leading to quadratic behaviour.
Now, you *can* find a median of a set in linear time, and using such a method to find the pivot leads to a worst-case O (n log n) sorting algorithm. However, the overhead is so much, the resulting algorithm will be slower, more complicated, and certainly less elegant than either mergesort or heapsort.
References:
Knuth, D.E: The Art of Computer Programming, Vol III, Sorting and Searching, 2nd edition, Addison-Wesley, 1998. ISBN 0-201-89685-0.
Cormen, T. H., Leiserson, C. E. and Rivest, R. L.: Introduction to Algorithms MIT Press, 1990, ISBN 0-262-53091-0.
Hoare, C.A.R.: "Algorithm 63, Partition; Algorithm 64, Quicksort" Communications of the ACM, Vol 4, 1961, p 321.
-- Abigail
That's wrong. Mergesort is O (n log n) worst case. Worst case quicksort is Omega (n^2).
Right, I forget. But the point remains that worst case or average case analysis doesn't tell you everything you need to know about the algorithm's performance - even though (as you point out) quicksort has an inferior worst case performance, it performs better 'in practice'.