MAINT: Apply 'pre-commit run --all' and fix issues

00_Common/BASIC_Tests/InputTest.bas

@@ -2,4 +2,3 @@
 20 PRINT "You entered: ";A;B;C
 30 PRINT "--------------------------"
 40 GOTO 10
-

00_Common/BASIC_Tests/OutputTest.bas

@@ -1,4 +1,2 @@
 10 A=1: B=-2: C=0.7: D=123456789: E=-0.0000000001
 20 PRINT "|";A;"|";B;"|";C;"|";D;"|";E;"|"
-
-

00_Common/BASIC_Tests/RndTest.bas

@@ -2,5 +2,3 @@
 20 PRINT "2: ";RND(-2);RND(1);RND(1);RND(1)
 30 PRINT "3: ";RND(-5);RND(1);RND(1);RND(1)
 40 PRINT "4: ";RND(-2);RND(1);RND(1);RND(1)
-
-

00_Utilities/mardown_todo_rust/src/main.rs

@@ -243,4 +243,3 @@ fn _list_files(vec: &mut Vec<PathBuf>, path: &Path) {
         }
     }
 }
-

01_Acey_Ducey/lua/README.md

@@ -4,4 +4,3 @@ As published in Basic Computer Games (1978), as found at Annarchive:
 
 Conversion to Lua
 - [Lua.org](https://www.lua.org)
-

04_Awari/python/awari.py

@@ -6,85 +6,69 @@ An ancient African game (see also Kalah, Mancala).
 Ported by Dave LeCompte
 """
 
-"""
-
-PORTING NOTES
-
-This game started out as 70 lines of BASIC, and I have ported it
-before. I find it somewhat amazing how efficient (densely packed) the
-original code is. Of course, the original code has fairly cryptic
-variable names (as was forced by BASIC's limitation on long (2+
-character) variable names). I have done my best here to interpret what
-each variable is doing in context, and rename them appropriately.
-
-I have endeavored to leave the logic of the code in place, as it's
-interesting to see a 2-ply game tree evaluation written in BASIC,
-along with what a reader in 2021 would call "machine learning".
-
-As each game is played, the move history is stored as base-6
-digits stored losing_book[game_number]. If the human player wins or
-draws, the computer increments game_number, effectively "recording"
-that loss to be referred to later. As the computer evaluates moves, it
-checks the potential game state against these losing game records, and
-if the potential move matches with the losing game (up to the current
-number of moves), that move is evaluated at a two point penalty.  
-
-Compare this, for example with MENACE, a mechanical device for
-"learning" tic-tac-toe:
-https://en.wikipedia.org/wiki/Matchbox_Educable_Noughts_and_Crosses_Engine
-
-The base-6 representation allows game history to be VERY efficiently
-represented. I considered whether to rewrite this representation to be
-easier to read, but I elected to TRY to document it, instead.
-
-Another place where I have made a difficult decision between accuracy
-and correctness is inside the "wrapping" code where it considers
-"while human_move_end > 13". The original BASIC code reads:
-
-830 IF L>13 THEN L=L-14:R=1:GOTO 830
-
-I suspect that the intention is not to assign 1 to R, but to increment
-R. I discuss this more in a porting note comment next to the
-translated code. If you wish to play a more accurate version of the
-game as written in the book, you can convert the increment back to an
-assignment.
-
-
-I continue to be impressed with this jewel of a game; as soon as I had
-the AI playing against me, it was beating me. I've been able to score
-a few wins against the computer, but even at its 2-ply lookahead, it
-beats me nearly always. I would like to become better at this game to
-explore the effectiveness of the "losing book" machine learning.
-
-
-EXERCISES FOR THE READER
-One could go many directions with this game:
-
-- change the initial number of stones in each pit
-
-- change the number of pits
-
-- only allow capturing if you end on your side of the board
-
-- don't allow capturing at all
-
-- don't drop a stone into the enemy "home"
-
-- go clockwise, instead
-
-- allow the player to choose to go clockwise or counterclockwise
-
-- instead of a maximum of two moves, allow each move that ends on the
-  "home" to be followed by a free move.
-
-- increase the AI lookahead
-
-- make the scoring heuristic a little more nuanced
-
-- store history to a file on disk (or in the cloud!) to allow the AI
-  to learn over more than a single session
-
-"""
+# PORTING NOTES
+#
+# This game started out as 70 lines of BASIC, and I have ported it
+# before. I find it somewhat amazing how efficient (densely packed) the
+# original code is. Of course, the original code has fairly cryptic
+# variable names (as was forced by BASIC's limitation on long (2+
+# character) variable names). I have done my best here to interpret what
+# each variable is doing in context, and rename them appropriately.
+#
+# I have endeavored to leave the logic of the code in place, as it's
+# interesting to see a 2-ply game tree evaluation written in BASIC,
+# along with what a reader in 2021 would call "machine learning".
+#
+# As each game is played, the move history is stored as base-6
+# digits stored losing_book[game_number]. If the human player wins or
+# draws, the computer increments game_number, effectively "recording"
+# that loss to be referred to later. As the computer evaluates moves, it
+# checks the potential game state against these losing game records, and
+# if the potential move matches with the losing game (up to the current
+# number of moves), that move is evaluated at a two point penalty.
+#
+# Compare this, for example with MENACE, a mechanical device for
+# "learning" tic-tac-toe:
+# https://en.wikipedia.org/wiki/Matchbox_Educable_Noughts_and_Crosses_Engine
+#
+# The base-6 representation allows game history to be VERY efficiently
+# represented. I considered whether to rewrite this representation to be
+# easier to read, but I elected to TRY to document it, instead.
+#
+# Another place where I have made a difficult decision between accuracy
+# and correctness is inside the "wrapping" code where it considers
+# "while human_move_end > 13". The original BASIC code reads:
+#
+# 830 IF L>13 THEN L=L-14:R=1:GOTO 830
+#
+# I suspect that the intention is not to assign 1 to R, but to increment
+# R. I discuss this more in a porting note comment next to the
+# translated code. If you wish to play a more accurate version of the
+# game as written in the book, you can convert the increment back to an
+# assignment.
+#
+# I continue to be impressed with this jewel of a game; as soon as I had
+# the AI playing against me, it was beating me. I've been able to score
+# a few wins against the computer, but even at its 2-ply lookahead, it
+# beats me nearly always. I would like to become better at this game to
+# explore the effectiveness of the "losing book" machine learning.
+#
+#
+# EXERCISES FOR THE READER
+# One could go many directions with this game:
+# - change the initial number of stones in each pit
+# - change the number of pits
+# - only allow capturing if you end on your side of the board
+# - don't allow capturing at all
+# - don't drop a stone into the enemy "home"
+# - go clockwise, instead
+# - allow the player to choose to go clockwise or counterclockwise
+# - instead of a maximum of two moves, allow each move that ends on the
+#   "home" to be followed by a free move.
+# - increase the AI lookahead
+# - make the scoring heuristic a little more nuanced
+# - store history to a file on disk (or in the cloud!) to allow the AI
+#   to learn over more than a single session
 
 
 game_number = 0

38_Fur_Trader/c/furtrader.c

@@ -472,4 +472,3 @@ int main( void )
 
     return 0; /* exit OK */
 }
-

46_Hexapawn/python/hexapawn.py

@@ -14,37 +14,35 @@ Conversion to MITS BASIC by Steve North
 Port to Python by Dave LeCompte
 """
 
