Two entries from my project journal
22 :: Sunday September 2, 2018
I need to jot this down before I forget.
I only just yesterday got the fat ports to work. I’d been calling inner write on the baby figures before they were added to the realm. That meant there were no trackers connected to the baby figures when their safe random method got called. All that time, I was just running the system more or less like the fat ports weren’t even there. Once I fix that, it ran like a dream.
I spent today seeing how stable they were passed the 1mil cutoff. I’ve also got a few populations generated by what I thought were bullshit, just for the hell of it experiments.
I cleaned up the handler methods figure next turn and after figure next turn. They are called inside of realm cycle now, just before and after a figure’s next turn method is called.
I ran the populations to see if the results were still the same. Turns out they weren’t, but it also turns out they aren’t always consistent anyway. The system’s one thread is stopped by another, so results may vary. However, those numbers one would expect to be consistent are from one run to the next.
I’ll stick the old versions as class name dot txt files in a folder called “good.” I was using that to keep the cleaned up code before changing it for another experiment.
We have three fat ports, each taking up 18 slots for a total of 54. Add in the 55 slim ports, and we have a port count of 109.
For the hell of it, I ran find empty by itself. Nothing came of it. Then I ran find empty with inner head along and outer head alone. Only the tracker wasn’t attached soon enough so I wasn’t actually running those experiments. I still got a stable population off the server. I saved it and it’s now named notInner0.pop.
When things were fixed I ran it again. Find empty by itself did nothing. Fined empty with just outer head gave me two stable populations, taking an hour and a half for the one that took the longest to stabilize. Find empty with just inner head did even better. I got two stable populations out of that one, they stabilized quicker, and they were running on the server—a slower machine than mine.
inner0.pop, not stable with all three fat ports open.
inner1.pop stable up to 10mil
outer0.pop and outer1.pop only got tested up to 1mil.
Running all three fat ports gave me populations that stabilized in much less time, anywhere from 5 to somewhere between 15 and 20 minutes.
all0.pop unstable passed 1mil only makes 300K or so more
all1.pop stable up to 10mil, and fast, faster than m1.pop, done in about fifteen seconds.
all2.pop unstable reaches about 800mil
all3.pop stable to 10mil, and slow, eight minutes and fifteen seconds to reach 1mil
It’s a kinder gentler realm, let’s see if that translates into a kinder gentler mutation.
23 :: /Tuesday September 4, 2018
Mutation is still far too devastating. With the fat ports, I saw 4 mutations kill off all twenty figures.
I implemented skipcom last night. I just tested the population that got generated by it, skipcom0.pop. It takes 16 minutes to make a million or so baby figures. It first reached a million and stopped at around 18 minutes. As it takes 16 minutes to make a million, we can infer that it took less than three minutes for the first population to reach that level of stability.
I ran it again for close to an hour with no luck. But, it really doesn’t matter. As it happens, the way I implemented skipcom was wrong.
It was nice on the porch with my brother, having a smoke and feeling hopeful about the first oh so promising result. I’m not sure what to do with the population that got generated. Guess I’ll squirrel it away.
With the original approach, when a figure had a bad command, it would reset. This means that if the first command is bad, it doesn’t matter what the rest of your code is like. With skipcom, short for skip command, instead of resetting and putting the pointer back to 0, the pointer is moved to the next command, pointer=pointer+3.
At the moment, any command that has c set to a range outside of the figure’s ports and addresses is treated as bad. That’s not what we want to have happen. If a or b are out of range, sure skip it, but if a and b are good, run them through the entire rigmarole. Then, if c is a bad address, we’ll handle it.
When c points to a bad address, instead of pointer=c, pointer=pointer+3;
That, my friends and neighbors , is an unconditional branch.
The unconditional branch, when the command is executed and the result is ignored, so that no matter the result, the program just goes to the same place, is actually unlikely to happen by random chance. For example, the first command, to go to the next command no matter what, must have the number at index 2 be equal to 3. No other number will do it. If you want an unconditional branch for the second command, then the number at index 5 must be 6. It takes a specific number in a specific place. With random numbers, even constrained to a certain range, well… the phrase “extremely low probability” hardly covers it. With skipcom implemented correctly, unconditional branches become very likely, and conditional branches should also still occur all the time.
Give me a minute to fix it.
Took about an hour and a half, but I got a population that is stable up to ten million. It finished that run in 15 minutes and 49 seconds, making it roughly ten times faster than skipcom0.pop. I saved it as skipcom1.pop. Good enough for the day.