Hi,
I’ve (very recently) started with julia and decided I would migrate my (java-) chess-engine to julia.
Installation of the environment and ide (vs code) has been pretty smooth and I like working in the repl, which neatly complements my need to get aquainted with lots of new constructs and concepts of the language. I have plenty of experience, in general, hacking basic & 6510-assembler as a preteen (back in the 80s), then turbo-pascal & C(++), java, sql, R and whatever else I had to deal with, in various challenges as a freelancer (even pl/1 on a mainframe for a while). Nowadays, I’m not coding that much, anymore, but am trying to stay up-to-date with the developments on a practical level.
My first goal is to migrate the utility-, debugging- and logging-functions of the engine to julia. It’s the most boring part of it, but essential for a clean migration and it’s also my opportunity to learn the constructs, patterns & tools, julia provides, before I need my brain for more critical (and performance-relevant!) pieces of code, which include a lot of bit-fiddling on integers, processor intrinsics, branch-avoidance, etc…
…however, I’ve already gotten stuck, trying to understand the way, julia indexes into arrays. I know about the column-major indexing, etc. - so one might think “how hard can that even be?”
…well, turns out: Harder than I thought:
const DISPLAY_MARKED = "|"
const DISPLAY_NOTMARKED = " "
const DISPLAY_PIECE = "O"
const DISPLAY_NOPIECE = " "
const DISPLAY_SQUARE = [ (DISPLAY_NOTMARKED * DISPLAY_NOPIECE * DISPLAY_NOTMARKED)
(DISPLAY_MARKED * DISPLAY_NOPIECE * DISPLAY_MARKED)
; (DISPLAY_NOTMARKED * DISPLAY_PIECE * DISPLAY_NOTMARKED)
(DISPLAY_MARKED * DISPLAY_PIECE * DISPLAY_MARKED)
]
…these are some basic definitions of global constants to be used for pure utility- / debugging-purposes of displaying human-readable bitboards (= 64bit unsigned integers), representing certain aspects of a chess position.
The idea of DISPLAY_SQUARE
is to generate a very simple constant 2x2 lookup-table (with Strings of length 3), to help with generating strings, being printed on the console (only, when testing / debugging), showing the state of 3 bitboards (3x UInt64
), projected on one 8x8 chessboard. For example all white pawns (first bitboard) vs. all black pieces (2nd bitboard) and all the squares, the white pawns can move to, including captures (3rd bitboard) of black pieces, like here…
In the example, I’m expecting to index into DISPLAY_SQUARE[i1][i2]
with i1/i2==2
, when there is a piece on a square / a white pawn can move to that square (capturing in case there is a piece) and ...==1
, otherwise. (There are also other use-cases for this debugging-pattern, i.e. 4 possible states of every square depending on 2…3 bitboards = UInt64
s).
However, it’s not working, like I’m expecting (I fell back to some if-then-else
logic, for the example, above). This piece of code is not critical (for debugging, only) but the engine-core will have to use a lot of other / different 2d or 3d lookup-tables for performance-critical parts, also (luckily no strings, though, there).
For some reason, I’m ending up with a 1d-array of cardinality 4. What am I missing?!?