Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ucbvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!cbosgd!ucbvax!daemon
From: daemon@ucbvax.UUCP
Newsgroups: fa.human-nets
Subject: HUMAN-NETS Digest   V7 #45
Message-ID: <1551@ucbvax.UUCP>
Date: Wed, 8-Aug-84 22:53:20 EDT
Article-I.D.: ucbvax.1551
Posted: Wed Aug  8 22:53:20 1984
Date-Received: Thu, 9-Aug-84 06:56:06 EDT
Sender: daemon@ucbvax.UUCP
Organization: U.C. Berkeley
Lines: 259

From MCGREW@RUTGERS.ARPA  Wed Aug  8 19:52:29 1984

HUMAN-NETS Digest       Wednesday, 8 Aug 1984      Volume 7 : Issue 45

Today's Topics:
                   Query - Latitude and Longitude,
    Response to Query - Program Specification Database (2 msgs) &
                         Hacker vs. Cracker,
                    Chess - The Delphi Experiment
----------------------------------------------------------------------

Date: 8 Aug 84 16:07:07 PDT (Wednesday)
From: Hodges.pa@XEROX.ARPA
Subject: Latitude and Longitude encoding question...
To: Astronomy^.PA@XEROX.ARPA,
cc: Kluger.pa@XEROX.ARPA

Hi,

I need to keep latitude and longitude information in a record
containing information about a network.  The initial values will be in
ascii text contained in a string (e.g. "109 26 33" ).  I expect the
units of the initial values will always be degrees, minutes, and
seconds.  I want to find out if anyone is aware of standard latitude
and longitude encoding (packing?) schemes.  Are there reasons other
than economy of storage to encode latitude and longitude?  Why?
(comparison operations, etc?)


Thanks for your help,

        Jeff Hodges

------------------------------

Date: Mon 6 Aug 84 11:05:13-PDT
From: WYLAND@SRI-KL.ARPA
Subject: Program Specification Database

I think the following interchange talks about a good idea but
just manages to miss it:




Cc: cwr at WHITE

    Date: Sat 28 Jul 84 21:37:46-PDT
    From: Kenneth Brooks 
    Subject: database of algorithms

    [Forwarded (with permission) from the Stanford bboard by
     Laws@SRI-AI.]

    I have just come back inspired from Siggraph.  At one of the panel
    sessions there, Alan Kay showed a demo film of Sketchpad, the
    first interactive computer graphics editor.  It has a lot of
    really excellent features, not seen in many graphics editing
    systems now being written and sold.  He commented, we ought to be
    standing on the shoulders of others.  We ought to be doing AT
    LEAST as well as systems of the distant past.

Basically, of course, I agree with what you are trying to say --
avoiding duplication of effort is like Mom and apple pie.  Alan (and
Mark Vickers who showed that tape in the session I was in) state a
good GOAL, but no one has discovered how to achieve it.  The library
of algorithms is of no real help at all.

Not all things get better through time, look at air quality.  We
cannot automatically expect that if program X is written before
program Y that Y is necessarily better than X.  The issue is more than
simple ignorance of what has gone before.  Program Y is likely written
under very different constraints (different CPU, different display
device type (eg vector/raster), different graphical input devices).
This is not just a matter of "device independence" but rather of
different user interface techniques being more appropriate for
different types of hardware.  (Newer faster hardware make fancier user
interaction styles practical.)

Sketchpad was a very large system (especially for its day), very few
of its algorithms were particularly unique.  A library of algorithms
would not address this problem -- its just one of software bulk and
non-trans-portability.
-c

------------------------------

Date: Sun 5 Aug 84 14:50:46-PDT
From: Richard Treitel 
Subject: Re: HUMAN-NETS Digest   V7 #44

re:  Crackers and Hackers

A nice simple easily memorisable definition is the following:

 "A cracker is a CRiminally inclined hACKER"

Some people may take exception to the implication that even a minority
of hackers have criminal inclinations, and others may argue that most
crackers are not talented enough to deserve to be called hackers.  I
get more and more sympathetic to Mark Crispin's fondness for the plain
old word "vandal".

                                                - Richard

------------------------------

Date: 7 August 1984 07:41-EDT
From: Robert Elton Maas 
Subject: hacker vs. cracker
To: wookie @ RICE



A "hacker" is somebody who has a penchant for understanding how
computer systems really work instead of the misleading or incomplete
descriptions that occur in documentation, and using such knowledge for
making things work more efficiently than by advertised means or for
making things work that seem impossible based on published
information.

A "cracker" is somebody who has a penchant for violating the security
of computer systems.

It used to be the two were related, if you were an expert at the
security aspects of a system you could possibly figure out how to
violate them. But now with thousands of random people banging away at
a security system until one person accidently discovers a flaw in it,
and that one person advertising a recipe for violating the security on
hundreds of bulletin boards arond the country, then thousands of
random users of those bulletin boards using that recipe to violate
that one system, you don't have to know anything about a system to
break into it using a recipe you happen to see on a bulletin board, so
crackers aren't necessarily (or even usually) hackers any more.



------------------------------

Date: 7 August 1984 08:05-EDT
From: Robert Elton Maas 
Subject: Delphi Experiment: group play against machine -> just people
To: mclure @ SRI-UNIX

I'd be more interested in a delphi experiment with Go instead of
Chess. Pick some starting position (probably not start of game, there
are too many good ways to play the fuseki) and see if we can converge
on the optimum way for both sides to play through to the end. Allow
backtracking at any time, thus if you suddenly see where one side made
a mistake you can change your vote at that point. If changed vote(s)
cause an alternate branch to have largest vote, the experiment shifts
to explore that branch instead of the one that had largest vote
before. Either allow everyone to vote for both black and white moves,
or divide the membership into two teams and have them select only
their own moves not opponents.

Note that my method doesn't require a go-playing program/machine to
play one side of the game.

To speed up the experiment, allow a voter to specify a whole sequence
of moves in advance, contingent on the opponent choosing the same move
as in the sequence. (For example: now I move ..., if he replies ...
then I conterreply ..., etc.; abbreviated of course.) So long as the
first move agrees with the voted move and the reply agrees with the
voted reply then the next move will be counted as a vote.

------------------------------

End of HUMAN-NETS Digest
************************