-"""
-PORTING NOTES:
-
-I printed out the BASIC code and hand-annotated what each little block
-of code did, which feels amazingly retro.
-
-I encourage other porters that have a complex knot of GOTOs and
-semi-nested subroutines to do hard-copy hacking, it might be a
-different perspective that helps.
-
-A spoiler - the objective of the game is not documented, ostensibly to
-give the human player a challenge. If a player (human or computer)
-advances a pawn across the board to the far row, that player wins. If
-a player has no legal moves (either by being blocked, or all their
-pieces having been captured), that player loses.
-
-The original BASIC had 2 2-dimensional tables stored in DATA at the
-end of the program. This encoded all 19 different board configurations
-(Hexapawn is a small game), with reflections in one table, and then in
-a parallel table, for each of the 19 rows, a list of legal moves was
-encoded by turning them into 2-digit decimal numbers. As gameplay
-continued, the AI would overwrite losing moves with 0 in the second
-array.
-
-My port takes this "parallel array" structure and turns that
-information into a small Python class, BoardLayout. BoardLayout stores
-the board description and legal moves, but stores the moves as (row,
-column) 2-tuples, which is easier to read. The logic for checking if a
-BoardLayout matches the current board, as well as removing losing move
-have been moved into methods of this class.
-"""
+# PORTING NOTES:
+#
+# I printed out the BASIC code and hand-annotated what each little block
+# of code did, which feels amazingly retro.
+#
+# I encourage other porters that have a complex knot of GOTOs and
+# semi-nested subroutines to do hard-copy hacking, it might be a
+# different perspective that helps.
+#
+# A spoiler - the objective of the game is not documented, ostensibly to
+# give the human player a challenge. If a player (human or computer)
+# advances a pawn across the board to the far row, that player wins. If
+# a player has no legal moves (either by being blocked, or all their
+# pieces having been captured), that player loses.
+#
+# The original BASIC had 2 2-dimensional tables stored in DATA at the
+# end of the program. This encoded all 19 different board configurations
+# (Hexapawn is a small game), with reflections in one table, and then in
+# a parallel table, for each of the 19 rows, a list of legal moves was
+# encoded by turning them into 2-digit decimal numbers. As gameplay
+# continued, the AI would overwrite losing moves with 0 in the second
+# array.
+#
+# My port takes this "parallel array" structure and turns that
+# information into a small Python class, BoardLayout. BoardLayout stores
+# the board description and legal moves, but stores the moves as (row,
+# column) 2-tuples, which is easier to read. The logic for checking if a
+# BoardLayout matches the current board, as well as removing losing move
+# have been moved into methods of this class.
 
 import collections
 import random
