Wed Apr 2 21:26:27 2014 by Jake |

I cant believe someone else mentioned displaying fractional results this weekend! After a long batch of using troll last week I had the same idea and even left myself blocks of time over the weekend to sketch out the solving algorithm and ideas and to put all of it into some hopefully intelligible english first thing monday morning. Well atleast now I have a lot less to type it seems. I often find myself reverse engineering the fractions from troll results since they are often times a lot simpler to visualize and manipulate (as well as given “true” accuracy instead of a truncated decimal) Given your reply I do still have one idea that falls short of true fractional-factorization, but would be a quick and dirty shortcut to getting fractional results that I dont think would be too painful to implement. If a user could grasp (either from his inputs or the results) a pattern and level of granularity to the numbers; then he has a factor to convert the decimals to integers or fractions. For example lets use your “sum largest 3 4d6” and its results. If the user understood that 4d6 was going to yield 6 ^{4} discrete outcomes OR that the only way to roll the lowest result of 3 was by rolling 4 1s, then they can use that fact to recover the integers/fractions by multiplying the results table by 1/(6^{4)} or .077%. This is what I usual start with although things do get abit trickier with multiple die types and less simple functions.However; if you were to add a 5th choice for your column 2 display (a “/” symbol to represent fractions) and add a small field in the space next to the Iteration bound labeled “denominator” or “factor” or the like, where a user picking the “/” option would enter what they believe the dividing factor to be [in this case 1/(6 ^{4)]} then column 2 simply displays column 1's results multiplied by this factor. (the same decimal precision would be kept since as a check)So “sum largest 3 4d6” with “/” selected and “1/(6 ^{4)} or .0007716” entered as a factor: would yield the same decriminalized column 1 results as always, but column 2 would show {1,4,10,21,38,62,...42,21} Given your level of skill and complexity of the code as it is already, I figured that would be a fairly simple addition that could be very greatly useful to a large section of your users. What do you think? |

Thu Apr 3 12:28:45 2014 by Torben |

It is not a bad idea. Already, I multiply the probabilities by 100 to change them from mathematical probabilities (ranging from 0 to 1) to percentages. Allowing the user to select a multiplier (such as 216) would not be very difficult. I'll look into over the next week or so. I have a deadline tomorrow, so I'll probably not have time this week. |

Thu Apr 3 15:26:23 2014 by Torben |

Due to a cancelled meeting, I actually got some time today to implement your suggestions. You can try it out now: Simply replace 100 by, e.g, 1296. |

Fri Apr 4 23:52:24 2014 by Jake |

Completely Awesome! that will add a lot of utility. I do have 3 minor suggestions: 1) You might want to keep column 1 the way it was (x100), and have the user's input change column 2. The reason I suggest this is the decimal percent values are still sometimes useful in conjunction with the fractional outputs; and I'm not exactly sure how the column 2's running totals times the user's chosen input is something as useful to display. Those two things are most definitely just my personal opinion so take them with that in mind. 2) I would suggest a larger input field. 6 digits is decent but those numbers can get big VERY fast. (I was recently working on one where the factor was 2 ^{31}3) The future possibility of allowing the user input field to handle some very simplistic calculations. All you would really need is multiplication and exponents, which would allow user's to enter "(6 ^{3} )*(2^{8} )*(7)" instead of what that actually multiplies out to be. I think it would make for a handy shorthand.Definitely a powerful/useful addition, I cant wait to mess with it about this weekend. Thanks again. |

Mon Apr 7 10:11:07 2014 by Torben |

Ad 1: I'll keep this as it is. Partly because it is easier, partly because it is sometimes useful to get fractions also for the non-cumulative count and partly because you can always run twice if you want both percentages and fractions. Ad 2: I have increased to 9 digits. With 10 or more digits, there can be overflow. Unfortunately, this rules out your 2 ^{31.}Ad 3: I did consider this, but it will have to wait until I have a bit more time. |