HDTenEightyP/NetNews huggingface dataset:
From: jimc@tau-ceti.isc-br.com (Jim Cathey)
Newsgroups: comp.human-factors
Subject: Re: Macintosh System Inconsistency
Date: 9 Nov 92 22:38:23 GMT
Organization: ISC - Bunker Ramo, Spokane, WA

In article <721054414.26707@minster.york.ac.uk> simpson@minster.york.ac.uk writes:
>It turns out that the default font for Macs (New York) is not held in the
>printers so it downloads the font each time. I didn't believe the support
>people here when they told me so I phoned the shop and they confirmed it.

The default application font for Macs is usually Geneva, not New York. 
Blame Microsloth for that one, unless you did something. 

That said, the original Laserwriter drivers had an option called "font
substitution", in which Geneva is replaced with Helvetica, New York with
Times Roman, and Monaco with Courier.  This is so that the 'new' Laserwriter
would use the built-in outline fonts instead of going through all the
rigamarole you've been noticing, as well as having no better print quality
than a dot-matrix printer.  Unfortunately, all letterspacing was still done
with the original bitmapped fonts' metrics, which looks like dog doo-doo.

Everybody ends up turning it off.

I would surmise, then, that the LW driver you're using now defaults to
font substitution OFF, which is your problem.

Another problem is that the LW outline fonts' bitmapped versions (used on
the screen) aren't as legible as Geneva and New York, which means using
one of them as a default is probably a bad idea.

A lose-lose situation no matter how you look at it.

-- 
+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC-Bunker Ramo
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!isc-br!jimc (jimc@isc-br.isc-br.com)
! II      CCCCCC !  (509) 927-5757
+----------------+
			"PC's --- the junk bonds of the computer industry"
Newsgroups: comp.human-factors
From: mf@dancer.uucp (24227-fusco)
Subject: Re: Voting Booths
Organization: On the Road
Date: Wed, 11 Nov 92 12:32:35 GMT

In article <1992Nov11.045622.23693@microsoft.com> bethmo@microsoft.com (Beth Moursund) writes:
>This discussion is interesting to me, because I've never seen anything
>like the voting booths you're discussing.  In all the places I've
>voted, you get your ballot (which is a long cardboard strip with
>punchable holes), slide it into a slot in the voting booth, and then
>use a stylus to punch one hole for each vote.  The book next to the
>ballot lists the candidates/propositions, and clearly marks where
>to stick the stylus for each.

	I recently voted in NJ and I did not use a punch ballot,
just pulled some levers.  In fact, I also worried that my vote(s)
were registered since the booth attendents seemed to have some 
trouble operating the levers on the outside of the booth before 
the next person entered (reset levers?).
From: lee@turbo4.rsg.hac.com (C. Lee)
Newsgroups: comp.human-factors
Subject: Re: HUD question
Date: 10 Nov 92 01:46:11 GMT
Organization: Hughes Transportation Simulation Center, Hughes Aircraft Company, Culver City, CA

In article <1992Nov6.033242.7230@cactus.org> rdd@cactus.org (Robert Dorsett) writes:
>In article <9211051727.AA19848@tecnet1.jcte.jcs.mil> davehyde@tecnet1.jcte.jcs.mil writes:
>>refocus your eyes periodically.  It has also been my observation that, on HUD->>equipped airplanes I've flown, that I had to re-focus somewhat to read info on>>the HUD after looking through it to see outside....
>
>It appears that even the slightest accumulation of dust, grease, or other
>particulate matter on the collimater will ruin the infinite-perspective
>effect.
>
>>(as they exisit in production today) HUD, you won't see anything coming at you>>outside of boresight.  I.E. a HUD may not be the ideal thing for VFR...
>
>From HUMAN FACTORS IN AVIATION (Nagel & Wiener, Academic Press, 1988), p. 399:
>  { ... study indicating HUD's may distract
>  from peripheral situational awareness ... }

How do HF people feel the problem with HUD's causing lack of attention
to non-boresite activity is applicable to cars, trucks, trains, boats,
and ships?

E.g., I know of at least one study on the use of HUD's on trains.

I believe GM offers HUD's as an option on some cars, and is studying
putting them on other cars, and possibly trucks.

At least one company offers HUD's for law enforcement vehicles to
supplement their in-car terminal message system.

