User:D414/Diary of a Robocoder - Revision history

D414: Some ramblings about neural networks

2025-08-19T22:24:42Z

Some ramblings about neural networks

D414 at 13:15, 16 August 2025

2025-08-16T13:15:02Z

D414 at 12:33, 16 August 2025

2025-08-16T12:33:05Z

D414 at 12:25, 16 August 2025

2025-08-16T12:25:14Z

D414: Some progress in shrinking enemy tracking code

2025-08-16T12:24:33Z

Some progress in shrinking enemy tracking code

D414: First diary entry in over a year.

2025-08-08T21:34:34Z

First diary entry in over a year.

D414: Brief update after some disappointing results

2024-06-07T18:10:26Z

Brief update after some disappointing results

D414: Quantum now outranks HawkOnFire!

2024-05-14T07:39:12Z

Quantum now outranks HawkOnFire!

D414: More code shrinking and gun tweaks

2024-05-13T18:41:22Z

More code shrinking and gun tweaks

D414: Quantum got even smaller

2024-05-10T09:51:59Z

Quantum got even smaller

← Older revision		Revision as of 22:24, 19 August 2025
Line 1:		Line 1:
		+	; 19th August 2025
		+	For the past few days I've been trying to squeeze a neural network capable of "learning" into a nanobot, and I seem to have succeeded with [[Neutrino]]. I say "learning" because actually training mid-battle like [[Gaff]] is utterly infeasible in a nanobot. Instead I've been looking at echo state networks (See [https://www.ai.rug.nl/minds/uploads/PracticalESN.pdf A Practical Guide to Applying Echo State Networks]) as a way of maintaining state on multiple time scales.
		+
		+	In the process of shrinking down the inference code to a measly ~90 bytes I ended up accidentally designing something significantly more powerful that supports the following:
		+	* [https://en.wikipedia.org/wiki/Multilayer_perceptron Multi layer perceptrons] (MLP)
		+	* Echo state networks (ESN)
		+	* Special cases and/or approximations of a handful of other types of neural network
		+	* Any of the above connected in arbitrary ways (eg MLPs feeding multiple ESNs tuned to different timescales that then feed into another MLP)
		+	* Doesn't require the network to be organised in layers - it can handle an arbitrary [https://en.wikipedia.org/wiki/Directed_acyclic_graph DAG]
		+	* Handles sparsely connected networks efficiently
		+	* Can save state from one round to the next, and supports training a completely separate network that is only run once per round
		+
		+	These capabilities only emerged after I finally managed to flatten the typical nested loops needed for matrix multiplication down to this:
		+
		+	<syntaxhighlight lang="java">
		+	static void doNN(double[] inout, int i) {
		+	try {
		+	while (true) {
		+	double leak;
		+	inout[OUT_ORDER.charAt(i)] = ((1 - (leak = decode(LEAK, i))) * inout[IN_ORDER_1.charAt(i)])
		+	+ (leak * Math.tanh((inout[ACCUMULATOR_INDEX] += decode(WEIGHTS, i) * inout[IN_ORDER_2.charAt(i)]) + decode(BIASES, i++)));
		+	}
		+	} catch (ArrayIndexOutOfBoundsException e) {
		+	}
		+	}
		+	</syntaxhighlight>
		+
		+	I've still got an enormous amount of work to go before I can turn [[Neutrino]] into a fully functioning bot, let alone a competitive one.
		+
	; 16th August 2025		; 16th August 2025
	I've been doing some exploratory work for an entirely different approach for [[Quantum]] worthy of being called version 2. Something I'm trying to add is storing data about my enemies.		I've been doing some exploratory work for an entirely different approach for [[Quantum]] worthy of being called version 2. Something I'm trying to add is storing data about my enemies.

@@ Line 2: / Line 2: @@
 I've been doing some exploratory work for an entirely different approach for [[Quantum]] worthy of being called version 2. Something I'm trying to add is storing data about my enemies.
-The typical way of tracking data about enemies would be to use a Map, an example of which can be seen in [[HawkOnFire]] but this uses up far too much space to put into a nanobot. [[User:Kev]] uses an imaginative approach in [[Mirage]] that stores the data in arrays instead and uses a static function to give each enemy a unique integer id to index into those arrays. I shaved 11 bytes off of [[Mirage]]'s approach in [[FireHammer]] (my attempt to fit [[Mirage]]'s gun into a micro) and then [[User:Kev]] found a way to shave a whopping 26 bytes(!) off of that in [[Figment]].
+The typical way of tracking data about enemies would be to use a Map, an example of which can be seen in [[HawkOnFire]] but this uses up far too much space to put into a nanobot. [[User:Kev|Kev]] uses an imaginative approach in [[Mirage]] that stores the data in arrays instead and uses a static function to give each enemy a unique integer id to index into those arrays. I shaved 11 bytes off of [[Mirage]]'s approach in [[FireHammer]] (my attempt to fit [[Mirage]]'s gun into a micro) and then [[User:Kev|Kev]] found a way to shave a whopping 26 bytes(!) off of that in [[Figment]].
 Unfortunately the [[Figment]] method has some drawbacks that could make it unsuitable for how I'm hoping to use enemy data in [[Quantum]] v2 but I have been able to shave another 5 bytes off of [[FireHammer]]'s code.

@@ Line 55: / Line 55: @@
 // Stable IDs: Can be unstable at the start of the first round until each enemy has been scanned for the first time.
 // Contiguous IDs: Yes, from 0-9 in a 10 bot melee match
 // Memory usage: Extremely low. Almost zero overhead and no wasted space in the data arrays.
 static TreeSet<String> index = new TreeSet<String>();

@@ Line 12: / Line 12: @@
 // Contiguous IDs: Yes, from 1-10 in a 10 bot melee match
 // Clashing IDs: Theoretically possible, but unlikely (uses 18bits of the 32bit .hashcode())
-// Memory usage: Low, constant 1mb overhead for IDs. 1-based indexing wastes one enemy's worth of space in the data arrays.
+// Memory usage: Low. Constant 1mb overhead for IDs. 1-based indexing wastes one enemy's worth of space in the data arrays.
 static final int OPPONENT_HASHES = 262144; // 18 bits
 static int[] opponentIDs = new int[OPPONENT_HASHES];

← Older revision		Revision as of 12:24, 16 August 2025
Line 1:		Line 1:
		+	; 16th August 2025
		+	I've been doing some exploratory work for an entirely different approach for [[Quantum]] worthy of being called version 2. Something I'm trying to add is storing data about my enemies.
		+
		+	The typical way of tracking data about enemies would be to use a Map, an example of which can be seen in [[HawkOnFire]] but this uses up far too much space to put into a nanobot. [[User:Kev]] uses an imaginative approach in [[Mirage]] that stores the data in arrays instead and uses a static function to give each enemy a unique integer id to index into those arrays. I shaved 11 bytes off of [[Mirage]]'s approach in [[FireHammer]] (my attempt to fit [[Mirage]]'s gun into a micro) and then [[User:Kev]] found a way to shave a whopping 26 bytes(!) off of that in [[Figment]].
		+
		+	Unfortunately the [[Figment]] method has some drawbacks that could make it unsuitable for how I'm hoping to use enemy data in [[Quantum]] v2 but I have been able to shave another 5 bytes off of [[FireHammer]]'s code.
		+
		+	<syntaxhighlight lang="java">
		+	// Mirage
		+	// Size: 46 bytes
		+	// Stable IDs: Yes
		+	// Contiguous IDs: Yes, from 1-10 in a 10 bot melee match
		+	// Clashing IDs: Theoretically possible, but unlikely (uses 18bits of the 32bit .hashcode())
		+	// Memory usage: Low, constant 1mb overhead for IDs. 1-based indexing wastes one enemy's worth of space in the data arrays.
		+	static final int OPPONENT_HASHES = 262144; // 18 bits
		+	static int[] opponentIDs = new int[OPPONENT_HASHES];
		+	static int opponentsSeen;
		+
		+	static int getOpponentID(String name) {
		+	int code = name.hashCode() & (OPPONENT_HASHES - 1);
		+	int id = opponentIDs[code];
		+	return opponentIDs[code] = (id == 0 ? ++opponentsSeen : id);
		+	}
		+
		+	// FireHammer
		+	// Size: 35 bytes
		+	// Stable IDs: Yes
		+	// Contiguous IDs: Yes, from 0-9 in a 10 bot melee match
		+	// Clashing IDs: No
		+	// Memory usage: Extremely low. Almost zero overhead and no wasted space in the data arrays.
		+	static ArrayList<String> opponentIDs = new ArrayList<>();
		+
		+	static int getOpponentID(String name) {
		+	ArrayList<String> list;
		+	if (!(list = opponentIDs).contains(name)) {
		+	list.add(name);
		+	}
		+	return list.indexOf(name);
		+	}
		+
		+	// Figment
		+	// Size: 9 bytes
		+	// Stable IDs: Yes
		+	// Contiguous IDs: No, could be anything from 0 - 255
		+	// Clashing IDs: Theoretically possible, more likely than Mirage
		+	// Memory usage: Potentially high, increases data size by 246x
		+	static final int OPPONENT_HASHES = 256; // 8 bits
		+
		+	static int getOpponentID(String name) {
		+	return name.hashCode() & (OPPONENT_HASHES - 1);
		+	}
		+
		+	// Quantum v2
		+	// Size: 30 bytes
		+	// Stable IDs: Can be unstable at the start of the first round until each enemy has been scanned for the first time.
		+	// Contiguous IDs: Yes, from 0-9 in a 10 bot melee match
		+	// Memory usage: Extremely low. Almost zero overhead and no wasted space in the data arrays.
		+	static TreeSet<String> index = new TreeSet<String>();
		+
		+	static int getOpponentID(String name) {
		+	index.add(name);
		+	return Arrays.binarySearch(index.toArray(), name);
		+	}
		+	</syntaxhighlight>
		+
	; 8th August 2025		; 8th August 2025
	It's been over a year since my last update! I got disheartened by the inadequacies of my testing framework and the fact that the melee [[RoboRumble]]s for [[Code Size]] restricted bots include results for battles involving bots from outside of the weight class - I think we'd see some interesting changes to the leaderboards and which strategies are and aren't successful.		It's been over a year since my last update! I got disheartened by the inadequacies of my testing framework and the fact that the melee [[RoboRumble]]s for [[Code Size]] restricted bots include results for battles involving bots from outside of the weight class - I think we'd see some interesting changes to the leaderboards and which strategies are and aren't successful.

