# Difference between revisions of "Talk:Learning Haskell with Chess"

(4 intermediate revisions by 2 users not shown) | |||

Line 7: | Line 7: | ||

==full ruleset vs. reduced and simplified ruleset== |
==full ruleset vs. reduced and simplified ruleset== |
||

To implement the full ruleset you have to remember and consider previous states (in particular for castling rule and capturing en passant). |
To implement the full ruleset you have to remember and consider previous states (in particular for castling rule and capturing en passant). |
||

+ | |||

+ | -- Actually, this isn't so bad to do. It's entirely possibly by simply checking and updating flags. A single Int with a few bit masks could easily do it. One thing to consider as far as what needs to be encoded in any given position to be able to determine all legal moves is the FEN specification for representing moves: [[http://www.very-best.de/pgn-spec.htm#16]] -- Andrew Wagner. |
||

==representation of positions== |
==representation of positions== |
||

Is <hask>type Pos = (Int,Int)</hask> ok? Or better something like <hask>type Pos = (Row, Column), data Row = A | B | ... | H, data Column = ?</hask>. How to model the constraints (0<=x,y<=7)? |
Is <hask>type Pos = (Int,Int)</hask> ok? Or better something like <hask>type Pos = (Row, Column), data Row = A | B | ... | H, data Column = ?</hask>. How to model the constraints (0<=x,y<=7)? |
||

+ | |||

+ | -- There are several ways to handle this. Much work has been done in figuring out what the best way is, but I'll just point you to the first two articles at [[http://www.cis.uab.edu/hyatt/pubs.html]] I should point out that the theory behind using bitboards has advanced significantly since those articles were written, and I would strongly recommend looking at that. -- Andrew Wagner |
||

+ | |||

+ | -- Andrew, thank you for this link. The facts there strongly apply to imperative programming, however, I cannot see how to transfer these practices to functional programming without getting the fingers too dirty. -- Steffen Mazanek |
||

+ | |||

+ | -- I'm not quite sure what you see there that's inherently imperative. In fact, the whole point of bitboards is to get rid of loops as much as possible, which should please the functional programmer greatly. Can you possibly clarify? -- Andrew |
||

+ | |||

+ | ==more general game library== |
||

+ | |||

+ | Should students be confronted with a more general gametree generation (successor states-function as param) and minimax algorithm (eval-function as param)? |

## Latest revision as of 01:13, 21 March 2007

## Contents

## list handling vs. abstract data types (array)

Lists are very inefficient, but understanding list handling is important for understanding functional programming. On the other hand, using `Array`

would provide understanding for abstract data types.

## using state monad for the board

Only possible with advanced students, do not try this in introductory courses.

## full ruleset vs. reduced and simplified ruleset

To implement the full ruleset you have to remember and consider previous states (in particular for castling rule and capturing en passant).

-- Actually, this isn't so bad to do. It's entirely possibly by simply checking and updating flags. A single Int with a few bit masks could easily do it. One thing to consider as far as what needs to be encoded in any given position to be able to determine all legal moves is the FEN specification for representing moves: [[1]] -- Andrew Wagner.

## representation of positions

Is `type Pos = (Int,Int)`

ok? Or better something like `type Pos = (Row, Column), data Row = A | B | ... | H, data Column = ?`

. How to model the constraints (0<=x,y<=7)?

-- There are several ways to handle this. Much work has been done in figuring out what the best way is, but I'll just point you to the first two articles at [[2]] I should point out that the theory behind using bitboards has advanced significantly since those articles were written, and I would strongly recommend looking at that. -- Andrew Wagner

-- Andrew, thank you for this link. The facts there strongly apply to imperative programming, however, I cannot see how to transfer these practices to functional programming without getting the fingers too dirty. -- Steffen Mazanek

-- I'm not quite sure what you see there that's inherently imperative. In fact, the whole point of bitboards is to get rid of loops as much as possible, which should please the functional programmer greatly. Can you possibly clarify? -- Andrew

## more general game library

Should students be confronted with a more general gametree generation (successor states-function as param) and minimax algorithm (eval-function as param)?