alexanderhott/chess_hackathon_23

hello there 🌊, i'm alex ott

I love picking things apart to figure out how they work and I'm always looking for new problems to solve. My interests lie in machine learning, networking, cybersecurity, and backend development.

⚡️ i'm currently

• 🖊️ Leading the Cyber Security club at my university
• 👨‍💻 hacking into the mainframe
• ☕ drinking tea

🕜 Recent Activity

1. ❗ Opened issue #2 in AlexanderHott/dronestats
2. 🗣 Commented on #8759 in python/typeshed
3. 🗣 Commented on #3621 in shadcn-ui/ui
4. ❗ Opened issue #3621 in shadcn-ui/ui
5. 🗣 Commented on #524 in maruohon/litematica

🚀 tech heap (stacks are overrated)

         

     

   

 

---

chess_hackathon_23's Issues

dynamic depth search (keep searching until no more trades / checks)

CURRENTLY UNRESOLVED

Why is checkmate crashing?
Double check that we fixed the transition table repetition issue
Check that it's not still doing weird moves
Add transition table to the quiescence

piece heatmaps (interpolate to endgame)

reconsider how search_all_captures should function with checks

1. this is easy to disable if we decide not to use it
2. as is, it doesn't do so much, since if white checks black in the middle of the search sequence, black must capture or check in response for the sequence to continue
3. we could fix this by allowing moving away from check moves but this would result in infinite loops
4. maybe transition tables would help?

Engine Improvements

Logic

• #9
• king safety
• iterative deepening
• #10
• #12
• prioritize checks when ordering moves
• transition tables
• openings
• endgame
• Bongcloud Detection™
• prioritize bishop pairs / correct bishop color
  • https://www.chessprogramming.org/Simplified_Evaluation_Function#Piece_Values
• pawn structure

Perf

• partial sort moves?
• Caching board positions (so if you reach the same position two different ways you don't have to re-eval the board)
• Parallel Search
  • https://www.chessprogramming.org/Parallel_Search
  • https://www.chessprogramming.org/Young_Brothers_Wait_Concept
  • https://arxiv.org/pdf/1908.11660.pdf
  • https://groups.google.com/g/comp.ai.games/c/a3KRe89ALS4

UI via Jupyter Lab Notebooks

Performance profiling

cProfile module

https://github.com/pyutils/line_profiler

Threefold vs Fivefold repetition

Currently, the engine and testing framework only take the automated fivefold repetition rule into account. I believe this can be fixed with always including claim_draw=True when testing for game end.

Testing Framework

• get eval/move for fen
• performance logging (moves searched, time)
• play against other (previous) bots
• use git worktree to play previous bots against themselves
• use git version tags to play previous bots against the current one.

Figure out how the final submission should look

It's a bit unclear to me how they expect our final submission to look. The style of the initial skeleton code is dubious, and I'd just delete all of it if we could. I think we should clarify what we're required to keep in these files and also the requirement to not create new Python files.

• email Hackathon organizer to clarify requirements

Time control for searching

• make the bot take a set amount of time to search
• make the bot speed up when time gets lower (maybe think longer when eval is more equal or we are losing)