← Older revision		Revision as of 21:34, 8 August 2025
Line 1:		Line 1:
		+	; 8th August 2025
		+	It's been over a year since my last update! I got disheartened by the inadequacies of my testing framework and the fact that the melee [[RoboRumble]]s for [[Code Size]] restricted bots include results for battles involving bots from outside of the weight class - I think we'd see some interesting changes to the leaderboards and which strategies are and aren't successful.
		+
		+	Since the itch to robocode returned I think I've found ways to squeeze a few more bytes out of [[Quantum]], perhaps as many as 4-8. Sadly without a robust testing strategy it seems infeasible to find anything to actually do with those bytes besides adding colours back.
		+
		+	I've also spent some time watching [[IWillFireNoBullet]] move and have to say it's a thing of beauty. I highly recommend it to anybody with even a passing interest in [[Melee]] battles.
		+
	; 7th June 2024		; 7th June 2024
	My last couple of updates to [[Quantum]] have hammered home the point that my test benches don't reflect rumble performance nearly as well as I'd like - v1.2.1 and v1.2.2 performed similarly in my testing but quite differently to each other in the rumble. They both outperformed v1.0.0 by around 1% APS in testing but failed to live up to that when released. I don't think I can get away with putting off building a good testing framework any longer!		My last couple of updates to [[Quantum]] have hammered home the point that my test benches don't reflect rumble performance nearly as well as I'd like - v1.2.1 and v1.2.2 performed similarly in my testing but quite differently to each other in the rumble. They both outperformed v1.0.0 by around 1% APS in testing but failed to live up to that when released. I don't think I can get away with putting off building a good testing framework any longer!

