home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / pascal / 7846 < prev    next >
Encoding:
Text File  |  1993-01-04  |  3.1 KB  |  71 lines
  1. Newsgroups: comp.lang.pascal
  2. Path: sparky!uunet!gatech!taco!csemail.cropsci.ncsu.edu!samodena
  3. From: samodena@csemail.cropsci.ncsu.edu (S. A. Modena)
  4. Subject: Re: LARGE Sorts and such...
  5. Message-ID: <1993Jan4.204921.3217@ncsu.edu>
  6. Sender: news@ncsu.edu (USENET News System)
  7. Organization: Crop Science Dept., NCSU, Raleigh, NC 27695-7620
  8. References: <1993Jan3.222248.18162@news.acns.nwu.edu>
  9. Date: Mon, 4 Jan 1993 20:49:21 GMT
  10. Lines: 59
  11.  
  12. In article <1993Jan3.222248.18162@news.acns.nwu.edu> delusion@casbah.acns.nwu.edu (Albert Schmezer) writes:
  13. >    Hello all, again. I am in the midst of a large programming project,
  14. >and have come across an interesting stumbling block. I hope this isn't a FAQ.
  15. >If it is, could someone direct me to the source of the answer?
  16. >
  17. >    Anyways, for the question: How does one go about, in TurboPascal,
  18. >sorting an array of IMMENSE proportions? What I mean is that I am making a
  19. >database-type program, and I have at least 10,000 items in the database. How
  20. ......
  21. >temporary file on the harddrive? How slow is this? How would I even go about
  22. >doing this? Can I stick groups of 100 or so into an array and integrate the
  23. >sorts? How would I do this?! Is this slow, too?
  24. >
  25. >
  26. >    Thanx in advance!
  27. ><<delusion
  28. >
  29.  
  30. You are on the right track in your thinking.
  31.  
  32. Generally speaking (and remembering back to just ten years ago on the
  33. first micro I ever programmed on), a *good* sort utility takes a look
  34. at the file (data) to-be-sorted and uses some heurustics to guess-timate
  35. whether the data can be sorted in memory or must be sorted on-disk.
  36. If, on-disk, then it does a calculation to guess-timate whether the data
  37. is small enough for an efficient single pass...or should be broken into
  38. a series of small files to be sorted individually FOLLOWED by a MERGE
  39. of the sorted files.
  40.  
  41. Only *you* can make these design decisions, because only *you* know
  42. whether you are programming for the PARTICULAR computer you are working
  43. on OR if this program must ANTICIPATE everything from a dog-tired
  44. IBM PC with 256K and dual floppies (I have one right behind me) and 
  45. all the way up to what I'm programming on right now (33 MHz 486DX
  46. with 20 Megs RAM and two 12 milliSec hard drives totalling >300 MBs).
  47.  
  48. This decision and design process is the essence of software development,
  49. as opposed to "coding."  :^)  So you might come back with specific
  50. questions if you get stumped once you'vew decided what the design 
  51. parameters are going to be.  Good luck!
  52.  
  53. Steve
  54. ---
  55. +------------------------------------------------------------------+
  56. |     In person:  Steve Modena     AB4EL                           |
  57. |     On phone:   (919) 515-5328                                   |
  58. |     At e-mail:  nmodena@unity.ncsu.edu                           | 
  59. |                 samodena@csemail.cropsci.ncsu.edu                |
  60. |                 [ either email address is read each day ]        |
  61. |     By snail:   Crop Sci Dept, Box 7620, NCSU, Raleigh, NC 27695 |
  62. +------------------------------------------------------------------+
  63.          Lighten UP!  It's just a computer doing that to you.    (c)
  64. OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
  65.          
  66.  
  67.  
  68.  
  69.  
  70.  
  71.