Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #38832 > unrolled thread

First attempt at a Python prog (Chess)

Back to article view | Back to comp.lang.python

Contents

  First attempt at a Python prog (Chess) Chris Hinsley <chris.hinsley@gmail.com> - 2013-02-13 23:25 +0000
    Re: First attempt at a Python prog (Chess) Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-02-13 23:55 +0000
      Re: First attempt at a Python prog (Chess) Chris Hinsley <chris.hinsley@gmail.com> - 2013-02-14 01:31 +0000
    Re: First attempt at a Python prog (Chess) Tim Roberts <timr@probo.com> - 2013-02-13 22:05 -0800
      Re: First attempt at a Python prog (Chess) Chris Hinsley <chris.hinsley@gmail.com> - 2013-02-14 17:48 +0000
        Re: First attempt at a Python prog (Chess) Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-14 11:30 -0700
        Re: First attempt at a Python prog (Chess) Tim Roberts <timr@probo.com> - 2013-02-18 20:15 -0800
          Re: First attempt at a Python prog (Chess) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-19 06:24 +0000
          Re: First attempt at a Python prog (Chess) Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-19 12:41 -0700
    Re: First attempt at a Python prog (Chess) jkn <jkn_gg@nicorp.f9.co.uk> - 2013-02-14 13:14 -0800
      Re: First attempt at a Python prog (Chess) Chris Hinsley <chris.hinsley@gmail.com> - 2013-02-14 22:13 +0000
        Re: First attempt at a Python prog (Chess) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-14 22:09 -0500
    Re: First attempt at a Python prog (Chess) Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-14 21:05 -0800
    Re: First attempt at a Python prog (Chess) Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-02-15 11:22 +0000
      Re: First attempt at a Python prog (Chess) Neil Cerutti <neilc@norwich.edu> - 2013-02-15 16:17 +0000
        Re: First attempt at a Python prog (Chess) MRAB <python@mrabarnett.plus.com> - 2013-02-15 17:52 +0000
          Re: First attempt at a Python prog (Chess) Neil Cerutti <neilc@norwich.edu> - 2013-02-19 21:10 +0000
        Re: First attempt at a Python prog (Chess) Matt Jones <matt.walker.jones@gmail.com> - 2013-02-15 12:03 -0600
    Re: First attempt at a Python prog (Chess) Tim Golden <mail@timgolden.me.uk> - 2013-02-15 11:36 +0000
    Re: First attempt at a Python prog (Chess) Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-02-15 13:11 +0000
    Re: First attempt at a Python prog (Chess) Tim Golden <mail@timgolden.me.uk> - 2013-02-15 15:36 +0000
      Re: First attempt at a Python prog (Chess) Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-02-15 18:48 +0200
    Re: First attempt at a Python prog (Chess) Chris Angelico <rosuav@gmail.com> - 2013-02-16 02:49 +1100
    Re: First attempt at a Python prog (Chess) Tim Golden <mail@timgolden.me.uk> - 2013-02-15 17:37 +0000
    Re: First attempt at a Python prog (Chess) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-15 13:41 -0500
    Re: First attempt at a Python prog (Chess) Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-02-16 14:39 +0000

Page 2 of 2 — ← Prev page 1 [2]

#38924

On 15/02/2013 13:11, Oscar Benjamin wrote:
> On 15 February 2013 11:36, Tim Golden <mail@timgolden.me.uk> wrote:
>> And the "how shall we represent the board?" question is pretty
>> much the first thing any team asks themselves. And you always
>> get someone in favour of lists of lists, someone for one long
>> list,
> 
> I always get confused when doing this about which of my coordinates
> needs to be multiplied (i.e. whether I am in Fortran or C order).

How true. This last time, my team split into two: one half
to handle the display, the other working on the algorithm. We
ended up having to draw a really simple diagram on the back of
an envelope with the x,y pairs written out and pass it back
and forth as *everyone* kept forgetting which went first.

>> (Also I seem to remember that the OP was advised earlier precisely
>> to abandon lists of lists in favour of something else).
> 
> Actually the suggestion was for the list of lists (instead of a flat list).

Ah, ok. I'd only followed the thread casually. (And I was too lazy to
go back and check).

TJG

[toc] | [prev] | [next] | [standalone]

#38928

Tim Golden writes:
> On 15/02/2013 13:11, Oscar Benjamin wrote:
> > On 15 February 2013 11:36, Tim Golden wrote:
> >> And the "how shall we represent the board?" question is pretty
> >> much the first thing any team asks themselves. And you always get
> >> someone in favour of lists of lists, someone for one long list,
> > 
> > I always get confused when doing this about which of my
> > coordinates needs to be multiplied (i.e. whether I am in Fortran
> > or C order).
> 
> How true. This last time, my team split into two: one half to handle
> the display, the other working on the algorithm. We ended up having
> to draw a really simple diagram on the back of an envelope with the
> x,y pairs written out and pass it back and forth as *everyone* kept
> forgetting which went first.

Surely you knew to have f1(board, x, y) for getting whatever is at
(x,y) and f2(store, x, y, wev) for putting wev at (x,y). Why didn't
you do that?

[toc] | [prev] | [next] | [standalone]

#38925

On Sat, Feb 16, 2013 at 2:36 AM, Tim Golden <mail@timgolden.me.uk> wrote:
> How true. This last time, my team split into two: one half
> to handle the display, the other working on the algorithm. We
> ended up having to draw a really simple diagram on the back of
> an envelope with the x,y pairs written out and pass it back
> and forth as *everyone* kept forgetting which went first.

I'm sorry, I don't follow. People forgot that x comes before y, like
it does in everything algebraic? Or is it that people lost track of
which axis you called 'x' and which you called 'y'?

ChrisA

[toc] | [prev] | [next] | [standalone]

#38937

> On Sat, Feb 16, 2013 at 2:36 AM, Tim Golden <mail@timgolden.me.uk> wrote:
>> How true. This last time, my team split into two: one half
>> to handle the display, the other working on the algorithm. We
>> ended up having to draw a really simple diagram on the back of
>> an envelope with the x,y pairs written out and pass it back
>> and forth as *everyone* kept forgetting which went first.


>
On 15/02/2013 15:49, Chris Angelico wrote:
> I'm sorry, I don't follow. People forgot that x comes before y, like
> it does in everything algebraic? Or is it that people lost track of
> which axis you called 'x' and which you called 'y'?


 > On 15/02/2013 16:48, Jussi Piitulainen wrote:
 > Surely you knew to have f1(board, x, y) for getting whatever is at
 > (x,y) and f2(store, x, y, wev) for putting wev at (x,y). Why didn't
 > you do that?

To be honest I don't remember exactly what we did get confused
over; it was probably whether our origin was top left and/or
whether we were storing in row or in column order. But in any
case, my experience is that stuff which is perfectly easy to
reason about and write as Jussi has above when you're just
coding quietly on your own becomes a confused ball of mess as
soon as you're part of a Dojo team with 60 minutes to come up
with a solution. (Not saying that we couldn't have managed better;
merely that we didn't).

TJG

[toc] | [prev] | [next] | [standalone]

#38945

On Fri, 15 Feb 2013 11:36:43 +0000, Tim Golden <mail@timgolden.me.uk>
declaimed the following in gmane.comp.python.general:

> 
> I'm laughing slightly here because, at the monthly London Python
> Dojo, we often find ourselves implementing board-game mechanics
> of one sort or another: Boggle, Battleships, Sliding block,
> Connect 4, Noughts-and-Crosses, even things like Game of Life
> (which has a board of sorts).
> 
> And the "how shall we represent the board?" question is pretty
> much the first thing any team asks themselves. And you always
> get someone in favour of lists of lists, someone for one long
> list, someone who likes a string, someone (me) who likes a sparse
> dict keyed on coords, someone else likes nested defaultdicts,
> and occasionally more outlandish schemes.
>

	Ancient book
http://www.amazon.com/Programming-Proverbs-Programmers-computer-programming/dp/0810458209/ref=sr_1_1?s=books&ie=UTF8&qid=1360953438&sr=1-1&keywords=0810458209
as I recall (mine is in a box at a storage facility 16 miles away) used
a 10x10 board to implement a Checkers board. Since checkers move on the
diagonal, it gave "overflow" guards on the boundaries and somehow made
the addressing easier...
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#39003

On 15 February 2013 15:49, Chris Angelico <rosuav@gmail.com> wrote:
> On Sat, Feb 16, 2013 at 2:36 AM, Tim Golden <mail@timgolden.me.uk> wrote:
>> How true. This last time, my team split into two: one half
>> to handle the display, the other working on the algorithm. We
>> ended up having to draw a really simple diagram on the back of
>> an envelope with the x,y pairs written out and pass it back
>> and forth as *everyone* kept forgetting which went first.
>
> I'm sorry, I don't follow. People forgot that x comes before y, like
> it does in everything algebraic? Or is it that people lost track of
> which axis you called 'x' and which you called 'y'?

When you have a flat array and need to do a[x*N + y] to get an
element, the order is irrelevant. What matters is which of the
coordinates you multiply and what dimension of the array you multiply
it by. There are two equally good ways to do this, row-major and
column-major order:
http://en.wikipedia.org/wiki/Row-major_order

Any time you call into an API that expects a flattened array
representing a multidimensional array you need to check what order the
API expects. Typically a language has a convention such as C
(row-major) or Fortran (column-major). (According to that Wikipedia
page Python uses row-major, but I'm not really sure what that is
referring to).

Numpy allows you to specify the order when creating an array:
>>> import numpy as np
>>> aC = np.array([['a', 'b'], ['c', 'd']], dtype=str, order='C')
>>> aF = np.array([['a', 'b'], ['c', 'd']], dtype=str, order='F')
>>> aC
array([['a', 'b'],
       ['c', 'd']],
      dtype='|S1')
>>> aF
array([['a', 'b'],
       ['c', 'd']],
      dtype='|S1')

The different order in the two arrays above is transparent to Python
code that doesn't directly refer to the underlying memory arrangement:

>>> aC[0, 1]
'b'
>>> aF[0, 1]
'b'
>>> aC.strides
(2, 1)
>>> aF.strides
(1, 2)
>>> str(buffer(aC))
'abcd'
>>> str(buffer(aF))
'acbd'

This is useful when interfacing with linked Fortran and C libraries
(as is the case in scipy).

I find keeping track of what order I'm using when accessing the
elements of an array to be a pointless distraction. I would much
rather use an abstraction over the linear memory (such as a numpy
array) that enables me to forget all about it.


Oscar

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web