HDTenEightyP/NetNews huggingface dataset:
From: boutell@isis.cshl.org (Tom Boutell)
Subject: Re: Programming by Description of Output...
Organization: Cold Spring Harbor Labs
Date: Wed, 30 Dec 1992 19:15:01 GMT

In article <1992Dec30.174004.4168@cs.cornell.edu> karr@cs.cornell.edu (David Karr) writes:
>In article <C01yxr.BGF@phage.cshl.org> boutell@isis.cshl.org (Tom Boutell) writes:
>>Initial state:
>>Array A[] contains n whole numbers... 

>This sounds like automatic programming, which is an old idea.
>Frederick P. Brooks mentioned it in an article a couple of years ago,
>entitled (I think) "No Silver Bullet."

Interesting. I know a lot of discussion of the subject has been done.

>How much easier is it to specify a program by predicates on its input
>and output rather than by an algorithm?  

An excellent question. I gather Prolog programmers have discovered
it is often as much or more work than writing the algorithm, as
you point out.

>I contend it's not as easy
>as one might hope.  For example, is the following legal I/O for your
>specification:
>
>A[] (input):   3 2 1 3 2 1 3 2 1
>B[] (output):  1 2 3 3 3 3 3 3 3
>
>Each element of A[] appears in B[], but not with the same count of 
>repetitions.  Is this what you intended?

Interesting point. An extension of the terminology is needed to
express this problem succinctly, which in turn requires its own
mathematical definition; and I imagine similar difficulties will
appear in describing most problems.

This doesn't mean it's not worth pursuing the notion, though,
so attempting to respond:

The following definitions are made:

All objects have values. Objects exist independent of their values;
two distinct objects, for instance, may have the value 3.

Arrays are objects whose value is an ordered, uniquely indexed
list of objects.

Now, the description of B[] is amended to read:

  One duplicate of each object in A[] appears in B[]...

These are reasonable definitions and they seem to handle the
problem you pointed out. I recognize that the amount of time spent
on this could have been spent, say, devising a sorting
algorithm, but the idea (and it is only an idea, and may not
work well in practice) is that one only has to make these
definitions and get the hang of them once.

>
>-- David Karr (karr@cs.cornell.edu)

-T

-- 
Tom Boutell, boutell@cshl.org

Clausthaler is the best non - alcoholic beer in the known universe.
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.programming
Subject: Re: Locating duplicates
Date: 2 Jan 93 11:51:09 GMT
Organization: AND Software BV Rotterdam