← Older revision		Revision as of 18:10, 7 June 2024
Line 1:		Line 1:
		+	; 7th June 2024
		+	My last couple of updates to [[Quantum]] have hammered home the point that my test benches don't reflect rumble performance nearly as well as I'd like - v1.2.1 and v1.2.2 performed similarly in my testing but quite differently to each other in the rumble. They both outperformed v1.0.0 by around 1% APS in testing but failed to live up to that when released. I don't think I can get away with putting off building a good testing framework any longer!
		+
		+	It's not a complete loss though. I've learned a lot, found a few more bytes to play with and I'm still confident that the approach to bullet power selection will yield better performance (eventually).
		+
	; 14th May 2024		; 14th May 2024
	Well, that was unexpected! The minor update to [[Quantum]] that I released reduced the codesize enough to allow me to fix the radar bug I added in v0.2.2 to make room for colours (Each time an opponent died there was a 50% chance the radar would switch directions). That bugfix was worth around 0.7 APS in the micro melee rumble, which was enough to push [[Quantum]] above [[HawkOnFire]]! I'm ''very'' excited to tune the gun...		Well, that was unexpected! The minor update to [[Quantum]] that I released reduced the codesize enough to allow me to fix the radar bug I added in v0.2.2 to make room for colours (Each time an opponent died there was a 50% chance the radar would switch directions). That bugfix was worth around 0.7 APS in the micro melee rumble, which was enough to push [[Quantum]] above [[HawkOnFire]]! I'm ''very'' excited to tune the gun...

