> Or, perhaps it's more of "Handling sorting of data larger than available
RAM
> memory has been a fundamental problem of data processing since the dawn of
> computers.  Any "sort" PROGRAM (as opposed to a function) OUGHT to be able
> to deal with this, although finding one that handles 3G in reasonable
> timemight be a bit of a challenge."  (For this reason, it's relatively
> common for programs that need to sort large amounts of data to make
> "external" calls to the system sort utilities, rather than writing code
from
> scratch each time.  One of my first programming jobs involved porting such
a
> function (the API to call the system sort utilities) from fortran II on a
> GE4020 to Fortran4 on an IBM370...

A common way to deal with very large sorts, is to arbitrarily break up the
large unordered pile into smaller ones that can each be sorted more easily.
The final pass is then a merge of all the individual sorted piles.  This is
easy and doesn't require much memory because each input pile and the final
output are traversed sequentially.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads