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:

<Date: Sat 28 Jul 84 21:37:46-PDT
<From: Kenneth Brooks <BROOKS@SU-SCORE.ARPA>
<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.

<Why don't we?  Why do we keep on reinventing the wheel, in the
<process neglecting to reinvent such amenities as the rubber tire?  I
<can answer for my own case: I have reimplemented many a standard
<textbook algorithm, and have reinvented several algorithms that might
<have been learned from a textbook, because I did not know where to
<look.  Other such programs may exist, yes - but buried how deep?  How
<long might it take to dig up the program from a thesis done in '72?

<I think we could do something very effective about this problem:
<apply some database technology and come up with an on-line database
<of algorithms.  What I would like to be able to do is come up and
<type in a key phrase like "balanced 2-3 tree" or "b-tree" or "command
<parsing" or "hidden surface".  The database should then come up with
<one or more headers, each of which could be delved into at will.
<Entries might be of several forms [.........]
------------------------------

<From: Ethan Bradford <BRADFORD@SU-SIERRA.ARPA>
<Subject: CS: Database of algorithms.

<        [Forwarded from the Stanford bboard by Laws@SRI-AI.]

<The ACM publishes a reference book (with periodic supplements) called
<"The Collected Algorithms of the ACM", which has most of the
<information you ask for, though it is on paper.  [.....]

I think that Ken Brooks' initial insight is that we could use a
reference on program *specifications* - what has been
accomplished in the form of working programs to date - as opposed
to *algorithms*, or how programs are implemented.  Ethan
Bradford's point about ACM recording algorithms is valid: a
database exists for algorithms and should serve for algorithm
reference.

I do not know of a corresponding database of program specifications.
(If there is one, please tell me how to find it!!)  If this
specification database were available, we could search for what has
been done in graphics and find the Sketchpad program as an example.
As in many things, knowing what has been done is half or more of the
battle: it shows what can be done and what has proved practical in at
least one instance.

A specification database would be more useful to me than the algorithm
database has been.  I usually have my own ideas on how my program
should be written - i.e., what algorithms should be used.  I will
typically use my own, proven (to me) algorithms because I understand
them and know that they work, and say that "I haven't time" to
research the literature for the "best" algorithms because the ones I
have are good enough.  (This cannot really be justified; however, it
is not uncommon, is it?)

I believe that I would actively use a specification database, however.
In a sense, I do now by maintaining an interest in new software
concepts.  I use examples of what *has* been done as examples of what
*can* be done and as raw material for what *should* be done.  Often,
the point of view embodied in an existing program provides a cricial
key to a simple formulation of a current problem.  Also, existing
programs often suggest simple program convenience features that can
make a program much more pleasant and effective to use.  The impact of
this information on programming time and resultant quality is large
and fairly obvious.

I think there is a case for a program specification database.  The
number of books discussing programs and languages sold every year
points to this interest.  I, too, think that such a database could be
of great, real help by suggesting structures and features used in
earlier programs that could be included in new programs.

Dave Wyland

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

Date: Monday, 6 August 1984, 14:22-PDT
From: Reynolds at RAND-UNIX
Subject: database of algorithms
To: Kenneth Brooks <BROOKS at SU-SCORE.ARPA>
Cc: cwr at WHITE

    Date: Sat 28 Jul 84 21:37:46-PDT
    From: Kenneth Brooks <BROOKS@SU-SCORE.ARPA>
    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 <TREITEL@SUMEX-AIM.ARPA>
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 <REM @ MIT-MC>
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.

<Exposition by REM>

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

Date: 7 August 1984 08:05-EDT
From: Robert Elton Maas <REM @ MIT-MC>
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
************************