Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!news.xnet.com!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newspeer.radix.net!uunet!ash.uu.net!world!not-for-mail
From: buzzard@TheWorld.com (Sean T Barrett)
Subject: Re: Purity in Programming
Sender: news@world.std.com (Mr Usenet Himself)
Message-ID: <GqGs50.7Es@world.std.com>
Date: Thu, 24 Jan 2002 22:36:34 GMT
References: <d4b6f29f.0201121136.235ddbc0@posting.google.com> <3vh38.5589$Wf1.2131029@ruti.visi.com> <GqEyLK.2JG@world.std.com> <9HY38.7712$Wf1.2501715@ruti.visi.com>
NNTP-Posting-Host: shell01.theworld.com
Organization: The World Public Access UNIX, Brookline, MA
X-Newsreader: trn 4.0-test72 (19 April 1999)
Lines: 95
Xref: news.duke.edu rec.arts.int-fiction:97786

David Thornley <thornley@visi.com> wrote:
>[snip good stuff]
[snip good stuff]

We seem to be going in circles: I say "the halting problem
shows that SOME cases are hard; being NP-complete or NP-hard
shows that SOME cases are slow; we know the languages used in
IF allow creating those sorts of cases; do we really know that
actual practical cases from IF are really either of those?"

And then you say, "Yes, because here's one that requires a
halting test, and here's one that depends on multiple things
so its problem is one that is known to be in an NP-hard
domain."

>However, at least one game in the
>archive depends on a complicated calculation in order to
>get to a winning state.  In fact there is a command that causes
>that calculation to allow the game to proceed, but that's not
>the sort of thing that can be a priori determined.

Why can't it be a priori determined? It sounds like begging
the question since that's what we're discussing creating, but
I suspect I'm just missing some distinction you're trying to
make.

>>The nice thing about a proving system is that it could prove "there
>>is no way to make this game unwinnable". It's not possible to do
>>that by just feeding a walkthrough into the game.
>>
>Except that that doesn't work.
>
>In the general sense, there is no way to do that, since there may
>be a potential path to winnability that includes something that
>may or may not work.

Huh? That's what the prover is supposed to do.

>In a more restricted sense, analyzing
>multiple dependent solutions to problems turns out to be NP-hard.

Meaning what? Integer packing is NP-complete, I think, but that
didn't stop me from using it once-per-move on an AI mastermind-player
that could solve a hundred problems per second. (The problem size
was only 9, so the full search didnt take long.)

Or for a more useful example, integer packing is NP-hard, and
making change is a case of integer packing, but if you have
sufficient quantities of each coin, making change is not NP-hard.

>Varicella is a good example of these; if you altered Varicella
>somehow it would be exceedingly difficult to prove it winnable
>mechanically, except by supplying a transcript.

You're not being concrete enough here for me to understand
your objections.

The main thing that seems problematic for automatic verification
is the exponential explosion of possibilities (all the possible
locations you might be, all the objects you might or might not
have).

I'm guessing those can be made tractable by adding human-suggested
rules for grouping actions into tasks, basically very similar to
the way AI planning avoids exponential explosion by using tasks
and subtasks and paramterized scripts for forming goals and creating
plans for those goals.

In fact, one way to tackle the problem would be to simply write
the AI who can solve your game "from any state", give it a list
of the non-reversible actions it can take, and have it explore
the space it can reach non-reversibly, and try to solve the game
from each of those states.

>>Underworld II had a bug where you could go through a conversation
>>twice or something, and by doing so get some internal flags into
>>an invalid state. This brought the "servant strike" plot to a halt
>>and made the game unwinnable. Automated validation of conversations
>>might have caught it.
>>
>This sounds like a possible source bug, forcing the program to
>be dealt with as a standard computer program, rather than as a
>more abstract game program.

Umm, well, there is no such thing as an "abstract game program",
game programs are computer programs, and anything that applies to
the one should apply to the other, shouldn't it?

And how do you "deal with a standard compute program?" One way is
with CASE tools and program proving (which is related to what
we're talking about here), and the other is by "hope that your
testers find it". Well, we did the latter, and they didn't find
it, so I'm interested in some simplified version of the former.

Sean
