From: Chris Capel
Subject: Battleship simulator
Date: 
Message-ID: <10qqvcvf35fv89e@corp.supernews.com>
Hi everyone,

I've programmed a simulator for the game battleship (description included in
file) so I could try out a few different strategies (idle curiosity,
mainly) and I thought I'd let you all know in case you want to try to
program a better strategy--see if you can beat mine. Also, as I'm fairly
new to lisp, I'd welcome any comments on the code itself. I think it's
pretty clean.

I played around yesterday with adding lots of declarations and cutting down
on consing, but I've taken all that out because it was just for practice
and the code's fast enough as it is. You can get a pretty good average
after running a strategy for 1000 rounds. You don't need to make 1,000,000
take less than a second.

I would the code in the message, but it's a tad long, so I'll just put it on
the web. If you can figure out how to make it shorter, I'm listening.

http://www.pdf23ds.net/battleship.lisp

Chris Capel

From: David Sletten
Subject: Re: Battleship simulator
Date: 
Message-ID: <YLfrd.55$Ew6.49@twister.socal.rr.com>
Chris Capel wrote:

> Hi everyone,
> 
> I've programmed a simulator for the game battleship (description included in
> file) so I could try out a few different strategies (idle curiosity,
> mainly) and I thought I'd let you all know in case you want to try to
> program a better strategy--see if you can beat mine. Also, as I'm fairly
> new to lisp, I'd welcome any comments on the code itself. I think it's
> pretty clean.
> 
> I played around yesterday with adding lots of declarations and cutting down
> on consing, but I've taken all that out because it was just for practice
> and the code's fast enough as it is. You can get a pretty good average
> after running a strategy for 1000 rounds. You don't need to make 1,000,000
> take less than a second.
> 
> I would the code in the message, but it's a tad long, so I'll just put it on
> the web. If you can figure out how to make it shorter, I'm listening.
> 
> http://www.pdf23ds.net/battleship.lisp
> 
> Chris Capel
> 
This is trivial (I'm going to bed), but the CASE in your function 
NEXT-POINT doesn't need to quote the keys:
(case direction
	(right (temp incf x y board-width 0))
	(down (temp incf y x board-height 0))
	(left (temp decf x y -1 (1- board-width)))
	(up (temp decf y x -1 (1- board-height))))

Anyway, I hope someone else can provide you with more useful feedback 
while I sleep. :)

David Sletten
From: Chris Capel
Subject: Re: Battleship simulator
Date: 
Message-ID: <10qr32om2f39ee4@corp.supernews.com>
David Sletten wrote:

> Chris Capel wrote:
> 
>> I played around yesterday with adding lots of declarations and cutting
>> down on consing, but I've taken all that out because it was just for
>> practice and the code's fast enough as it is. You can get a pretty good
>> average after running a strategy for 1000 rounds. You don't need to make
>> 1,000,000 take less than a second.
>> 
> This is trivial (I'm going to bed), but the CASE in your function
> NEXT-POINT doesn't need to quote the keys:
> (case direction
> (right (temp incf x y board-width 0))
> (down (temp incf y x board-height 0))
> (left (temp decf x y -1 (1- board-width)))
> (up (temp decf y x -1 (1- board-height))))

Hey, you're right. I wouldn't have known that.

Initially, though, it confuses me to see "right", "down", etc. without the
quote, because I wonder "Well, what are the values of those?". Of course,
the quote is implicit. But it looks weird. Because usually you have a case
that switches on a self-evaluating expression, like a number or character
or keyword, so the implicit quote doesn't matter. I wonder, is the style
you posted generally preferred?

Chris Capel
From: Björn Lindberg
Subject: Re: Battleship simulator
Date: 
Message-ID: <hcssm6qcjqk.fsf@my.nada.kth.se>
Chris Capel <······@iba.nktech.net> writes:

> David Sletten wrote:
> 
> > Chris Capel wrote:
> > 
> >> I played around yesterday with adding lots of declarations and cutting
> >> down on consing, but I've taken all that out because it was just for
> >> practice and the code's fast enough as it is. You can get a pretty good
> >> average after running a strategy for 1000 rounds. You don't need to make
> >> 1,000,000 take less than a second.
> >> 
> > This is trivial (I'm going to bed), but the CASE in your function
> > NEXT-POINT doesn't need to quote the keys:
> > (case direction
> > (right (temp incf x y board-width 0))
> > (down (temp incf y x board-height 0))
> > (left (temp decf x y -1 (1- board-width)))
> > (up (temp decf y x -1 (1- board-height))))
> 
> Hey, you're right. I wouldn't have known that.
> 
> Initially, though, it confuses me to see "right", "down", etc. without the
> quote, because I wonder "Well, what are the values of those?". Of course,
> the quote is implicit. But it looks weird. Because usually you have a case
> that switches on a self-evaluating expression, like a number or character
> or keyword, so the implicit quote doesn't matter. I wonder, is the style
> you posted generally preferred?

It is not only preferred, it is necessary. Quoting the keys is wrong
because the quote is actually reader sugar for (QUOTE ...). Observe
the outcome of this example:

  (case 'quote
    ('foo "foo")
    (t "t"))
  ==> "foo"


Bj�rn
From: Chris Capel
Subject: Re: Battleship simulator
Date: 
Message-ID: <10qrdm5duo9kse0@corp.supernews.com>
Bj�rn Lindberg wrote:

> It is not only preferred, it is necessary. Quoting the keys is wrong
> because the quote is actually reader sugar for (QUOTE ...). Observe
> the outcome of this example:
> 
>   (case 'quote
>     ('foo "foo")
>     (t "t"))
>   ==> "foo"

Oooooh. Because saying 'foo is like saying (quote foo) and (quote foo) is
taken as a list of symbols to match against. I see. Still, it doesn't lead
to wrong behavior in this case, and probably wouldn't in most cases, but it
is misleading.

My error in this case was not understanding that case takes an unevaluated
list of keys and not just one argument as its /keys/ clause. So saying
"(case x (foo t))" is just a shortcut for saying "(case x ((foo) t))".
That's a bit tricky.

Chris Capel
From: Zach Beane
Subject: Re: Battleship simulator
Date: 
Message-ID: <m3brde9kx9.fsf@unnamed.xach.com>
Chris Capel <······@iba.nktech.net> writes:

> My error in this case was not understanding that case takes an unevaluated
> list of keys and not just one argument as its /keys/ clause. So saying
> "(case x (foo t))" is just a shortcut for saying "(case x ((foo) t))".
> That's a bit tricky.

Whenever you see that an argument is "a designator for <something>", a
shortcut is around. It's pretty handy to write "foo" as a shortcut for
"(foo)", if one-item lists are common. From the glossary:

   list designator n. a designator for a list of objects; that is, an
   object that denotes a list and that is one of: a non-nil atom
   (denoting a singleton list whose element is that non-nil atom) or a
   proper list (denoting itself).

This is also handy with MAKE-ARRAY, which takes a designator for a
list of dimensions as its first argument. One-dimensional arrays are
convenient to write as (make-array n ...) instead of 
(make-array (list n) ...) (or `(n)).

Zach