In article <C07FJo.4vq@ux1.cso.uiuc.edu> ceblair@ux1.cso.uiuc.edu (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?

If you're low on memory and the array is really large, there is no better
way than to sort the array and scan the sorted array afterwards, checking
for duplicates. This would cost you O(n*log(n)) time to do the job.

On the other hand, if you're not low on memory and if you know the range
of the numbers in the array, say Min and Max, you could use an index
scheme as follows:

for all i in Min and Max in index
	index[i] = unset

for all i in Minindex and Maxindex in array
	if index[array[i]] != unset then
		duplicate detected
	else
		index[array[i]]= i

Here index[j] points to the location in the array where the number j
can be found, if present.  This algorithm (and it's memory usage) is 
all very dependent on the actual numbers Min and Max (the lowest and 
highest values found in the array.) But it'll cost you only O(n) time 
to scan the array.

I hope this helps a bit,

kind regards and a happy new year,

Jos aka jos@and.nl
From: trier@slc6.ins.cwru.edu (Stephen C. Trier)
Newsgroups: comp.programming
Subject: Re: Semaphores, Swap, or Test_And_Set
Date: 22 Dec 1992 17:05:47 GMT
Organization: Case Western Reserve University, Cleveland OH (USA)
NNTP-Posting-Host: slc6.ins.cwru.edu

In article <1992Dec22.055727.8056@nestmoi.rain.com> jim@nestmoi.rain.com (Jim Chorn) writes:
>This will only work on multiprocessors if the lock prefix is supported by
>the processor. For example, if the multiprocessor system is tightly
>coupled and each processor supports a coherent cache but the cache
>ignores the processor lock signal this may not work.

Ah, finally!  It sounds like I've found someone who knows something about
the nitty-gritty of these ghastly CPUs.

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?

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.  Everything provides application-level information,
but none of the info I need about exactly when an interrupt or exception
can take place.  It seems strange, since this information is readily avail-
able for the 680[234]0.  Why isn't the 386/486 as well documented?  (Maybe
I'm looking in the wrong place?)

By the way, someone sent me mail about a typo in my assembly code.  There's
one point where it says, "mov bx, word ptr [bx+4]".  That should be "mov
bx, word ptr [bp+4]".  It is a transcription error, my fault, and the bp
version is what was in the original.

-- 
Stephen Trier                      "We want to offer you a price that you
Network software type               just can't afford to take advantage of."
Case Western Reserve University         - Sales blurb from HSC Software
trier@ins.cwru.edu
Newsgroups: comp.programming
From: jpw@sansfoy.lib.Virginia.EDU (John Price-Wilkin)
Subject: lex help
Keywords: lex
Organization: University of Virginia
Date: Wed, 23 Dec 1992 01:25:20 GMT

My apologies if this is misdirected, but I could use some basic help with  
lex.  I'm writing a filter for a tagged file and have done all of the  
basic routines (i.e., the routines my *basic* skills will cover).  Some of  
the tagging I'm trying to cover looks like the following:
	<doc name="Opera" author="Anselmus">
but sometimes they're like:
	<doc author="Anselmus">
and sometimes like:
	<doc name="Opera">
They are always one of the three, and the contents of the quotes are of  
variable length, often containing spaces.  I'd like to render them as:
	Name:  Opera
	Author:  Anselmus
(or the corresponding versions with only one of the elements).  There's  
another variation on this theme, where the hierarchical tag scheme "<divN"  
is used, so that I encounter
	<div1 name="Opera" author="Anselmus">
as well as
	<div2 name="Opera" author="Anselmus">
and so on, through div4.  My first and most immediate concern is to get a  
lex routine that will take care of each instance (e.g,. a <doc tag that  
has any one of the three configurations -- both author and name, or either  
author or name), but an ideal solution would be to have something that did  
a <doc or any <divN as well.  I'd be much obliged if someone would show me  
the light on this.  Replying to me personally would be swell.

John Price-Wilkin
jpw@virginia.edu
From: majidi@rwja.umdnj.edu (Masoud Majidi)
Newsgroups: comp.programming
Subject: berger test of programming proficiency
Date: 29 Dec 92 16:22:34 GMT
Organization: Robert Wood Johnson Medical School, Piscataway NJ

Dear netters,

Has any heard of 'Berger Test of Programming Proficiency?' Any pointer to
any source of information on this would be appreciated?

BTW, I hope this is the right newsgroup to post this query and I 
apologize if it is not.

Thanks again,

--
Masoud Majidi                           Internet: majidi@umdnj.edu
Academic Computing Services             Voice: (908) 463-4839
University of Med & Dent of NJ          Fax:   (908) 463-5252
From: spackman@disco-sol.dfki.uni-sb.de (Stephen Spackman)
Newsgroups: comp.programming
Subject: Re: Semaphores, Swap, or Test_And_Set
Date: 1 Jan 1993 19:06:39 GMT
Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken
	<1992Dec22.192229.17569@pasteur.Berkeley.EDU>
	<1h87slINNshf@rodan.UU.NET>
Reply-To: stephen@acm.org
NNTP-Posting-Host: disco-sol.dfki.uni-sb.de
In-reply-to: avg@rodan.UU.NET's message of 22 Dec 1992 18:20:53 -0500

Historically, the 8086 LOCK prefix did nothing but raise the external
lock signal. Hardware engineer's option whether that means anything.
Since then the situation has become worse, as the list of circumstances
in which it *doesn't* work has got longer. A botch job, I think....
------------------------------------------------------------------------
stephen p spackman                                       stephen@acm.org
------------------------------------------------------------------------
From: mars@carroll1.cc.edu (Sean Tyler Mars)
Newsgroups: comp.programming
Subject: Stupid Mouse in C++
Date: 24 Dec 92 08:49:58 GMT
Organization: Carroll College-Waukesha, WI

Hey all in computer programming land,
	I have a question for anyone who knows about turbo C++ version 3.0.

	 I am simply trying to program a game that uses a mouse and when 
I put the screen on graphics mode,  I can only move the mouse half way down
the screen.  Does this sound familiar to anyone??  I would really like help 
on this.  There are not any books that I have found that will even explain the
stupid mouse.  If you have any suggestions, please help me.  I really 
appreciate it.
	
	-Sean
mars@carroll1.cc.edu
Newsgroups: comp.programming
From: pt@geovision.gvc.com (Paul Tomblin)
Subject: Fillet mode?
Reply-To: pt@geovision.gvc.com
Organization: Not officially GeoVision Systems Inc., Ottawa, Ontario
Date: Sun, 20 Dec 1992 21:43:33 GMT

I'm trying to figure out the algorithm for this, but I thought I'd ask
first:

I want to generate lines with fillets - ie. line segments joined by
fixed-radius arcs.  I.e. I'd like to be able to get a user to enter a
radius, and then digitize a polyline, and I'd change all the corners to nice
arcs.

Given: Corner points of a polyline, and a fillet radius
Generate: the parameters for the arcs at each corner point (ie. radius,
start point, end point, or 3 points that define the arc)

If anybody can email an algorithm for this, I'll be happy to share my final
code.

-- 
Paul Tomblin (I don't make or state policy for this company)
"Well, this looks absolutely brilliant and completely unmarketable."
"Thanks.  I'm technology driven" - Dilbert
From: reiter@aisb.ed.ac.uk
Newsgroups: comp.society.development
Subject: DEVEL-L on USENET
Date: 21 Dec 92 10:01:06 GMT
Reply-To: e.reiter@ed.ac.uk ()
Organization: Dept AI, Edinburgh University, Scotland

The BITNET discussion group DEVEL-L now seems to be available on USENET
(netnews, rn, ...) as group

	bit.listserv.devel-l

[Note that not all USENET systems carry bit.* groups].  DEVEL-L is devoted
to general discussions of third-world development, with an emphasis on
technology transfer issues.  It is much more active than this group, with
up to a dozen messages a day.
--
						Ehud Reiter
						(e.reiter@edinburgh.ac.uk)
Newsgroups: comp.society.futures
From: klopfens@andy.bgsu.edu (Bruce Klopfenstein)
Subject: Seminal Works in Futures Research?
Keywords: forecasting telecommunications future
Organization: Bowling Green State University B.G., Oh.
Date: Wed, 30 Dec 1992 23:22:05 GMT

What are the most cited works about forecasting/futures research in
general and forecasting telecommunications/information-computer science
in particular?  I want to use them in a graduate seminar on forecasting
new electronic media.

Feel free to email, but I think there will be sufficient interest
to post your responses on the group.

Thanks.

-- 
Bruce C. Klopfenstein             |  klopfens@andy.bgsu.edu
Department of Telecommunications  |  klopfenstein@bgsuopie.bitnet
Bowling Green State University    |  (419) 372-2138; 372-2224 
Bowling Green, OH  43403-0235     |  fax (419) 372-8600
Date: Mon, 21 Dec 1992 17:49:18 -0500
From: Mikki Barry <ooblick@intercon.com>
Newsgroups: comp.society.privacy
Subject: Re: More on SSNs as used by VA DMV
Organization: InterCon Systems Corporation
X-Submissions-To: comp-privacy@pica.army.mil
X-Administrivia-To: comp-privacy-request@pica.army.mil
X-Computer-Privacy-Digest: Volume 1, Issue 117, Message 5 of 9

The good news is that after testimony at a VA Senate Subcommittee by Dave 
Banisar of CPSR, two of us from InterCon, and many other very annoyed people, 
the Subcommittee voted to draft legislation removing the SSN from the VA 
Driver's license.  They also are looking into setting up an "Information 
Czar" to overlook electronic privacy issues.

Seems the subcommittee was very frightened by the spectre of fraud and SSN's.  
They were especially amused by Banisar's recounting of a story of a fat farm 
selling customer information to a chocolate factory :-)

Bottom line is, they believed that the SSN should be kept more private, and 
should not be used as a default identifier.
Date: 22 Dec 92 13:38:12 GMT
From: "Wm. L. Ranck" <ranck@joesbar.cc.vt.edu>
Newsgroups: comp.society.privacy
Subject: Re: SSN and Schools
Organization: Computer Privacy Digest
X-Submissions-To: comp-privacy@pica.army.mil
X-Administrivia-To: comp-privacy-request@pica.army.mil
X-Computer-Privacy-Digest: Volume 1, Issue 117, Message 9 of 9


Eric Hunt (bsc835!ehunt%bsc835bsc.edu@uunet.uu.net) wrote:
: 
: > Alabama recently (last 2 years) began requiring SSN's for all students
: > entering school. No SSN, no school. 
: 
: It was her 10th grade year. She's in the 11th now. Public School. Very pissed
: off mother, incedentally. "If the number is good for the IRS, by god it should
: be good enough for [insert principal's name]" [grin]

Our school district tried to 'require' SSN of its students a couple of
years ago.  I told them no and they didn't give me a hard time.  If the
school had tried to keep my kids from attending because of it I would
have been on the phone to the ACLU and any other legal aide group I
could think of.  They can't deny someone an education because they
don't have a SSN.  They *aren't* required you know.  If you don't take
the deductions for your children off your taxes there is no law that
forces you to have the number for them.  Also there must me *some*
foreign nationals enrolled who don't have SSNs.  
--

*******************************************************************************
* Bill Ranck                                          ranck@joesbar.cc.vt.edu *
* Computing Center at Virginia Tech, not Vermont ----------------------^^     *
*******************************************************************************
Date: Fri, 18 Dec 1992 12:55:15 GMT
From: Rob deFriesse <rj@cadre.com>
Newsgroups: comp.society.privacy
Subject: Re: Radar Detector Prohibitions
Reply-To: rj@cadre.com
Organization: Cadre Technologies Inc.
X-Submissions-To: comp-privacy@pica.army.mil
X-Administrivia-To: comp-privacy-request@pica.army.mil
X-Computer-Privacy-Digest: Volume 1, Issue 116, Message 1 of 11

: Not that this is a privacy issue, but I thought that banning radar
: detectors was technically a violation of federal law.  I think
: there is a federal law on the books, dating back from the '30's,
: which affirms citizens' rights to receive signals broadcast anywhere
: in the electromagnetic spectrum.

While it is illegal to ban any reciever, the law also states that it
is illegal to use a reciever in the commision of a crime.  This is
how they justify the prohibition of radar dectectors.

The problem I have with this is that a radar detector prohibition
assumes that a crime has or will be commited even though there
may be no proof of the crime.  The counter argument is that a radar
detector is good for only one thing: to facilitate the violation
of speed limits.  This is not good enough.  The law is clear.
Receivers are always legal unless used to commit a crime.  If
there is no proof of a crime, there is no crime.

--
The software engineer's credo:  Eschew Obfuscation

Rob deFriesse                    Mail:  rj@ri.cadre.com
Cadre Technologies Inc.          Phone:  (401) 351-5950
222 Richmond St.                 Fax:    (401) 351-7380
Providence, RI  02903

I don't speak for my employer.
Date: Sun, 20 Dec 1992 07:22:50 GMT
From: dcg5662@hertz.njit.edu (Dave Grabowski (KxiK))
Newsgroups: comp.society.privacy
Subject: Re: The UPS clipboard
Organization: New Jersey Institute of Technology, Newark, N.J.
X-Submissions-To: comp-privacy@pica.army.mil
X-Administrivia-To: comp-privacy-request@pica.army.mil
X-Computer-Privacy-Digest: Volume 1, Issue 117, Message 3 of 9

In article <comp-privacy1.115.3@pica.army.mil> roy@cybrspc.uucp (Roy M. Silvernail) writes:
>Consider that instead of a physical paper trail, you have valuable data
>being stored electronically.  No one at UPS could tell me if that data
>was stored in the clear.  The most knowledgable person I spoke to did
>not know the term 'encryption'.  Given that I'm familiar with the
>company building the clipboards, if this product follows their usual
>design practices, it's implemented around an 8051 derivative processor
>and static RAM.  It may, in fact, store data in EEPROM to avoid
>inadvertant power loss.  Both memories' contents can be recovered by a
>skilled tech, regardless of the wishes of the host processor.  Even if
>they have gone to a more powerful processor, the memory must be held
>static for the duration of the shift.  The stored data are therefore
>vulnerable.
>
>Consider, also, that the signature may actually be the least valuable
>piece of information in that record.  How much could you tell about a
>competitor if you had access to their UPS shipping records?  In many
>cases, even the insured value of packages is recorded.
>
>No one at UPS knew of any audit trail established for the clipboards.
>The one rep told me the boards were 'dumped and cleared' at the end of
>each shift, but could not confirm that residual data was actually
>overwritten.  He also didn't know if a board could be dumped more than
>once.

  My roommate (who works for UPS) just told me a bit about the "DIAD"
boards. When UPS started with the boards, the printed a bunch of info
about them in the UPS newsletter. According to it, the boards are
"dumped and cleared" at the end of every shift. They're all placed in
one big matrix and are all basically read at once, and sit there until
the next shift. Once cleared, the information can NOT be "dumped" again.

  BTW - Apparently, those little touch-sensitive signature pads have to
be replaced about once every two weeks.

-Dave
-- 
 -----------------------------------------------------------------------------
Kappa Xi Kappa - Over & Above!                         dcg5662@hertz.njit.edu
9 Sussex Ave., Newark, NJ (car theft capital USA)   70721.2222@compuserve.com
Date: Wed, 23 Dec 1992 18:03:14 -0500 (EST)
From: "Dave Niebuhr, BNL CCD, 516-282-3093" <NIEBUHR@bnlcl6.bnl.gov>
Newsgroups: comp.society.privacy
Subject: Privacy Concerns and the So-Called Privacy Advocates
Organization: Computer Privacy Digest
X-Submissions-To: comp-privacy@pica.army.mil
X-Administrivia-To: comp-privacy-request@pica.army.mil
X-Computer-Privacy-Digest: Volume 1, Issue 119, Message 4 of 7

A question just crossed my mind.  When Caller-ID is in the process
of being instituted in an area, the privacy-mavens scream bloody
murder.  Yet, with the known (I suppose) wide-spread usage of SSNs
as identifiers, where are they?

People I talk to are surprised when I tell them that if I knew their
SSN I could find out all kinds of information about them and possibly
do them irreprable harm if I wanted to.

Is this a mis-guided sense of "security" or what?  Does it spring
from the original Social Security for being a supplement to retirement
funds and the general public doesn't realize just how much businesses
know about one or can find out if so desired.

I'm not a complete privacy freak, but I do know when to give information
and when not to do so.

Dave
Dave Niebuhr      Internet: niebuhr@bnl.gov / Bitnet: niebuhr@bnl
Brookhaven National Laboratory Upton, NY 11973  (516)-282-3093
Date: Wed, 23 Dec 92 22:56:56 GMT
From: John De Armond <jgd@dixie.com>
Newsgroups: comp.society.privacy
Subject: Re: Radar Detector Prohibitions
Organization: Dixie Communications Public Access.  The Mouth of the South.
X-Submissions-To: comp-privacy@pica.army.mil
X-Administrivia-To: comp-privacy-request@pica.army.mil
X-Computer-Privacy-Digest: Volume 1, Issue 118, Message 4 of 9

rj@cadre.com (Rob deFriesse) writes:

>: Not that this is a privacy issue, but I thought that banning radar
>: detectors was technically a violation of federal law.  I think

>While it is illegal to ban any reciever, the law also states that it
>is illegal to use a reciever in the commision of a crime.  This is
>how they justify the prohibition of radar dectectors.

No, not at all.  The states base their law on their right to regulate
what equipment is used in a vehicle.  Virginia got burned early on by
confiscating detectors they could not prove was being operated in
the vehicle.  Thus the use of radar detector detectors.  
This is the same basis used to rationalize scanner bans and red/blue
flashing light bans.  Whether this rational would withstand a Supreme Court 
test is anyone's guess.

John

-- 
John De Armond, WD4OQC               |Interested in high performance mobility?  
Performance Engineering Magazine(TM) | Interested in high tech and computers? 
Marietta, Ga                         | Send ur snail-mail address to 
jgd@dixie.com                        | perform@dixie.com for a free sample mag
Need Usenet public Access in Atlanta?  Write Me for info on Dixie.com.
Date:  Tue, 22 Dec 92 16:54:10 EST
From:  Computer Privacy List Moderator <comp-privacy@pica.army.mil>
Newsgroups: comp.society.privacy
Subject:  Holiday Schedule
Organization: Computer Privacy Digest
X-Submissions-To: comp-privacy@pica.army.mil
X-Administrivia-To: comp-privacy-request@pica.army.mil
X-Computer-Privacy-Digest: Volume 1, Issue 117, Message 1 of 9

  Due to the holidays I will not be publishing the digest from Dec 25 -
Dec 29.  The last digest will go out the morning of the 24th.  I will
save all submissions for when I come back.  I extend best wished for a
happy holiday season to everyone.

dennis
Date: Wed, 23 Dec 92 07:25:48 PST
From: Dave Crimmin DTN 226-5857 23-Dec-1992 1021 <crimmin@delni.enet.dec.com>
Newsgroups: comp.society.privacy
Subject: SSN's discontinued by MA Registry of MV
Organization: Computer Privacy Digest
X-Submissions-To: comp-privacy@pica.army.mil
X-Administrivia-To: comp-privacy-request@pica.army.mil
X-Computer-Privacy-Digest: Volume 1, Issue 118, Message 8 of 9

The Massachusetts Registry of Motor Vehicles announced yesterday that they 
will no longer use SSN's on licenses.  The brief report on the radio this 
morning did not go into detail on how/if present license numbers (which for 
most people are the SSN) would be converted.  The privacy issue was cited as 
the driving force behind the policy change.