[CONTACT]

[ABOUT]

[POLICY]

[ADVERTISE]

Aucbvax.fa.worksutcsrgv!utzoo!

Found at: gopher.quux.org:70/Archives/usenet-a-news/FA.works/82.01.21_ucbvax.5902_fa.works.txt

Aucbvax.5902
fa.works
utcsrgv!utzoo!decvax!ucbvax!works
Thu Jan 21 22:44:10 1982
WorkS Digest V2 #11
>From JSOL@USC-ECLB Thu Jan 21 22:41:56 1982
Works Digest	        Friday, 22 Jan 1982       Volume 2 : Issue 11
Today's Topics:	    Hard Copy Output - Not Needed?
               Query Reply - Everything In Main Memory
                         Multics - Quicksorts
----------------------------------------------------------------------
Date: 21 Jan 1982 0942-EST
From: WALKER at CMU-20C
Subject: hard copy
There is certainly no use for an optical character reader to insert a
machine-generated document into another machine, but what about all
the books, papers, etc already laying around?  Most of this stuff can
be safely thrown away (look around your office, or at least mine), but
a lot of it is relatively timeless.  It would be a royal pain to have
someone type in the Library of Congress by hand.
------------------------------
Date: 21 Jan 1982 1457-PST
From: BILLW at SRI-KL
Subject: Re: Large address spaces
Re: the whole world is not in main memory (for example my terminal).
Well, It could be, maybe it should be, and on a lot of workstations,
it IS.  DMA displays have all sorts of advatages over any other type
of display.  Its just that if the display bitmap takes 128K bytes,
and your processor only addresses 64K, you are in a lot of trouble.
WW
------------------------------
Date: 21 Jan 1982 09:03:26-PST
From: decvax!duke!unc!smb at Berkeley
Full-Name: Steven M. Bellovin
To: REM@MIT-MC
Subject: Re:  Multics
	From REM@MIT-MC Thu Jan 21 08:55:16 1982
	Via: duke!chico!ucbvax
	Date: 21 January 1982 01:34-EST
	From: Robert Elton Maas <REM MIT-MC AT>
	Subject: Re:  Multics
	
	To: chico!duke!unc!smb at UCB-C70
	
	Quicksort is N^2 worst case, so even in main memory it isn't
	good.  Thus it's a red herring. Anybody who would use it even
	when it all fits in realmemory (no thrashing) is a loser
	already and thrashing is beside the point.  Some other methods
	of sorting are n log n worst case, and some of them can be
	made to run in virtual memory with much localness of accessing
	so as to avoid thrashing if real memory is small, even tiny.
Quicksort is n*log n in the average case, and generally does quite
well, but that isn't my point at all.  You've made it for me -- that
some sorts "can be made to run in virtual memory with much localness
of accessing", i.e., that the program *must* be aware that it may run
in that environment, that awareness of the underlying structure *is* a
concern of the programmer.
------------------------------
End of WorkS Digest
*******************
-------
-----------------------------------------------------------------
 gopher://quux.org/ conversion by John Goerzen <jgoerzen@complete.org>
 of http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 
 Bruce Jones, Henry Spencer, David Wiseman.

NEW PAGES:

[ODDNUGGET]

[GOPHER]