Slight discrepency in shift-key step size when using Shift + W

[terracoda]

While testing issue #275, I noticed a slight discrepancy in shift-key step size when using Shift + W when using Both Hands. I've opened a new issue in case this is a separate from #275.

The discrepancy might be a little random (not sure). It might also have to do with intended or unintended snapping behaviour (again not sure).

Both Hands at Tick Mark zero

Both Hands at bottom

Both Hands 1 shift-key step up

The part that seems a bit strange is that sometimes, I can get to the challenge ratio by moving the left hand up 2 shift-key steps and the right hand up only 3 shift-key steps. THIS MIGHT BE INTENDED BEHAVIOUR AS THINGS ARE FUZZY close to zero/close to the bottom.

Steps to reproduce 2 steps: 3 steps:

1. With keyboard using Both Hands OR Sliders, move the hands to the bottom, or to zero using tick marks.
2. Move the right hand up 3 shift-key steps
3. Move the left hand up 2 and you should get challenge ratio
   If you move the left hand up 2 shift-key steps first, it doesn't seem to happen.

To reproduce or see the difference is step sizes:

1. Turn on numbered tick marks
2. Using keyboard and Both Hands interaction move the hands to Tick Mark zero.
3. Using shift-key key presses each hand up.
4. The left step with Shift + W seems slightly smaller.

Again, this might be intended behaviour as THINGS ARE FUZZY near the bottom.

[terracoda]

Do I need to tag phetsims/qa#582?
Note I was testing from Master.

[terracoda]

@zepumph, I just noticed that this slight difference only happens if I move the right hand first and then the left hand. This might have something to do with the left hand trying to find ratio with the right hand???

If I move the left hand up first and then the right had up, the Shift + W and the shift + Up Arrow seem to make the same size step.
These look like even sized steps. I moved the left hand first.

[zepumph]

Steps to reproduce 2 steps: 3 steps

This is a biproduct of using small values, and our positional fitness algorithm. This didn't happen when the no-success value threshold was at .021, but it is now at .01. Please recommend how to proceed.

To reproduce or see the difference is step sizes:

I was unable to reproduce this until your tip in #314 (comment). Then, using ?log, I was able to see that the model actually is giving the wrong value:

left: 0.005, 
right: 0.01, 
distance: 0.005, 
current ratio: 0.5, 
target ratio: 0.5,
unclampedFitness: 0.965

I'll investigate.

[zepumph]

The above doesn't fix the problem, but I wanted to make sure that the shift key step size was as accurate as possible, and since #243, we need to apply toFixed to input values that will change the model.

[zepumph]

Oh! The issue is that the "conservation of snap" logic is acting upon this, where since we are passing over the "ideal" value with the left value, it goes directly to that value. I think the fix here is to make sure that that behavior doesn't happen when we are < the no-success threshold.

[zepumph]

Ok, I was able to fix this by having the snapping function ignore the snap-to-ratio feature when it is in the no-success range. This should solve all of the problems you mentioned. Also note that ?log was helpful here to discover that the left value was snapping directly into ratio range.

please ignore my initial thoughts in #314 (comment):

This is a biproduct of using small values, and our positional fitness algorithm. This didn't happen when the no-success value threshold was at .021, but it is now at .01. Please recommend how to proceed.

Anything else here?

[terracoda]

Awesome work :-)
Thanks and closing.