← Older revision		Revision as of 07:39, 14 May 2024
Line 1:		Line 1:
		+	; 14th May 2024
		+	Well, that was unexpected! The minor update to [[Quantum]] that I released reduced the codesize enough to allow me to fix the radar bug I added in v0.2.2 to make room for colours (Each time an opponent died there was a 50% chance the radar would switch directions). That bugfix was worth around 0.7 APS in the micro melee rumble, which was enough to push [[Quantum]] above [[HawkOnFire]]! I'm ''very'' excited to tune the gun...
		+
	; 13th May 2024		; 13th May 2024
	ProGuard didn’t manage to shrink [[Quantum]] at all and installing Jikes is a bit of a faff these days (on an Arm MacBook anyway) so I decided to try out [https://github.com/Storyyeller/Krakatau Krakatau] to work with the assembly code directly. It looks like I can make room for the gun to use quite a few attributes - distance, bullet power, number of opponents, lateral velocity and lateral acceleration should all fit. I definitely need to improve on the spaghetti shaped shell scripts I’m using to build and test my bots if I’m going to successfully tune the gun, but I reckon it’ll be worth it. Whether or not it’s enough to outperform [[HawkOnFire]] with a nano remains to be seen, but I’m hopeful.		ProGuard didn’t manage to shrink [[Quantum]] at all and installing Jikes is a bit of a faff these days (on an Arm MacBook anyway) so I decided to try out [https://github.com/Storyyeller/Krakatau Krakatau] to work with the assembly code directly. It looks like I can make room for the gun to use quite a few attributes - distance, bullet power, number of opponents, lateral velocity and lateral acceleration should all fit. I definitely need to improve on the spaghetti shaped shell scripts I’m using to build and test my bots if I’m going to successfully tune the gun, but I reckon it’ll be worth it. Whether or not it’s enough to outperform [[HawkOnFire]] with a nano remains to be seen, but I’m hopeful.

← Older revision		Revision as of 18:41, 13 May 2024
Line 1:		Line 1:
		+	; 13th May 2024
		+	ProGuard didn’t manage to shrink [[Quantum]] at all and installing Jikes is a bit of a faff these days (on an Arm MacBook anyway) so I decided to try out [https://github.com/Storyyeller/Krakatau Krakatau] to work with the assembly code directly. It looks like I can make room for the gun to use quite a few attributes - distance, bullet power, number of opponents, lateral velocity and lateral acceleration should all fit. I definitely need to improve on the spaghetti shaped shell scripts I’m using to build and test my bots if I’m going to successfully tune the gun, but I reckon it’ll be worth it. Whether or not it’s enough to outperform [[HawkOnFire]] with a nano remains to be seen, but I’m hopeful.
		+
	; 10th May 2024		; 10th May 2024
	[[User:Sheldor2\|Sheldor]]'s adaptation of [[Quantum]] (NaturalScience) motivated me to put development of a micro bot on hold. I had space for table based bullet power selection, albeit much simpler than [[User:Sheldor2\|Sheldor]]'s, but only found marginal gains and tuning it by hand was both tedious and slow. I did manage to squeeze another 3 bytes out of my code though, bringing [[Quantum]] down to 239 bytes (without colours). There is room now for several different table based approaches but I'm going to need an automated way of tuning them. This leaves me with a nice todo list that will also benefit the development of other bots:		[[User:Sheldor2\|Sheldor]]'s adaptation of [[Quantum]] (NaturalScience) motivated me to put development of a micro bot on hold. I had space for table based bullet power selection, albeit much simpler than [[User:Sheldor2\|Sheldor]]'s, but only found marginal gains and tuning it by hand was both tedious and slow. I did manage to squeeze another 3 bytes out of my code though, bringing [[Quantum]] down to 239 bytes (without colours). There is room now for several different table based approaches but I'm going to need an automated way of tuning them. This leaves me with a nice todo list that will also benefit the development of other bots:

@@ Line 1: / Line 1: @@
 ; 4th May 2024
 I managed to find another half-dozen or so bytes in [[FireHammer]] which was enough to improve the movement a bit. I've entered it into the rumble and will run some battles overnight so we'll see where it ranks when I wake up in the morning.
@@ Line 5: / Line 12: @@
 ; 2nd May 2024
-I've finally given [[FireHammer]] a better (but not good) movement without going over 749 bytes. Once I've tidied the code up it will be ready to enter the rumble! I'm torn on whether to release it now versus waiting until I have a minibot ready to challenge [[Mirage]], I don't like to think about how much stronger [[Kev]] could make [[Mirage]] with all the extra space to play with!
+I've finally given [[FireHammer]] a better (but not good) movement without going over 749 bytes. Once I've tidied the code up it will be ready to enter the rumble! I'm torn on whether to release it now versus waiting until I have a minibot ready to challenge [[Mirage]], I don't like to think about how much stronger [[User:Kev|Kev]] could make [[Mirage]] with all the extra space to play with!
 ; 26th April 2024