Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!seismo!dimacs.rutgers.edu!aramis.rutgers.edu!paul.rutgers.edu!njin!limonce From: limonce@pilot.njin.net (Tom Limoncelli +1 201 408 5389) Newsgroups: comp.sys.amiga.programmer Subject: Re: Combsort algorithm Message-ID: Date: 9 May 91 03:57:28 GMT References: <1193@cbmger.UUCP> <1991May3.201243.7959@watdragon.waterloo.edu> <1991May6.155148.1201@zorch.SF-Bay.ORG> <231b3678.673637576@fergvax> Organization: Drew University - Madison NJ Lines: 28 In article mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > A closer-to-fair comparison would be to write your own quicksort for > sorting a fixed-size array of known object types. I cheated, and >[...] > comb-sort of 100000 elements: 42.46 seconds > qsort of 100000 elements: 27.12 seconds If you want to be even more closer-to-fair you wouldn't give results for only sorting one amount of numbers. You should really show a graph of how they work on 1000, 2000, 3000, 5000, 10000, 15000... (note the logorithmic increase) elements. Of course, if you want to be the most accurate (by computer theory standards) you wouldn't even run the program! You'd just figure the O() of the function. > In reality, I'll continue using qsort(), even though I can get faster > results by handcoded routines. When a profiled run of the code shows > that the serious delays are caused by the qsort, I'll change it to > something faster, and chosen for the problem at hand. I now do just about all my programming like that. I don't think I've written a new line of code in years. :-) -- Tom Limoncelli tlimonce@drew.edu tlimonce@drew.bitnet 201-408-5389 Three witches making a potion. One asks, "A Liza Minnelli record, light beer, poppers, Frye boots; what's this spell for anyway?"