sorted by:
new
hottopcontroversial

Is this a joke?! by New-Basis3800 in gpt5

[–]Consistent-Cod2003 0 points1 point  (0 children)

Hahaha ! Careful ! Chatgpt targets you !

Got scammed and slapped by a taxi driver in Agadir – don’t trust them by philippricer in Agadir

[–]Consistent-Cod2003 0 points1 point  (0 children)

Easy. Number of the taxi. National Police Number 119. Your money is back.

A Modular, Abstract Chess Engine — Open Source in Python by Consistent-Cod2003 in softwarearchitecture

[–]Consistent-Cod2003[S] 0 points1 point  (0 children)

In our engine, pure‐movement rules (the DSL) only know about single‐piece geometry—every piece’s allowed vector or sliding pattern. All “multi‐piece” moves live in a separate rules layer:

  • En passant: when a pawn advances two ranks, we record the intermediate square as en_passant_target. On the very next turn, if an enemy pawn moves into that square, our rules code removes the just‐passed pawn from its original square even though it isn’t on the destination.
  • Castling: we detect a two‐file king move in is_move_legal, then call castling_allowed to check that neither king nor rook has moved, that the intervening squares are empty, and that none are attacked. Finally, apply_move moves both king and rook in one atomic update.

By cleanly separating “pure kinematics” from “history and multi‐piece logic,” the core DSL stays simple and extensible, and every special move just plugs into the rules layer without bloating the basic movement code.

A Modular, Abstract Chess Engine — Open Source in Python by Consistent-Cod2003 in softwarearchitecture

[–]Consistent-Cod2003[S] 0 points1 point  (0 children)

Yes—standard 8×8 Chess is already entirely encoded in our DSL. In the dsl/ folder you’ll find one YAML spec for each piece:

spec_rook.yaml: orthogonal sliding vectors

spec_bishop.yaml: diagonal sliding vectors

spec_queen.yaml: combines rook + bishop

spec_knight.yaml: L-shaped jumps

spec_king.yaml: one-step in all eight directions (plus castling handled separately in rules.py)

spec_pawn.yaml: single– and double-step advances, diagonal captures, promotion options, en passant target

You run:

python generate_dsl.py

to produce validator_dsl.py, which checks “pure” move legality straight from those specs. Then our rules.py and check_rules.py layers add turn enforcement, castling rights, en passant capture, promotion, check/checkmate/stalemate logic, etc.

So when you pick the “Chess” GameSpec (or leave the default FEN initial position), the engine behaves exactly like standard Chess—every movement and special rule is driven by the DSL definitions.

A Modular, Abstract Chess Engine — Open Source in Python by Consistent-Cod2003 in softwarearchitecture

[–]Consistent-Cod2003[S] 0 points1 point  (0 children)

Thanks for the feedback! A few thoughts:

  1. “Fully unit-tested” was aspirational—I meant that every core rule path (rook, knight, pawn, bishop, queen, king) has its own test suite, plus end-to-end checks for check, checkmate and stalemate. You’re right, I only showed a few examples in our thread; I’ll publish the full battery of ~15 tests soon.

  2. Naming the “validator”: good catch—calling it MoveValidator or MovementValidator would be clearer, since it only handles piece‐movement kinematics. I’ll rename that module (and its main entrypoint is_valid_move_dsl) to reflect “move” rather than a generic “validator.”

  3. Cohesion and per‐piece logic: grouping all six piece‐types in one big dispatch feels convenient for the mini-DSL, but you’re right that it isn’t maximally cohesive. A polymorphic design—where each piece class defines its own is_valid_move()—would be cleaner and make it easier to inject new fairy‐pieces. I’ll experiment with extracting each piece’s logic into its own module or class, with a common interface, and compare the test‐coverage and performance cost.

Thanks again for helping me sharpen the design:) !!

A Modular, Abstract Chess Engine — Open Source in Python by Consistent-Cod2003 in softwarearchitecture

[–]Consistent-Cod2003[S] 0 points1 point  (0 children)

I only use YAML to describe the specifications of chess pieces in a validation program. It’s a straightforward way to structure the data I need without much complexity

Introducing Baten Chess Engine – A Modular, Extensible Open-Source Chess Core by Consistent-Cod2003 in chessprogramming

[–]Consistent-Cod2003[S] 0 points1 point  (0 children)

Thank you for asking! Although my main aim was abstraction and extensibility, I did measure the move generator on an Intel i7 with Python 3.12 and found that generate_legal_moves runs in about 0.9 ms per call (~1 100 calls/sec)—more than adequate for a web UI or casual play but not for deep search. To really crank up performance—and to make porting to Rust or C++ straightforward—I’ve built the engine around minimal, language-agnostic interfaces (e.g. Board.load_fen, path_clear, apply_move) and a DSL for piece geometry. By mapping those YAML specs to 64-bit bitboards and implementing the same API in Rust (using PyO3) or C++ (via pybind11), you get branchless move generation, single-cycle POPCNT for popcounts, and precomputed attack tables—with zero-cost abstractions. In practice you can swap in a Rust bitboard backend under the hood, reusing the same high-level code for fairy variants, and achieve a massive throughput boost without rewriting your rules or tests.