11-11-2016, 10:23 AM
(This post was last modified: 11-11-2016, 04:53 PM by Oedipussy Rex.)
Good news/bad news.
Good news: I got it to work. Kind of. I got an index out of range error when on an 11 die pool, meaning a chain came up with six successes where at most only five should be possible.
Bad news: That skewing downward of successes is bad. At only 5 dice, a shift of 5% is seen, i.e. should be a 50% chance for two successes but only 45% is calculated. Also, as predicted, this really sucks up the RAM. On my little laptop w/3gb it used up 95% as well as 50% swap, which I don't need to tell you, slows processing to a crawl. Well, the RAM suckage happens at ten- and eleven-die pools and at eight-die pools when it starts filling with 10- and 12-siders.
So, what can be done? First, dump the remainder method and go back to the recursive method of determining the number of successes. This will add processing time, so what can be cut to make up the difference? Something that comes to mind is the repetitive rebuilding of die rolls for each target number. How about building a die roll once then applying each target number to that?
Another issue is this RAM issue. One thought I have is: let's say we have a pool of [8,8,6,4,4]. Right now, we're storing [8], [8,8], [8,8,6], [8,8,6,4], and [8,8,6,4,4] in memory, which includes all the 8+64+384+1536+6144 different permutations of die rolls. Now, obviously, we need to keep the 6144; it's what being processed currently and it's what will be passed to [8,8,6,4,4,4]. But do we need the 1536? It's information has already been processed, passed on, and won't be passed on anymore. We definitely need the 384 because after all the 4s have been added the pool will go to [8,8,6,6] and that 384 will be passed on. But we won't need it after that. So if oldpool.pool[-1] == newdie we can oldpool.rolls.empty() in Pools. This isn't a panacea. In this example we've only freed 1544 "units" of the 8136, but when we're dealing with the swap partition, every little bit helps.
Good news: I got it to work. Kind of. I got an index out of range error when on an 11 die pool, meaning a chain came up with six successes where at most only five should be possible.
Bad news: That skewing downward of successes is bad. At only 5 dice, a shift of 5% is seen, i.e. should be a 50% chance for two successes but only 45% is calculated. Also, as predicted, this really sucks up the RAM. On my little laptop w/3gb it used up 95% as well as 50% swap, which I don't need to tell you, slows processing to a crawl. Well, the RAM suckage happens at ten- and eleven-die pools and at eight-die pools when it starts filling with 10- and 12-siders.
So, what can be done? First, dump the remainder method and go back to the recursive method of determining the number of successes. This will add processing time, so what can be cut to make up the difference? Something that comes to mind is the repetitive rebuilding of die rolls for each target number. How about building a die roll once then applying each target number to that?
Another issue is this RAM issue. One thought I have is: let's say we have a pool of [8,8,6,4,4]. Right now, we're storing [8], [8,8], [8,8,6], [8,8,6,4], and [8,8,6,4,4] in memory, which includes all the 8+64+384+1536+6144 different permutations of die rolls. Now, obviously, we need to keep the 6144; it's what being processed currently and it's what will be passed to [8,8,6,4,4,4]. But do we need the 1536? It's information has already been processed, passed on, and won't be passed on anymore. We definitely need the 384 because after all the 4s have been added the pool will go to [8,8,6,6] and that 384 will be passed on. But we won't need it after that. So if oldpool.pool[-1] == newdie we can oldpool.rolls.empty() in Pools. This isn't a panacea. In this example we've only freed 1544 "units" of the 8136, but when we're dealing with the swap partition, every little bit helps.
Getting me free admission into gaming conventions for a decade