home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.asm.x86      Ahh, the lost art of x86 assembly      4,675 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 2,868 of 4,675   
   James Van Buskirk to Terje Mathisen   
   Re: Process at read-in time, or use post   
   19 Jul 17 18:28:02   
   
   From: not_valid@nospicedham.comcast.net   
      
   "Terje Mathisen"  wrote in message news:okoeol$ikv$1@gioia.aioe.org...   
      
   > OK, let's go through it:   
      
   > A priority queue is perfect if you have to be prepared to spit out an   
   > ordered list any any point in time, it carries a cost of O(log(n)) for   
   > both insertions and deletions (with n = 40 here, so the log(n) term will   
   > be ~6) for most operations.   
      
   > Unless you also maintain a separate #40 marker, i.e. the current cutoff   
   > point, you will carry that log(40) cost for all new records, _including_   
   > all those that fall outside the top 40 range!   
      
   > I.e. the naive version will blindly insert the new record and then   
   > delete the current #41 to bring the total back to 40.   
      
   > If the total count is large (i.e. >= 400) at least 90% of all new   
   > records will be discarded immediately at O(1) cost as long as you have   
   > that cutoff point available. At that point the difference between a   
   > O(log(n)) and a O(n) algorithm is a fixed number (6/(40*0.5) =~ 3).   
      
   Going back to Robert Wessel's post, he suggests building the N=40   
   heap in reverse sort order so that the current #40 will lie on top of   
   the heap.  Then each new element need only be compared with the   
   heap top, and for random data the new element will be discarded   
   at no further cost all but roughly N*ln(M/N) times.   
      
   If the new element is better than the current #40, it gets inserted   
   by replacing the top of heap element followed by a percolate down   
   to restore the heap condition. A heap of size N=40 may require up   
   to 10 comparisons to percolate down compared to an average of   
   20 data movements for a sorted array.  If he ever wants to get   
   bigger N, it will be easy to stick with the heap.  Besides, O.P. said   
   he already has efficient heapsort code at hand, so he has very   
   little work involved in adapting it to the operations required to   
   build, maintain, and read out the heap.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca