HDTenEightyP/NetNews huggingface dataset:
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.programming
Subject: Re: Graphics in C
Date: 1 Jan 93 00:52:55 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <1992Dec31.224521.24607@netcom.com>, whedon@netcom (Bill Whedon) writes:
>In article <1992Dec29.205122.23878@organpipe.uug.arizona.edu> dave@cs.arizona.edu (Dave Schaumann) writes:
>>In article <C00uI5.5vr@ocsmd.ocs.com>, mark@ocsmd (Mark Wilson) writes:
>>>Does anyone have any sources for source code for displaying graphics
>>>using C?
>>
>
>Smartass college child responds with something about Bezier curves.  Well, he
>did spell it correctly...

[the rest of Mr. Whedon's diatribe deleted]

Mr. Whedon's vitrolic reply to my post prompted me to go re-read it.
Frankly, I don't thing it merits such a response.  No, I was not overly
polite about it, but I did indicate that Mr. Wilson might be better
served by asking his question elsewhere.  (Given the existence of
a large number of news groups with "graphics" in their name, along
with a large number of groups dedicated to ibm machines and operating
systems, I really do wonder how Mr. Wilson decided "comp.programming"
and "comp.lang.c" were the best places to ask his question...)


The "peeve list" I appended might have been out of hand; but surely
orders of magnatude less so than Mr Whedon's reply.  If Mr. Wilson
or anyone else was offended by my post, I apologize; it was certainly
not my intent to offend anyone.  However, my original point still
stands: the machine specific groups are the appropriate place to ask
machine specific questions.

As for Mr Whedon, I might suggest he try to take posts to Usenet a bit
less personally.

ObGraphicsProgramming:
	A very good text on graphics programming is _Computer Graphics:
	Principles and Practice_, bye Foley et.al. (ISBN 0-201-12110-7)
	It contains discussion of everything from line-drawing algorithms
	to the implementation of 3D rendering systems.

	Moreover, those interested in the specifications of GIF or other
	graphic formats should follow up the pointers in the comp.graphics
	FAQ, which gives ftp sites where such things can be found (along
	with pointers to archives for various graphics packages).

-- 
Dave Schaumann			dave@cs.arizona.edu
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.programming
Subject: Re: Graphics in C
Date: 29 Dec 92 20:51:22 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Followup-To: alt.gimmie-a-break
Organization: University of Arizona

In article <C00uI5.5vr@ocsmd.ocs.com>, mark@ocsmd (Mark Wilson) writes:
>Does anyone have any sources for source code for displaying graphics
>using C?

I have a nice program to draw Bezier curves that I did for a graphics
class last spring.


>Microsoft C 7.0 or Borland C++ OK...  I am principally
>interested in putting up PCX graphics, or perhaps GIF; this is
>for PC-based applications.

Whups.  Too bad.  My code works nice under X, though.  If your
interest is limited to only one platform, why not use the groups
specifically for discussion about that platform?

>(NOTE: this same subject was posted in comp.lang.c; figured I'd try here,
>too.)

Peeve #1: there are so many peesee dweebs that think the whole friggin'
	net is their personal playground.

Peeve #2: People who post the same friggin' message multiple times to
	different news groups instead of cross-posting once.

Peeve #3: Eye-bee-em coins "PC" to mean "Personal Computer" (a supposedly
	generic term) but all the peesee dweebs use it like a specific
	name.