@@ -238,7 +236,7 @@ def get_coordinates():
         try:
             print("YOUR MOVE?")
             response = input()
-            m1, m2 = [int(c) for c in response.split(",")]
+            m1, m2 = (int(c) for c in response.split(","))
             return m1, m2
         except ValueError as ve:
             print_illegal()

64_Nicomachus/python/nicomachus.py

@@ -6,13 +6,11 @@ Math exercise/demonstration
 Ported by Dave LeCompte
 """
 
-"""
-PORTING NOTE
-
-The title, as printed ingame, is "NICOMA", hinting at a time when
-filesystems weren't even 8.3, but could only support 6 character
-filenames.
-"""
+# PORTING NOTE
+#
+# The title, as printed ingame, is "NICOMA", hinting at a time when
+# filesystems weren't even 8.3, but could only support 6 character
+# filenames.
 
 import time
 

66_Number/rust/src/main.rs

@@ -60,4 +60,3 @@ fn welcome() {
 
     ");
 }
-

70_Poetry/python/poetry.py

@@ -6,14 +6,12 @@ A poetry generator
 Ported by Dave LeCompte
 """
 
-"""
-PORTING EDITORIAL NOTE:
-
-The original code is a pretty convoluted mesh of GOTOs and global
-state. This adaptation pulls things apart into phrases, but I have
-left the variables as globals, which makes goes against decades of
-wisdom that global state is bad.
-"""
+# PORTING EDITORIAL NOTE:
+#
+# The original code is a pretty convoluted mesh of GOTOs and global
+# state. This adaptation pulls things apart into phrases, but I have
+# left the variables as globals, which makes goes against decades of
+# wisdom that global state is bad.
 
 PAGE_WIDTH = 64