replaymanager.py is only 339 lines long but it feels at least three times that when I'm working on it. The module is definitely due for a refactor. For one, the term subdataset should be renamed to version_set and extracted into a class. version_set more accurately and describes what it is, and the class extraction would clean up the namespace in ReplayManager. There is probably some kind of class extraction possible for replays, so that their names, paths, file streams, and Twitter profiles can all be neatly encapsulated, thereby cleaning up the namespace even more. However, I do not want to worry about having two kinds of replays: the one used by ReplayManager and the one used by ReplayParser. Even though ReplayManager does not use ReplayParser, the prospect of making things more muddier deters me.
There's probably a right way to refactor this code, but, to put it simply, now is not the time. Speaking of time, I came up with a great way to get work done, even when I am sleeping!
One cannot sleep and work
I need sleep
Computer does not need sleep
∴ Computer does all the work while I sleep?
It's been a while since I had to deal with logical arguments, so that may not be entirely sound. Or valid? Anyway, I set the collector agent loose on Rivals of Aether version 1.0.2. Over the course of about a day and a half, where most of that time was during the night, the agent amassed 41.6 GB of frame buffer data. That's at 1/4 scale, too! At full scale that works out to be around 166.4 GB!! That's like two copies of Nioh!!!
That 41.6 GB of 1/4 scale frame buffer data represents 331 replays. We need to know if all of that data is actually usable; otherwise, we'll waste a lot of time training a model on improperly indexed or incomplete data. To address this, I wrote methods in ReplayManager designed to produce a variety of sets. The first variety is the random sample set; it uses NumPy's random choice function to randomly select a given number of replays. These replays are copied into a separate location for later review. The second variety is the one we'll need later; it takes the entire dataset and uses the same random choice function to randomly distribute the dataset into a training and a testing subset, according to a preconfigured distribution. The current distribution is 80% training and 20% testing. This function works, but I haven't run it with the actual copying enabled because it will, literally and by definition, double the storage requirements of the dataset. These methods copy rather than move because the data has reached a stage of processing at which it is expensive to reproduce. I will need to establish more backups before I risk moving data destructively.
Our next step is to review the random samples. Once those are validated (manually, using the demo code), we can finish collecting for version 1.0.2. Then we'll sort the dataset into training and testing sets, finish the replay loader, and start running our LSTM. Then sleep while the LSTM does its thing.
There's probably a right way to refactor this code, but, to put it simply, now is not the time. Speaking of time, I came up with a great way to get work done, even when I am sleeping!
One cannot sleep and work
I need sleep
Computer does not need sleep
∴ Computer does all the work while I sleep?
It's been a while since I had to deal with logical arguments, so that may not be entirely sound. Or valid? Anyway, I set the collector agent loose on Rivals of Aether version 1.0.2. Over the course of about a day and a half, where most of that time was during the night, the agent amassed 41.6 GB of frame buffer data. That's at 1/4 scale, too! At full scale that works out to be around 166.4 GB!! That's like two copies of Nioh!!!
That 41.6 GB of 1/4 scale frame buffer data represents 331 replays. We need to know if all of that data is actually usable; otherwise, we'll waste a lot of time training a model on improperly indexed or incomplete data. To address this, I wrote methods in ReplayManager designed to produce a variety of sets. The first variety is the random sample set; it uses NumPy's random choice function to randomly select a given number of replays. These replays are copied into a separate location for later review. The second variety is the one we'll need later; it takes the entire dataset and uses the same random choice function to randomly distribute the dataset into a training and a testing subset, according to a preconfigured distribution. The current distribution is 80% training and 20% testing. This function works, but I haven't run it with the actual copying enabled because it will, literally and by definition, double the storage requirements of the dataset. These methods copy rather than move because the data has reached a stage of processing at which it is expensive to reproduce. I will need to establish more backups before I risk moving data destructively.
Our next step is to review the random samples. Once those are validated (manually, using the demo code), we can finish collecting for version 1.0.2. Then we'll sort the dataset into training and testing sets, finish the replay loader, and start running our LSTM. Then sleep while the LSTM does its thing.
Comments
Post a Comment