-- 
Hey, everybody -- somebody said `mattress' to Mr. Lambert!  TWICE!
Newsgroups: comp.programming
From: u895027@tasman.cc.utas.edu.au (Mark Mackey)
Subject: Fast array rotation
Organization: University of Tasmania, Australia.
Date: Tue, 22 Dec 1992 02:10:51 GMT


	I am currently writing a terrain display routine which utilises
a fast surface display algorithm based on scan-line processing. As
part of the algorith I need to rotate the raw data array. I have an
algorithm to do this using two 1d transforms, but in between these
transforms the data array needs to be transposed.
	Does anyone out there have any code for fast array transposition
on disk, minimising disk access time? Alternatively, if anyone out there
has ideas on how to rotate a large array (512*512 reals) efficiently
I would be most grateful.


-------------------------------------------------------------------------------
Mark Mackey                       | "I think therefore I am" - Descartes.
u895027@tasman.cc.utas.edu.au     | "I think I think therefore perhaps I am"
E-mail should be accompanied by   |   - a more cautious philosophical outlook.
$1000 in unmarked $5 notes,       | "I drink to unthink, which proves that I
preferably in a brown paper bag.  |   think" - not the famous Ly Tin Wheedle.
-------------------------------------------------------------------------------
Newsgroups: comp.programming
From: ceblair@ux1.cso.uiuc.edu (Charles Blair)
Subject: Locating duplicates
Organization: University of Illinois at Urbana
Date: Sat, 2 Jan 1993 02:13:58 GMT

   Given a large array of integers.  Is there a way to identify duplicates
which is substantially less work than sorting the array?
Newsgroups: comp.programming
From: ke94002@black.ox.ac.uk (Daniel J Mitchell)
Newsgroups: comp.programming
Subject: Re: Programming by Description of Output...
Date: 30 Dec 92 23:36:59 GMT
Organization: Oh, come /on/..
Originator: ke94002@black


 This method of programming is usually called 'deriving programs'
-- the original work is Edsger Dijkstra's _A Discipline of
Programming_ (Prentice-Hall, 1976), other books I've read which
are probably worth looking at are _Programming from Specifications_
(Carroll Morgan, Prentice-Hall, and the course book for the course
I just did in exactly this subject.. <grin> ), and _The Science of
Programming_ (D.Gries, Springer-Verlag). (Morgan is more concrete
in it's applications, Gries is more abstract).

 To take the example given, sorting, it'd be (in the notation used
in the above, at any rate):

 var a:seq_{N} Z; con A; and A=bag a
 a:[true, up a]

 This then uses the bag abstraction to ensure the elements remain
constant -- there is no precondition, as the data being used here
specifies everything necessary (ie it's a sequence of numbers), and
the postcondition is that the sequence is an upsequence (ie is
sorted).

 This method has some advantages -- if the program is derived
step-by step from the specification to the final code, and each step
is right, then the final code is guaranteed to be correct -- this
is useful in some cases (ie to be sure that, say, a binary search
will find exactly what you want it to find, and not the element one
to the left). Also, the methods used to derive programs are
designed to make it very easy to locate flaws in the derivation if
they exist. 

 It also can wind up deriving /very/ elegant algorithms (qv the
longest upsequence problem, covered in Gries and Morgan) for
difficult problems.

 The disadvantage, obviously, is that it takes a lot more time than
it would to just write code in the majority of cases..

 As to doing it automatically, the only thing I know of is a
language called ML which reputedly is a great deal higher level
than most languages, and comes close to being able to take
specifications of the above form as code. (I think. I'm probably
wrong about that, on reflection..)

--
Daniel Mitchell == ke94002@black.ox.ac.uk == bi furry juggler
From: avg@rodan.UU.NET (Vadim Antonov)
Newsgroups: comp.programming
Subject: Re: Semaphores, Swap, or Test_And_Set
Date: 22 Dec 1992 18:20:53 -0500
Organization: UUNET Technologies Inc, Falls Church, VA
NNTP-Posting-Host: rodan.uu.net

In article <1992Dec22.192229.17569@pasteur.Berkeley.EDU> johnm@cory.Berkeley.EDU (John D. Mitchell) writes:
>In article <1h7htbINNdg6@usenet.INS.CWRU.Edu> trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:
>[...]
>>I've been trying to figure out whether that LOCK prefix is necessary when
>>sharing the code between several virtual 8086s running on one 386.   I have
>>been unable to get a clear answer to this question -- is the LOCK prefix
>>useful only for multiprocessors that take advantage of it, or does it also
>>make the instruction noninterruptible?
>
>The LOCK prefix code of the i80x86 CPUs locks down the system bus.  On a
>uniprocessor system it's only relevant if there is bus activity going on by
>the processor's back (e.g., DMA (which makes the system essentially a form
>of asymetrical multiprocessor :-)).

Never mind DMA. So far i saw no x86 machines (even real multiprocessors
like Sequent i currently enjoy looking at through my office door)
which have circuitry protecting DMA from colliding with locked memory
locations.

LOCK prefix is useful only for multiprocessing, period.
386 isn't really good for multiprocessing (no per-page cacheability
control), it was amended in 486 (but they added non-coherent internal
cache to keep life funnier, sigh).

>>An answer to the effect of, "A 386 instruction is never interruptible" is
>>OK, too -- I haven't been able to dig that sort of information out of the
>>references I can find.

Wrong. Page faults DO interrupt 386 instructions. REP... instructions
are interruptible by any interrupt source. 386 provides for
restartability, not for non-interruptability of instructions.

>Note that some instructions can *NOT* be preceded by the LOCK
>prefix.

I'd say *MOST* instructions cannot be preceded by the LOCK
(486 manuals explicitly state that). See Intel's "Microprocessors
vol I, 1992". Register<->memory XCGH should not be preceded by LOCK
because it asserts LOCK signal automatically (for the sake of
compatibility with 8086 -- who needs it?)

--vadim
From: markh@csd4.csd.uwm.edu (Mark)
Newsgroups: comp.programming
Subject: Re: Network Chat Messaging Algorithm
Date: 23 Dec 1992 11:58:41 GMT
Organization: Computing Services Division, University of Wisconsin - Milwaukee
NNTP-Posting-Host: 129.89.7.4

In article <1h8752INNn3i@darkstar.UCSC.EDU> banshee@cats.ucsc.edu (Wailer at the Gates of Dawn) writes:
>Fnet is a client/server system based on TCP/IP sockets.  The outline of
>communication between the client and server is as follows:
...
>    Specifically, the client connections are multiplexed by the server, using
>the select() call....
...
>    Net lag causes unacceptable waits to all clients.

Net lag is not causing those problems, select() is.  Always check for blocking
even if set in non-blocking mode, because select() sometimes blocks regardless.
Or, better, don't use select().  Use fork().
Newsgroups: comp.programming
From: mark@ocsmd.ocs.com (Mark Wilson)
Subject: Graphics in C
Organization: Online Computer Systems, Inc.
X-Newsreader: Tin 1.1 PL5
Date: Tue, 29 Dec 1992 12:54:04 GMT

Does anyone have any sources for source code for displaying graphics
using C?  Microsoft C 7.0 or Borland C++ OK...  I am principally
interested in putting up PCX graphics, or perhaps GIF; this is
for PC-based applications.

I have 2 editions of a book by Rimmer on this subject, but his
code doesn't work (at least for ME...)

HELP!  Email is probably best, but will check here too...

(NOTE: this same subject was posted in comp.lang.c; figured I'd try here,
too.)

--
-------------------------------------------------------------------------------
Mark Wilson, Online Computer Systems.  1-800-922-9204 or 1-301-601-2215
(Try email address mark@wilson.ocs.com....)
This file .disclaims everything signed with my .signature, I .mean it!
-------------------------------------------------------------------------------
From: pwestlak@eoe.co.uk (Peter Westlake)
Newsgroups: comp.programming
Subject: Re: reentrant code
Date: 21 Dec 92 18:57:50 GMT
Organization: EO Europe Limited, Cambridge, UK
X-Newsreader: TIN [version 1.1 PL6]

Randy Crawford (crawford@boole.mitre.org) wrote:
: 
: In article <1992Dec13.221314.26971@nntpd.lkg.dec.com>, mjg@ktbush.ogo.dec.com (Michael J. Grier) writes:
: > 
: > In article <1992Dec13.051634.14815@linus.mitre.org>, crawford@boole.mitre.org (Randy Crawford) writes:
: > |>
: > |>>The problems of reentrancy are a bit different from concurrency. 
: > |>
: > |>True, but reentrancy is irrelevant unless concurrency in some form (like
: > |>context switching) is involved.
: > |>
: > 
: >    Untrue.  Consider a module which implements an abstraction of a queue
: > or other searching structure, which provides a service for iteration on the
: > data structure.  If you specify the service such that the caller provides
: > a function to execute for each element in the structure, there is again
: > a need for reentrancy controls of some fashion.
: 
: Only if one part of the search cannot continue to completion before another
: part begins (or resumes).  This is still concurrency (or concurrent sub-
: tasks) no matter how you look at it.  When you have communicating concurrent
: threads/processes/tasks/contexts/callbacks, you have concurrency.

This sounds more like recursion than concurrency. Yes, there are several activations
of the access function on the stack at the same time, but this does not constitute
concurrency any more in this case (passing in functions to be called back) than it
does when recursing by less devious means.

Peter.
-- 
Peter M Westlake                        EO Europe Ltd.,
Tel: +44 223-843131                     Abberley House,  Granhams Road,
Fax: +44 223-843032                     Great Shelford,
email:  pwestlak@eoe.co.uk              Cambridge CB2 5LQ,   England
Newsgroups: comp.programming
From: whedon@netcom.com (Bill Whedon)
Subject: Re: Graphics in C
Keywords: Vitriolic
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Fri, 1 Jan 1993 05:32:13 GMT

I have already apologized privately to Dave.  I overreacted considerably, in
retrospect, and am appropriately chastened.  Dave's followup article was most
gracious, and contained useful information, which mine did not.  I'll try in
the future to take larger grains of salt with my reading.

ObGraphics from me:
   Bit-Mapped Graphics, Steve Rimmer, Windcrest/McGraw-Hill, ISBN 0-8306-3558-0
   Fractal Programming and Ray Tracing with C++, Roger T. Stevens, M+T Pub.,
   ISBN 1-55851-118-0

Both of these volumes contain information on saving/loading .PCX files, and the
Fractal book comes with a source code diskette.  Both are under $50 US.  The
Bit-Mapped Graphics book, in addition, offers some coverage of GIF and TIFF 4.0
formats, and mine came with a coupon in the back for a diskette for $24.95.

Happy New Year, all,
Bill Whedon   whedon@netcom.com  (who works in Unix, DOS, OS/2, and Mac)
-- and whose .sig said it all, last time, to my chagrin!  Chalk one for Dave--


-- 
-- If I ain't programmin' I ain't awake! --
From: markh@csd4.csd.uwm.edu (Mark)
Newsgroups: comp.programming
Subject: Re: Programming by Description of Output...
Date: 31 Dec 1992 18:51:55 GMT
Organization: Computing Services Division, University of Wisconsin - Milwaukee
NNTP-Posting-Host: 129.89.7.4

   That's what logic programming is all about.
Newsgroups: comp.programming
From: tim@tim.src.utah.edu (Tim Ma)
Subject: How to copyright?
Keywords: copyright
Organization: University of Utah
Date: Mon, 4 Jan 1993 01:28:30 GMT


This isn't really a programming question per se, but could anyone tell me 
what the procedure is to officially copyright a program or portions of its 
code?

Thanks,

Tim Ma
Associate Programmer
University of Utah
Email:  tim@src.cppa.utah.edu
Newsgroups: comp.programming
From: whedon@netcom.com (Bill Whedon)
Subject: Re: Graphics in C
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Thu, 31 Dec 1992 22:45:21 GMT

In article <1992Dec29.205122.23878@organpipe.uug.arizona.edu> dave@cs.arizona.edu (Dave Schaumann) writes:
>In article <C00uI5.5vr@ocsmd.ocs.com>, mark@ocsmd (Mark Wilson) writes:
>>Does anyone have any sources for source code for displaying graphics
>>using C?
>

Smartass college child responds with something about Bezier curves.  Well, he
did spell it correctly...

>>Microsoft C 7.0 or Borland C++ OK...  I am principally
>>interested in putting up PCX graphics, or perhaps GIF; this is
>>for PC-based applications.

Smartass college-child responds with drivel about X and why don't you go
elsewhere, Mark, because us Really Intelligent jackasses can't be bothered
with your stupid questions...

>
>>(NOTE: this same subject was posted in comp.lang.c; figured I'd try here,
>>too.)
>

Smartass college-child responds with highly-amusing-to-jackasses "Peeve"
enumeration, indicating that Mark cannot play on the net like Smartass c-c
as long as Smartass c-c is around to take him to task for it.

Results:  Mark doesn't get a civil answer from S c-c, S c-c gets off on dumping
on Mark for having the effrontery to multiple-post.  Smartass college-child
pats self on back for being so very clever.

Evaluation:  Smartass college-child is the real "dweeb" here, not to mention,
rude and impertinent.  

Recommendation:  Mark should ignore Smartass college-child, and simply ask his
questions as before.  Not everyone on the network is quite so shitbrained, and
some will even supply civil responses.

Reading:  Drop down to your local computer bookshop, where there are quite a
few titles containing the source for what you want to do.  There are several
with included diskettes.  I am not in my office right now, but if you will drop
me a note, I'll have a look at some of the titles and ISBNs when I get there.

Happy New Year, Mark, Grow the Hell up, Smartass college-child,
Bill Whedon   whedon@netcom.com 


-- 
-- If I ain't programmin' I ain't awake! --




Newsgroups: comp.programming
From: jim@nestmoi.rain.com (Jim Chorn)
Subject: Re: Semaphores, Swap, or Test_And_Set
Followup-To: comp.arch
Organization: none - Portland, OR
Date: Thu, 24 Dec 1992 06:51:03 GMT

In Article <1h87slINNshf@rodan.UU.NET> Vadim Antonov writes:
	-> Never mind DMA. So far i saw no x86 machines (even real
	-> multiprocessors like Sequent i currently enjoy looking at
	-> through my office door) which have circuitry protecting
	-> DMA from colliding with locked memory locations.
Like I stated before, It depends on the hardware.
The Sequent cache has bus watching circuitry which causes DMA's to
invalidate cache lines on each transfer. Have you removed it? ;-)

	-> LOCK prefix is useful only for multiprocessing, period.
Again, it depends on the hardware.

	-> 386 isn't really good for multiprocessing (no per-page
	-> cacheability control), it was amended in 486 (but they
	-> added non-coherent internal cache to keep life funnier,
	-> sigh).
Again, (sigh) it depends on the hardware. Per page cache controls
make multiprocessor software easier for some cases but this can
also be accomplished in the cache controller. As for the 386 not
being good, then why did Sequent select the 386 for a multiprocessor
system? ;-)

With the advent of today's ASIC hardware technology, almost *any*
general purpose cpu can be used in a multiprocessor system. How
fast the system really is depends on several factors including bus,
cache and memory bandwidth as well as processor topology and what
application the system design is targeted to solve. Each of these
areas are complex and should be discussed in other news groups.

I've put follow-ups to comp.arch for which I have no news feed
so please email me if you wish to continue this discussion.

-jim		jim@nestmoi.rain.com
Newsgroups: comp.programming
From: dougm@titan.cs.rice.edu (Doug Moore)
Subject: Re: Locating duplicates
Organization: Rice University Computer Science, Houston, Texas
	<1993Jan2.041658.21596@organpipe.uug.arizona.edu>
Date: Sat, 2 Jan 1993 07:47:23 GMT

>>>>> On 2 Jan 93 04:16:58 GMT, dave@cs.arizona.edu (Dave Schaumann) said:

	Dave> In article <C07FJo.4vq@ux1.cso.uiuc.edu>, ceblair@ux1 (Charles Blair) writes:
>   Given a large array of integers.  Is there a way to identify duplicates
>which is substantially less work than sorting the array?

	Dave> Hmm... imagine we have an array with just two elements that are equal.
	Dave> Now assume we have some duplicate finder which does not sort the array.
	Dave> Assuming that the values and positions of the data are not related in
	Dave> some way, it seems reasonable to assume that we can arrange the values
	Dave> so that that the algorithm must try every possible combination before
	Dave> it finds the duplicate pair.

	Dave> Not an air-tight proof

Right.  So try this:

Assume that our duplicate checker must compare elements to do its
work.  And assume that we wish only to check whether or not any
duplicates exist.  Let the array have, besides data entries containing
the numbers to be checked, pointer entries.  When we compare two array
data entries, we make the pointer paired with the lesser element point
to the pair containing the greater element (or quit if the elements
are equal).  To confidently report 'no duplicates', the pointers must,
in the end, form a sorted linked list.  Consider two items that are
consecutive in a sorted sequence; if we haven't compared those two in
particular, we can't tell whether they're duplicates or not.  So we
must have compared all such pairs to report 'no duplicates'.  So
anything that let's us report 'no dups' is essentially a sorting
algorithm, and comparison based sorting requires O(n lg n) time.

But if these are fixed size integers (like C ints), you can radix sort
in linear time anyway, which is as fast as you can reasonably expect.

For example:

rsort(unsigned arr[], unsigned n)
{
  int j;
  unsigned* stacks = (unsigned*) malloc(n*sizeof(unsigned));
  unsigned mask = 1;
  unsigned max = 0;
  for (j = 0; j < n; ++j)
    if (max < arr[j])
      max = arr[j];
  while (mask <= max && mask) /* <= 32 times on my machine */
    {
      int top = n;
      int bottom = 0;
      for (j = 0; j < n; ++j)
        if (arr[j] & mask)
          stacks[--top] = arr[j];
        else
          stacks[bottom++] = arr[j];
      for (j = 0; j < bottom; ++j)
        arr[j] = stacks[j];
      for (j = top; j < n; ++j)
        arr[j] = stacks[n-1-j+top];
      mask <<= 1;
    }
  free((char*) stacks);
}

Doug Moore
(dougm@cs.rice.edu)
Newsgroups: comp.programming
From: jhallen@world.std.com (Joseph H Allen)
Subject: Re: Locating duplicates
Organization: The World Public Access UNIX, Brookline, MA
Date: Sat, 2 Jan 1993 09:18:20 GMT

Another way is to use a clash detection table.  For each integer apply a
hash function which returns an integer of about log2(2*size of array) bits.
Use this as an index into a bit map which is 1/16 the size of the array.  If
the bit is clear, set it.  If it's set, you might have a duplicate.  Store
the potential duplicate in some kind of database.  Make a second pass
through the array to verify the duplicates.

This method will approach O(n) if the number of expected duplicates is small
and if the hash function is good.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Newsgroups: comp.programming