On this screen I have asked the calculator to select a random element from a shuffled list of 3-digit decimal numbers, then multiply that number by 100 for display as an equivalent percentage. When displayed, that decimal number sometimes appears as a decimal number with many digits that is approximately the correct value, but off by 0.000000001 or something to that effect. It only appears to have this issue when the list has been shuffled before selecting the value. I know many work arounds, but I am wondering if this is a bug, some issue I should anticipate based upon how Desmos calculates a terminating decimal number times 100 (a seemingly simple thing to do), or if I am using the Shuffle function incorrectly…? I don’t believe the activity I created last year using this type of process had this issue. Has something changed recently that would have created this issue?
The second number in the list of four is the one I am having difficulties with. If it isn’t showing the symptoms I have described, press the Shuffle button a few times and then you’ll see what I am talking about.
Thanks in advance for any insight you can offer as to what might be going on here.
Just a follow-up on my original post. I have checked several other activities that used the (random(shuffle()) as a method of selecting a decimal number, which were then multiplied by 100 for display as a percentage. All of those activities that I created are now having this issue. I know they were not having this problem before. When I remove the shuffle() function or use integers instead of decimal numbers in my original lists it seems to eliminate the issue. With some more testing, the problem definitely appears to be caused by the interaction between the shuffle() function and selected decimal-number list elements (regardless of the number of decimal digits) that are then operated on (in my case, multiplying by 100).
I will often design the components on one screen to give randomly selected values for repeated practice problems. I’ll then copy that screen to create the next screen and change some aspect of the problem. Unfortunately, the ‘random’ selections on every screen in the activity seem to be the same selection (because I tie the random function to a ‘Try Another Problem’ action button on each screen, which always starts at a value of zero), but I figured out that using the shuffle function before selecting a random element made the selections different. I’ve since started using a different method to avoid that issue. If you understand what I am describing and have an easy way to avoid that, I am open to suggestions.
It appears to me using only shuffle still results in the issue I am describing though. So I’m not sure what’s going on?
The CL will generate differently each time it is run, plus the added seed of pressCount to the generator itself to update on button press. There’s also .int() instead of .float(), and the seed argument for randomGenerator() is not required. Copying to new screens will also generate different random seeds.
I didn’t realize that the CL randomGenerator didn’t have the same behavior as the calculator’s random function. Lately, instead of using the shuffle function I had been defining the seed of the graph’s random function as the sum of the action button’s presscount AND some initial value that I was setting using a slider in the calculator. I just had to be sure to adjust that slider to have a different initial value on each screen of the activity. Instead, it looks like I can use your suggestion and won’t have to ever set that initial value - I can just copy from screen to screen with no worries about the random selections.
The CL randomGenerator doesn’t seem to have the problem I was describing in my initial post that the shuffle() function is creating with displaying decimal numbers. Double win!