| Fri Jan 8 02:45:59 2016 by Me |
| First let me congratulate you on an extremely efficient and powerful (not to mention cool) tool you have created and give us access to. And for the continual improvements and upgrades you have been doing recently, great stuff! thank you. When ever I use the data that your site generates I tend to reverse engineer fractions out of the decimalized results. I believe that fractions give a much simpler, more complete, and easier to get your head around than a truncated repeating decimal ever could or would (ie: 31/54 is MUCH more intelligible than .5740740740... is). For simple formulas I am able to do the logical decimal to fraction conversions in my head, and for medium complexity setups I've had some luck with online converters but they start providing errant answers after a while too. Theoretically ALL the numbers you are generating should be rational numbers (And usually the denominator should be some power of how many sides the dice being used are [being able to change the multiplier from its default 100% has been VERY helpful making these patterns more obvious]); but is there some trick, site, or technique you know of to more quickly and accurately show your results tables as fractions instead of decimals, or to get from decimals to fractions. Thanks again for any help. P.S. Did you write the "dice rolled" "captcha" yourself or find it somewhere? |
| Fri Jan 8 19:05:12 2016 by Ron Vantreese |
| Let me just mention this as a fellow programmer who has studied the engineering and limitations of coding.... The numbers in floating-point format are based on the IEEE-754 standard. There are 2 popular types: the 32-bit and the 64-bit. Neither are capable of representing fractions. To computers, fractions are possible only in the base 2 boundary. Such as 1/2 == 0.5, or 1/4 == 0.25. Computers can't represent 1/10 well, and have difficulty even representing 0.1 because there's a 5 in the denominator. Also, Division is not easy for a computer to do (even though this statement is neither obvious nor intuitive). To test this division problem, just try dividing a number that's made of a product of 2 prime numbers, each within the range of 24-bit to 32-bit. Having a constant floating-point number means that the computer doesn't have to spend time regenerating it through division. Reducing the total number of divisions in a rendering engine through reformulation can reduce the time of the render. |
| Wed Jan 13 10:47:41 2016 by Torben |
| To start with the fractions part, the "Multiplier" field is at the moment the best I have to offer. Automatically deducing the denominator is not always simple. If there is a variable number or type of dice involved, the denominator can be very large or very complex. With exploding dice (accumulate) or recursive functions, the denominator can even be infinite. I did try making a variant of Troll using exact fractions, but I very quickly got overflow on the integers used to represent denominators and enumerators, even if I continually reduced the fractions during computation, so I dropped that. I have considered using fractions of unbounded integers, but that would be very slow. As for the dice CAPTCHA, yes I did make that myself. |