11-14-2016, 03:37 PM
What did I get right? Glad I pretended that someone asked. Speed combined with low memory usage. Well, depending on your definitions. The script runs in terms of hours, but that's better than the days it would take for my first efforts, and the RAM usage was ~750 mb with a pool of 11 10-siders, but that's better than bleeding into the swap partition that was going on. I've had open browsers sucking up more RAM.
Improved speed was established by using the iterative method of building a pool, then applying all target numbers to it, so it's built only once, and only running calculations for the target numbers that are applicable: if a pool has a d6 or larger, there's no need to process TN = 5.
Another change improved both the processing time and the memory usage. Let's say we have {2d4,3d6} as a pool. One result of a roll would be [2,3,4,1,4], another [3,4,1,5,2], and a third as [4,2,3,4,1]. Each roll each die had a different result, but when we look at just the results and not which die rolled it, they are all equivalent to [1,2,3,4,4] (or [1,0,1,1,2,0,0,0,0,0,0,0,0] when stored as the number of dice that rolled a particular number). Why keep each different roll result in memory for a particular pool when I can store it once then keep track of how many times it occurs, cutting down on memory. This also cuts down on time; [1,0,1,1,2,0,0,0,0,0,0,0,0] has only one success for TN 7, times the number of equivalent rolls.
I also cut down memory usage by getting rid of a list variable that had been hanging around since the first attempts at this using list comprehensions.
I can think of a couple things that could improve the process in minor ways, but why? It works (the first criteria on the quality of a program), it does so reasonably well, and it's a single purpose program that took me too long to get right enough.
Oh god, I hope I got it right this time.
Improved speed was established by using the iterative method of building a pool, then applying all target numbers to it, so it's built only once, and only running calculations for the target numbers that are applicable: if a pool has a d6 or larger, there's no need to process TN = 5.
Another change improved both the processing time and the memory usage. Let's say we have {2d4,3d6} as a pool. One result of a roll would be [2,3,4,1,4], another [3,4,1,5,2], and a third as [4,2,3,4,1]. Each roll each die had a different result, but when we look at just the results and not which die rolled it, they are all equivalent to [1,2,3,4,4] (or [1,0,1,1,2,0,0,0,0,0,0,0,0] when stored as the number of dice that rolled a particular number). Why keep each different roll result in memory for a particular pool when I can store it once then keep track of how many times it occurs, cutting down on memory. This also cuts down on time; [1,0,1,1,2,0,0,0,0,0,0,0,0] has only one success for TN 7, times the number of equivalent rolls.
I also cut down memory usage by getting rid of a list variable that had been hanging around since the first attempts at this using list comprehensions.
I can think of a couple things that could improve the process in minor ways, but why? It works (the first criteria on the quality of a program), it does so reasonably well, and it's a single purpose program that took me too long to get right enough.
Oh god, I hope I got it right this time.
Getting me free admission into gaming conventions for a decade