🚀 go-pugleaf

In article <3718310F.1DB0@csolve.net>,
  Mike Monett <add@csolve.net> wrote:
> netnews@altavista.net wrote:
> >
> > In article <7f4grb$7ik$1@nnrp1.dejanews.com>,
> >   Robert AH Prins <prinsra@williscorroon.com> wrote:
> > > In reply to a private email from a person who knows he can interrupt me.
(but
> > > should have added to the tread...)
>
>   'Twas me  - hit the wrong button in Netscape. Sorry. By  the  time I
>   noticed, it was too late to do anything about it.
>
>   [...]

Don't worry, you're on the list of people who are allowed to send me private
emails. It's just that I'm currently at war with my accountant and this is
putting me under some stress. [For those without access to UK newspapers,
accountants in UK are the worlds best paid, and mine is trying to charge my
company an amount equivalent to about GBP 3300 per hour...]

>   >> If your  file  exceeds available direct access  memory,  you will
>   >> have to  settle  for a multipass merge sort,  in  very simplistic
>   >> terms:
>
>   >> - read in as many records as allowed by available RAM
>   >> - sort them and write them out to file 1
>   >> - read in a next bunch of records
>   >> - sort them and write them out to file 2
>   >> - repeat above until entire original file has been processed.
>   >> - open files created
>   >> - read one record from each of them
>   >> - write out the smallest of these and read the next record from the
>   >>   file that delivered it
>   >> - repeat previous step until all files have reached eof
>
>   [...]
>
>   Very good explanation. Thanks!
>
>   The key  is  to "write out the smallest of these and  read  the next
>   record *from the file that delivered it*". It didn't make  any sense
>   until that sunk in.
>
>   The next problem is the number of file handles. This might be a good
>   argument for not using the heap, which limits you to 64k chunks.
>
>   Instead, allocate  DOS  memory with int21, function  48.  This would
>   allow sorting in ~500k chunks. If you had 30 file handles available,
>   this would allow sorting files up to 15 megabytes before running out
>   of file handles.

Not true, even with just one(!) file handle you can sort any size file:

- open file 1
- read input until RAM full
- close file 1
- sort RAM
- open file 2
- write out sorted data
- close file 2

- open file 1 again, read until RAM (-one record) full & close file 1
- sort RAM
- open file 2 and read first record
- close file 2
- open file 3
- write out smallest of RAM/file 2
- if record from RAM
  repeat above,
- else
  close file 3
  open file 2, read next & close
  open file 3, seek eof
  write out smalles of just read/RAM

Etc, I suppose you get the picture. The process will be
slooooooooooooooooow... and I expect it to fail somewhere with record files >
2Gb

>   Thanks to  WIN9X, most machines come with 64 or 128 megs of  ram. It
>   seems you  could  use Himem to move data from DOS to  XMS,  and sort
>   larger files by using XMS instead of writing to the hard disk.

Yes, for pure DOS, but under Winduffs (or OS/2), which allow the use of XMS in
their DOS boxes, it would result in paging, eliminating the advantage.

>   Of course, the ideal would be to use flat real mode and do  the sort
>   directly in ram! Default to using Himem only when in V86 mode.

Robert
--
Robert AH Prins
prinsra@williscorroon.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own