[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference rusure::math

Title:Mathematics at DEC
Moderator:RUSURE::EDP
Created:Mon Feb 03 1986
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2083
Total number of notes:14613

851.0. "sorting rows in a 2d matrix" by --UnknownUser-- () Fri Apr 01 1988 08:58

T.RTitleUserPersonal
Name
DateLines
851.1post it...CHOVAX::YOUNGDumb, Expensive, Dumb ... (Pick Two)Fri Apr 01 1988 12:143
    Hmmm...  I think that your requirements are somewhat ambiguous.
    
    Why don't you post your algorithim if its not too long?
851.2COOKIE::WAHLDave Wahl: Database Systems AD, CX01-2/N22Fri Apr 01 1988 16:526
I can probably mail you some code once I know what you're doing.  In
particular, what's the type definition of the matrix and what are you
sorting on?

Dave

851.3Don't move rows, just indicesAKQJ10::YARBROUGHWhy is computing so labor intensive?Fri Apr 01 1988 17:398
If the sort is too slow, you are probably doing more data movement than 
necessary. Whatever it is you are sorting on, you should consider 
constructing an index vector, initially 1..n, which specifies the order of
rows and shuffling that vector to specify in what order the rows should be
moved (ONCE!) into another matrix. 

If you were doing the job in FORTRAN, you might be getting hit by page faults 
due to FORTRAN's storing matrices by column.
851.5Watch out for Q-sort's worst caseAKQJ10::YARBROUGHWhy is computing so labor intensive?Tue Apr 05 1988 13:1813
So what you have is actually 26 separate 16000-block sorts. I assume you 
want to output the grand sorted list. What I would do is (for first=a..z)
create an index vector of length 1..(actual no of entries in current bucket)
and use a randomized quicksort to shuffle the index vector (to minimize 
data moves), then write out the array according to the order given by the 
index vector. 

NOTE: Quicksort may be the fastest sort *on average*, but its worst-case 
behavior is terrible. If the 16000 entries are *already in order* you have
run into the worst-case situation for quicksort, which then becomes an
O(n**2) sort instead of O(nLogn). So unless you are using a randomized
version, you would be better off using a heapsort, which is O(nLogn) in
worst case. 
851.6COOKIE::WAHLDave Wahl: Database Systems AD, CX01-2/N22Wed Apr 06 1988 02:588
I know this isn't what you asked for, but I feel like I have to ask
it anyway.  Why are you using an unsorted array in the first place?
Is there something about the application which prevents you from
using a persistent order preserving structure like an AVL tree or 
binary tree, so the cost of sorting is spread out over the cost of
individual updates to the tree, rather than doing it all at once?

Just asking.