At least one company offers, and several others are developing, HUD's
for commerial airliners (and I'd assume for private planes as well),
and they're all looking to aggressively expand.
Newsgroups: comp.human-factors,general,sci.engr,sci.misc,triangle.general
From: mroussel@alchemy.chem.utoronto.ca (Marc Roussel)
Subject: Re: Quick questionnaire
Organization: Department of Chemistry, University of Toronto
Date: Mon, 9 Nov 1992 15:51:13 GMT

In article <1992Nov6.211123.1032@cabell.vcu.edu> kguyre@cabell.vcu.edu
(Kenneth C. Guyre) writes:
>rwright@norfolk.vak12ed.edu (Robert Wright) writes:
>>Now I am thinking, if news from outside is coming in to general from
>>VDOE386, then surely our LOCAL posts are being sent out TO THE REST
>>OF THE WORLD by VDOE386 to newsgroups "general."
>
>If you are setting distribution to "local" your postings will stay on your
>local system.

     Probably not.  Usenet leaks because many sites insist on receiving
other sites' local newsgroups.  Examples:  Many U. of Toronto systems
receive York and Waterloo newsgroups.  Cross-postings between these
newsgroups and mainstream groups will therefore almost certainly leak to
the rest of the world.

				Marc R. Roussel
                                mroussel@alchemy.chem.utoronto.ca
From: palmer@icat.larc.nasa.gov (Michael T. Palmer)
Newsgroups: comp.human-factors
Subject: Re: Voting Booths
Date: 12 Nov 92 13:24:27 GMT
Organization: NASA Langley Research Center, Hampton, VA  USA
NNTP-Posting-Host: icat.larc.nasa.gov

shanks@saifr00.cfsat.honeywell.com (Mark Shanks) writes:

>I'll curb my predisposition to argue that anyone who isn't smart enough
>to figure out the MECHANICS of voting shouldn't be ALLOWED to vote, and
>ask if you two live in some benighted area that doesn't use punch
>ballots. I haven't seen the old draw-curtain telephone-operator-style
>booths in 25 years, and I've voted in Caribou, Maine and St. Peters,
>Missouri, neither being exactly leading-edge communities.

You mean there are other types of voting machines?  :-)  Maybe you
haven't seen them in 25 years because they shipped them all to Virginia.
Obviously, I figured it out.  But it makes me mad to HAVE to FIGURE IT
OUT.  It's supposed to be simple, and it definitely is not.  I have only
voted in Auburn, AL and Hampton, VA, and both places use the old-style
machines.

If you know the name of the manufacturer of the new machines, or can
find out by a simple phone call to your voter registrar, please post the
info.  Thanks.
-- 
Michael T. Palmer, M/S 152, NASA Langley Research Center, Hampton, VA 23681
Voice: 804-864-2044,   FAX: 804-864-7793,   Email: m.t.palmer@larc.nasa.gov
PGP 2.0 Public Key now available -- Consider it an envelope for your e-mail
Newsgroups: comp.human-factors
From: jgg@evb.com (John Goodsen)
Subject: Re: The Problem With UNIX
Organization: EVB Software Engineering, Inc.
Date: Thu, 12 Nov 1992 01:56:51 GMT

>
>"rm * .c" (when you really want "rm *.c")
>
>I think Unix (well, actually the shell is to blame) should always ask
>for permission when the star is used with rm. 
>

