Copy Link
Add to Bookmark
Report
AIList Digest Volume 2 Issue 048
AIList Digest Monday, 16 Apr 1984 Volume 2 : Issue 48
Today's Topics:
Applications - Business AI Request,
Natural Language - Metaphor References,
AI Literature - Book Prices,
AI Jobs - Noncompetition Agreements,
AI Computing - Discussion
----------------------------------------------------------------------
Date: Mon, 16 Apr 84 00:47:17 pst
From: syming%B.CC@Berkeley
Subject: AI for Business?
I am soliciting any information on the application of artificial intelligence
and/or expert system techniques on the area of business administration such
as marketing, finance, production/operation, accounting, organizational
behavior ... etc. Any information (e.g., on-going project, current reseach,
new idea, trends ...) are greatly appreciated.
Syming Hwang
School of Business Administration, U.C. Berkeley, 415-642-2070 (ofc)
350 Barrows Hall, U.C. Berkeley, Bekerley, CA 94720
syming%B.CC@Berkeley.ARPA
------------------------------
Date: Mon 16 Apr 84 02:21:16-EST
From: MDC.WAYNE%MIT-OZ@MIT-MC.ARPA
Subject: Poetics Today & Metaphor
The current issue of *Poetics Today* (V.4, N.2, 1983) is
specially dedicated to the subject of metaphor, and contains four
weighty articles by Umberto Eco, Eddy M. Zemach, Inez Hedges, and
Jan Wojcik. The article by Eco (who is considered by many to be
the foremost living literary theorist and semiotician in the
world) is especially useful.
Eco provides a glimpse of just how vast is the literature on
metaphor:
"The 'most luminous, and therefore the most necessary and
frequent' (Vico) of all tropes, the metaphor, defies every
encyclopedic entry. Above all because it has been the object of
philosophical, linguistic, aesthetic and psychological reflection
since the beginning of time. Shibles's 1971 bibliography on the
metaphor records around 3000 titles; and yet, even before 1971,
it overlooks authors like Fontanier, and almost all of Heidegger
and Greimas--and of course does not mention, after the research
in componential semantics, the successive studies on the logic of
natural languages, the work of Henry, Group u of Lieges, Ricoeur,
Samuel Levin, and the latest text linguistics and pragmatics."
Eco makes some remarks on the subject of metaphor which are
highly pertinent to AI researchers:
"No algorithm exists for metaphor, nor can a metaphor be
produced by means of a computer's precise instructions, no matter
what the volume of organized information to be fed in. The
success of a metaphor is a function of the sociocultural format
of the interpreting subjects' encyclopedia. In this perspective,
metaphors are produced solely on the basis of a rich cultural
framework, on the basis, that is, of a universe of content that
is already organized into networks of interpretants, which decide
(semiotically) upon the identities and differences of properties.
At the same time this content universe, whose format postulates
itself not as rigidly hierarchized, but rather according to Model
Q, alone derives from the metaphorical production and
interpretation the opportunity to restructure itself into new
modes of similarity and dissimilarity."
The journal *Poetics Today* is a rich source of speculation
and analysis for anyone exploring the more subtle structures and
processes of natural language understanding.
--Wayne McGuire <mdc.wayne@MIT-OZ>
------------------------------
Date: Fri, 13 Apr 84 16:14:56 PST
From: Koenraad Lecot <koen@UCLA-CS.ARPA>
Subject: Synapse Books Prices
I remember a message on the AIList that mentioned Synapse Books as
a [...] publisher of AI books. Have you seen their 1984 catalog ?
It contains two new "books" by a certain R.K. Miller, one at $200 and
the other at $485 ...
I knew that the prices of AI books were going up but this is crazy ..
[I remember an ad for a reprint of key expert systems papers for over
$1000 a year or two ago. This wasn't a Comtex microfiche collection
(about $2000 per set), just a reprint compendium marketed for corporations
and Wall Street types. -- KIL]
------------------------------
Date: 14 Apr 1984 11:59-PST
From: fc%USC-CSE@USC-ECL.ARPA
Subject: Noncompetition Agreements
I don't know about you, but whenever I am given a contract to
sign, I simply cross out anything I'm not willing to agree to and sign
what remains. If they want me, they sign, if they don't they don't. In
my experience, 95% of the time, they just sign and take what they get.
The other 5% of the time, they try to bargain, and I simply refuse to
yield on the issues that are important to me. At that point we either
agree or don't. The point is, that you should only agree to the things
that seem reasonable to you, and then only if you understand the legal
ramifications of what you are signing.
Frankly, I wouldn't work for anyone who felt the need to bind me
to them by an exclusive use of my brain contract. First of all, it's my
brain not theirs. Second of all, they must be in pretty bad stead with
their employees if they have to use the law to force them to stay.
Companies that are really good don't have to force employees to stay,
the employees stay because they believe in the company and they get the
rewards they seek. Figure out what you want and what you're willing to
give for it, don't do what you don't believe in just because others are
doing it.
Fred
------------------------------
Date: 13 Apr 84 16:33:52-EST (Fri)
From: Brian Nixon <nixon%toronto.csnet@csnet-relay.arpa>
Subject: Non-competition clauses
At least in Canada, the courts usually take a low view of such clauses
in employment contracts, UNLESS they are severely restricted in scope, e.g.
are for a period of less than 6 months, apply only to taking a job within
the same city, apply only to taking a job within a particular industry.
Brian Nixon, Dept. of Computer Science, Univ. of Toronto.
------------------------------
Date: 15 April 1984 17:53-EST
From: Steven A. Swernofsky <SASW @ MIT-MC>
Subject: Non-competition clauses
An excellent article on ''covenants not to compete'' and other non-
disclosure agreements is Davidson, ''Constructing OEM Nondisclosure
Agreements'', 24 Jurimetrics Journal 127 (1984). The author notes that
after-employment restrictions are strong medicine, and therefore they
are narrowly construed as to time and subject matter. In some states
(e.g., California) they are impermissible except in narrow
circumstances (such as the sale of a business and the like). Likely
the best policy is to consult a lawyer.
If you really wish to steer students away from that company, I would
think the best way would be to name names. Their employment terms are
hardly a secret in themselves.
-- Steve
------------------------------
Date: Sun, 15 Apr 1984 10:19 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
Subject: Employment restrictions
Of the responses I've received, both by mail and in person, several have
said that a three-year paid sabbatical wouldn't be so bad (but you would
be prevented from starting a company or doing anything that involves
significant machine resources or a team of people), several have
said that the clause probably wouldn't stand up in court (but it's no
fun to fight a big company in court), and many have said that this policy
would keep lots of good people away from the company in question.
Nobody has told me about any similar clause used by another company.
Some consulting firms require their employees to agree not to jump over
to work for the clients for a year or so, but that still leaves them with
lots of options within the field of AI.
In any event, the company that started all this is now reconsidering
their position and are trying to find some less restrictive way to
protect their proprietary information, so the whole issue may soon be
moot. It's nice to find a company where the lawyers still work for the
researchers, and not vice versa.
-- Scott Fahlman
------------------------------
Date: 9 Apr 84 22:55:52-PST (Mon)
From: hplabs!hao!cires!nbires!opus!rcd @ Ucb-Vax
Subject: Re: Stolfo's call for discussion
Article-I.D.: opus.346
>One way AI programming is different from much of the programming in other
>fields is that for AI it is often impossible to produce a complete set of
>specifications before beginning to code.
>
>The accepted wisdom of software engineering is that one should have a
>complete, final set of specifications for a program before writing a
>single line of code. It is recognized that this is an ideal, not
>typical reality, since often it is only during coding that one finds
>the last bugs in the specs. However, it is held up as a goal to
>be approached as closely as possible.
I submit that these statements are NOT correct in general for non-AI
programs. Systems whose implementations are not preceded by complete
specifications include those which
- involve new hardware whose actual capability (e.g., speed) is
uncertain.
- are designed with sufficiently new hardware and/or are to be
manufactured in sufficient quantity that hardware price per-
formance tradeoffs will change significantly in the course of the
development.
- require user-interface decisions for which no existing body of
knowledge exists (or is adequate) - thus the user interface is
strongly prototype (read: trial/error) oriented.
as well as the generally-understood characteristics of AI programs. In
some sense, my criteria are equivalent to "systems which don't represent
problems already solved in some way already" - and there are a lot of such
problems.
--
"A friend of the devil is a friend of mine." Dick Dunn
{hao,ucbvax,allegra}!nbires!rcd (303) 444-5710 x3086
------------------------------
Date: 11 Apr 84 20:13:01-PST (Wed)
From: hplabs!tektronix!uw-beaver!teltone!warren @ Ucb-Vax
Subject: Re: Stolfo's call for discussion
Article-I.D.: teltone.252
Unexpectedness and lack of pre-specification occur in many professional
programming environments. In AI particulary it occurs because
experimentation reveals unexpected results, as in all science.
In hardware (device-driver) code it occurs because the specs lie or
omit important details, or because you make an "alternative
interpretation".
In over-organized environments, where all the details are spelled out
to the nth degree in a stack of documents 8 feet high, unexpectedness
comes when you read the spec and discover the author was a complete idiot
having a very bad day. I have seen alleged specs that were signed off
by all kinds of high mucky-mucks that are completely, totally, zonkers.
Not just in error, but complete jibberish, having no visible association
with either reality or thought, not to mention the project at hand.
At the very least, they are simply out of date. Something crucial has
changed since the specs were written.
In business environments, it occurs when the president of the company
says he just changed the way records are to be kept, and besides, doesn't
like the looks of the reports he agreed to several months ago. Whats a
programmer to do ? Tell the boss to shove it ? The single most difficult
kind of programming occurs when 1) The user is your boss (or "has power").
2) The user is fairly stupid. 3) The user/boss is good enough of a con
artist to prevent the programmer from leaving. It is admitted, however,
that the difficulty is not technical, per se, but political.
All the above examples are from my professional experience, which spans
over ten years. None of the situations are very unusual. Unexpectedness
is part of our job. In any case, 90 to 99% of the code in the AI systems
I've seen are much like any other program. There are parsers, allocators,
symbol tables, error messages, and so on. I'll let others testify to
the remainder of the code, its been a while.
warren
------------------------------
End of AIList Digest
********************