If you're using a *real* shell like tcsh then you've already got
this and you didn`t even know.  Put the line:

    set rmstar

in your .cshrc ....  here's a test run ...

  % rm * .c
  Do you really want to delete all files? [n/y] n

:-)

enjoy

--
John Goodsen                           PCIS Programme
Software Process & Environments        Ada Joint Program Office       
EVB Software Engineering               goodsenj@ajpo.sei.cmu.edu
jgg@evb.com
From: jimb@rcx1.csd.harris.com (Jim Burmeister)
Newsgroups: comp.human-factors
Subject: Re: Voting Booths
Date: 12 Nov 1992 15:04:43 GMT
Organization: Harris CSD, Ft. Lauderdale, FL
Distribution: ssd
NNTP-Posting-Host: rcx1.ssd.csd.harris.com

In article <23973@hacgate.SCG.HAC.COM>, lee@turbo4.rsg.hac.com (C. Lee) writes:
> That (long cardboard strip with punchable holes) sounds just like the
> voting I've done (I've only voted in California).  It sounds like maybe
> the western states use those, and the eastern (and central?) states use
> mainly booths.

Sorry to shoot down your theory, but I have lived in Michigan and Florida,
and both places use the "punch-card" style of voting.  

I think it's more likely something to do with the amount of money the local
governments have.  If they can afford to upgrade to more modern systems
(punch-card or pencil-based), they do, otherwise they continue using the old
machines.

-Jim Burmeister, jimb@csd.harris.com
From: adam@endor.uucp (Adam Shostack)
Newsgroups: comp.human-factors
Subject: Re: Voting Booths
Date: 13 Nov 92 17:38:12 GMT
Article-I.D.: das.1992Nov13.173812.3420
Organization: Aiken Computation Lab, Harvard University

In article <23973@hacgate.SCG.HAC.COM> lee@turbo4.rsg.hac.com (C. Lee) writes:
>In article <1992Nov11.045622.23693@microsoft.com> bethmo@microsoft.com (Beth Moursund) writes:
>>                                      ...  In all the places I've
>>voted, you get your ballot (which is a long cardboard strip with
>>punchable holes), slide it into a slot in the voting booth, and then
>>...
>>(I've voted in Oregon and Washington.)
>
>That (long cardboard strip with punchable holes) sounds just like the
>voting I've done (I've only voted in California).  It sounds like maybe
>the western states use those, and the eastern (and central?) states use
>mainly booths.

Massachusetts uses the punch cards, which I prefer, since it lets you
check that your vote was at least entered onto the card exactly.
(There are numbers next to each hole.)

There was an article in RISKS a few days ago about a lady who, apon
checking her ballot in California, discovered that she had punched the
wrong hole.  Apparently, she was the first person in the course of the
day to realize that her vote was punched incorrectly.  Election
officials say that it is not possible to discover how many votes were
miscounted, but that the miscount would not have affected the outcome
of the election.  (It was estimated to be less than several hundered,
and the closest vote was several thousand apart, even in the county.)

Adam

Adam Shostack 					adam@das.harvard.edu

What a terrible thing to have lost one's .sig.  Or not to have a .sig
at all because of elections.  How true that is.
From: so@brownie.cs.wisc.edu (Bryan S. So)
Newsgroups: comp.human-factors
Subject: Re: The Problem With UNIX
Date: 10 Nov 92 00:39:20 GMT
Organization: University of Wisconsin, Madison -- Computer Sciences Dept.

In article <1992Nov9.191115.29951@julian.uwo.ca> jamie@uwo.ca (J. Blustein) writes:
>In article <1992Nov9.172037.15990@cs.wisc.edu>
>>
>>    mail somebody < a.out
>>
>>    Sending binary file should be uuencoded first.  This is a
>>    general type conflict problem.
 
>   Why must a binary file by uuencoded?  Mail will not accept binary
>files, but that doesn't mean that uuencoding must be used.
>-- 
>James Blustein                                        `Did you say "knives"?'
><jamie@uwo.ca>                                        `*Rotating* knives, yes.'

This seems a strange response to the original problem.  

You said mail will not accept binary files.  Actually that's
incorrect.  Mail will accept it.  However, some mail gateways
strip away the highest bit.  So, it's probably OK to say mail
will not accept binary files.

BUT, since you know this, uuencoding the binary file before 
sending it out is probably the most conventional remedy, as
any good consultant will suggest to a puzzled user.  Of course,
you may use "atob" instead of "uuencode", but isn't that the
same kind of action?



Bryan
From: rds@teak02.cray.com (Bob Swanson)
Newsgroups: comp.human-factors
Subject: Re: Voting Booths
Date: 11 Nov 92 22:30:51 GMT
Organization: Cray Research, Inc.
Originator: rds@teak02


In article <1992Nov11.123235.15218@porthos.cc.bellcore.com>, mf@dancer.uucp (24227-fusco) writes:
> In article <1992Nov11.045622.23693@microsoft.com> bethmo@microsoft.com (Beth Moursund) writes:
> >This discussion is interesting to me, because I've never seen anything
> >like the voting booths you're discussing.  In all the places I've
> >voted, you get your ballot (which is a long cardboard strip with
> >punchable holes), slide it into a slot in the voting booth, and then
> >use a stylus to punch one hole for each vote.  The book next to the
> >ballot lists the candidates/propositions, and clearly marks where
> >to stick the stylus for each.
> 
> 	I recently voted in NJ and I did not use a punch ballot,
> just pulled some levers.  In fact, I also worried that my vote(s)
> were registered since the booth attendents seemed to have some 
> trouble operating the levers on the outside of the booth before 
> the next person entered (reset levers?).
> 

There was a series of articles in the New Yorker a few years ago,
in which it was determined that mechanical voting machines
can be, and are regularly, compromised.  Entire votes lost,
due to malfunction, non-zeroing of counters by poll watchers
(belonging to the appropriate party), alteration of
vote tallys before they are read into the "official"
computers, and so on.  Interesting article, especially in
light of modern hacking practices.
-- 
:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
Bob Swanson                                          email: rds@cray.com
Cray Research Inc.                               phony co.: 612/683-5805
                          snailmail: 655F Lone Oak Dr., Eagan, MN  55121
Newsgroups: comp.human-factors
From: so@brownie.cs.wisc.edu (Bryan S. So)
Newsgroups: comp.human-factors
Subject: The Problem With UNIX
Date: 9 Nov 92 17:20:37 GMT
Article-I.D.: cs.1992Nov9.172037.15990
Organization: University of Wisconsin, Madison -- Computer Sciences Dept.

I am doing research on UNIX command line interface problems.
I am sure everyone has his/her favorite UNIX troubles, would
you post or email me what's your favorites?  What should have
been done by UNIX to resolve that problem in general?

Does anybody know of excellent papers in this area?  I know 
about Norman's "The Trouble with UNIX".

To start the discussion, consider the following problems:

    cat a b > b

    This is a general problem of trying to modify the input
    file.


    rm -filename_with_a_hyphen

    This is a general problem of name clash (clashing filename
    with command options.)


    mail somebody < a.out

    Sending binary file should be uuencoded first.  This is a
    general type conflict problem.


Bryan So
Newsgroups: comp.theory
From: kolount@leland.Stanford.EDU (Mihail N Kolountzakis)
Subject: Is the following problem in NP?
Keywords: NP, polynomials, equations, solvability
Organization: DSG, Stanford University, CA 94305, USA
Date: Mon, 9 Nov 92 21:51:48 GMT


INPUT: a polynomial F(x_1, ... , x_N) of bounded degree (say 10)
and integer coefficients (also bounded by say 100).

OUTPUT: YES iff there are _real_ numbers x_1, ... , x_N that satisfy F=0.

Please reply to "kolount@cauchy.stanford.edu".

Mike Kolountzakis




Newsgroups: comp.theory
From: richard@serss0 (Richard A Simm)
Subject: compressed trie table
Organization: Florida International University, Miami
Date: Fri, 6 Nov 1992 20:29:42 GMT

In the latest 'Software, Practice & Experience', an article is presented
detailing a new algorithm for handling tries. The new altorithm stores the
trie in two one-dimensional arrays. Ambiguities are resolved in a third
one-dimensional array. Apart from the sample code being buggy, I've run
across a problem implementing the authors' algorithm. I want to insert
the following two strings:
	to
	too

If these are the only two strings I want to insert, then I do the following:
	to: use case 1.
	too: use case 3 but a problem arises. The string 'to' will be
	     inserted in the BASE array. Because of this, I can no
	     longer recognize the string 'to'. I can make a special case
	     of one string being a subset of another in which case the
	     shorter string would have a 0 tacked on to the end (like a
	     C-style string) and then perform X_CHECK (1,'o'). The node
	     returned by X_CHECK would then be used to help match 'to'
	     by having as its value -1 to signal the end of the string.
	     The reason for doing XHECK(1,'o') is so we have BASE[1] > 0.


Any other ideas?


Albert Chin	richard@serss0.fiu.edu
From: deutsch+@cs.cmu.edu (Alain Deutsch)
Newsgroups: comp.theory
Subject: Re: Synthesizing loop invariants -- unsolvable?
Date: 6 Nov 92 20:22:26 GMT
Article-I.D.: cs.BxB9xH.3ty.2
Organization: School of Computer Science, Carnegie Mellon

Problem: explain why invariants are not computable in general.

Sketch: Consider a   program P  and  its operational  semantics defined by  a
Kripke structure:

	(State, -->, V)

where State is  a set  of  states   (usually infinite because   of  integers,
recursion or dynamic allocation); --> is a transition relation on State and V
is a valuation function which maps each state \gamma  to the set V(\gamma) of
atomic formulae true in this state.

Now because of the obvious isomorphism between program predicates and sets of
states (a predicate \Phi can be represented by the set of  states in which it
is true), the strongest global invariant is by definition the  sets of states
that can be reached from some set of initial I through the transitive closure
of the transition relation -->, which by [Pa69,Cl79,Co81] can be  computed as
a fixpoint, using the notation post(-->)(X) = {y | x \in X  ^  x --> y}:

		   *
 SGI[P]  = post(--> )(I)

         = lfp(\lambda X. I \cup post(-->)(X))


This least fixpoint  is well defined, as it  is the fixpoint   of a monotonic
operator on the (obviously complete) lattice of sets of states.

Now because the lattice of sets of  states has ordinal height \omega whenever
the sets of states is infinite, it follows that the computation of this least
fixpoint can require up to \omega iterations. Hence  SGI[P] is not computable
this way.

Another argument, less intuitive but probably stronger, based on Godel second
incompleteness theorem, appears in section 7.4.2.3.3 of [Co90].

References:

@Article{Park69,
  author = 	 "Park,D.M.R.",
  title = 	 "Fixpoint induction and proof program properties",
  journal = 	 "Machine {Intelligence}",
  year = 	 1969,
  volume = 	 5,
  pages = 	 "59--78",
  note = 	 "Edinburgh University Press"
}

@Article{Clarke79,
  author = 	 "Clarke,E.M.",
  title = 	 "Program Invariants as Fixedpoints",
  journal = 	 "Computing",
  year = 	 1979,
  volume = 	 21,
  pages = 	 "273--294"
}

@InProceedings{Cousot81,
  author = 	 "Cousot,P.",
  booktitle = 	 "Program Flow Analysis: Theory and Applications",
  title = 	 "Semantic foundations of program analysis",
  publisher = 	 "Prentice-Hall",
  year = 	 1981,
  pages = 	 "303--342"
}

@InBook{Cousot90,
  author = 	 "Cousot,P.",
  title = 	 "Methods and Logics for Proving Programs",
  pages =        "841--994",
  chapter =      "15",
  editor = 	 "van Leeuwen,J.",
  booktitle = 	 "Formal Models and Semantics",
  publisher = 	 "Elsevier Science Publisher \& The MIT Press",
  year = 	 1990,
  volume = 	 "B",
  note =         "ISBN 0-444-88074-7"
}
-- 
----
Alain Deutsch, Research Associate
Carnegie Mellon University -- School of Computer Science
Pittsburgh, PA 15213-3891, USA.
Newsgroups: comp.theory
From: thompson@atlas.socsci.umn.edu (T. Scott Thompson)
Subject: Re: Uniform noise in d-sphere
Reply-To: thompson@atlas.socsci.umn.edu
Organization: Economics Department, University of Minnesota
Date: Fri, 6 Nov 1992 17:26:57 GMT

jcbhrb@nic.cerf.net (Jacob Hirbawi) writes:

>In sci.math <1992Nov5.211723.26238@bnlux1.bnl.gov>
>Michael Murphy <murphy@sscdaq.phy.bnl.gov> writes:

>> I am trying to compute uniformly random noise inside a d-dimensional 
>> sphere.  I have identified two ways of doing so:
>>
>> [...]

>A third method might be the following: use spherical coordinates and
>pick uniform random numbers for each of the coordinates with the appropriate
>ranges. In three dimensions this would be:

>   (1) radius  uniform over (0,d)
>   (2) angle1  uniform over (0,2 pi)
>   (3) angle2  uniform over (0,  pi)

>This seems to be *too* simple but since I can't think of any point within the
>sphere being more favored than any other point I would think that the 
>distribution is in fact uniform. 

This does _not_ produce a uniform distribution since (2) and (3) do
not generate a uniform (on the sphere) distribution of directions.
(In fact, this distribution is given as an example of a paradox of
conditional probability in Billingsley's text "Probability and
Measure.")  Intuitively this is because too much probability is
concentrated at the poles.  (Consider that the value of angle1 is
almost irrelevant if angle two is close to zero or pi.)

Also, (1) concentrates too much probability near the center of the
sphere.  (Consider that neither angle matters much if the radius is
close to zero.)

One can generate a uniform distribution using a different form of
polar coordiantes, however.  Let t_1,...,t_{d-1} be independent and
uniformly distributed on [0,pi].  Let x_i = cos(t_i).  Let x_d be a
square root of 1 - (x_1)^2 - ... - (x_{d-1})^2.  Flip a coin to decide
whether to take the positive or negative square root.  Then the vector
x = (x_1,...,x_d) is uniformly distributed on the sphere.

Now let z be uniform on [0,1] and let r = z^(1/d).  (i.e. downweight
small radiuses so that they get probability proportional to the
surface area of the corresponding sphere.)  Then r*x will be uniformly
distributed on the unit ball in R^d.

I don't know how efficient this is, but it clearly dominates rejection
methods for large values of d.
--
T. Scott Thompson              email:  thompson@atlas.socsci.umn.edu
Department of Economics        phone:  (612) 625-0119
University of Minnesota        fax:    (612) 624-0209
Newsgroups: comp.theory
From: cailm@cs.tamu.edu (Liming Cai)
Subject: Dominating-Set optimization problem 
Organization: Computer Science Department, Texas A&M University
 
Date: Tue, 10 Nov 1992 18:28:45 GMT

-liming Cai


Newsgroups: comp.theory