Large to small ratios have a ridiculous margin of error for in ratio

[KatieWoe]

Test device
Dell and Lovelace
Operating System
Win 10 and ChromeOS
Browser
Chrome
Problem description
For phetsims/qa#601.
When the My Challenge ratio has a larger left hand side than right hand side, the acceptable range for something to be in ratio, is much, much larger than the equivalent ratio with the right hand side larger. For instance, with a 10:1 ratio with rhs at 1, at ratio can be reached with lhs at about 6. This happens at smaller ratios as well, such as 5:1, but it is even more noticeable with large ratios.
Steps to reproduce

1. Go to the second screen
2. Set my challenge to 10:1
3. Set right hand side to 1
4. Drag lhs around to note in/out of ratio behavior

Visuals

Troubleshooting information:

!!!!! DO NOT EDIT !!!!!
Name: ‪Ratio and Proportion‬
URL: https://phet-dev.colorado.edu/html/ratio-and-proportion/1.0.0-rc.1/phet/ratio-and-proportion_all_phet.html
Version: 1.0.0-rc.1 2021-01-26 23:41:16 UTC
Features missing: applicationcache, applicationcache, touch
Flags: pixelRatioScaling
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.146 Safari/537.36
Language: en-US
Window: 1280x658
Pixel Ratio: 1.5/1
WebGL: WebGL 1.0 (OpenGL ES 2.0 Chromium)
GLSL: WebGL GLSL ES 1.0 (OpenGL ES GLSL ES 1.0 Chromium)
Vendor: WebKit (WebKit WebGL)
Vertex: attribs: 16 varying: 30 uniform: 4096
Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 32)
Max viewport: 32767x32767
OES_texture_float: true
Dependencies JSON: {}

[KatieWoe]

Checked against phetsims/qa#582, and it looks like this might be a new issue.

[KatieWoe]

While testing NVDA I realized this might be even more serious as an a11y issue, as the screen reader reads out misleading info. The reading matches the color and metronome sound on the screen, but it may be less obvious on a screen reader that something is off, especially with tick marks off.

Image.from.iOS.MOV

[zepumph]

Yes this is a byproduct of the new fitness algorithm from #325. The old algorithm was reciprocal in which it treated 10:1 and 1:10 in the same way, just swapped, by grabbing the min of the two to set fitness. This new algorithm does not do that, it has a specific assumption that the fitness will always be two tick marks of distance for the right hand, and the left hand depends on the target ratio.

@emily-phet, will you please let me know if you want me to spend time on this. I personally am ambivalent, but feel like the current fitness algorithm is much simpler than the old way, but I understand if this byproduct is unacceptable. Let me know if you need more information or a meeting.

[emily-phet]

@zepumph - would doing the following address the issue: Recognize when the antecedent is greater than/less than the consequent, and invert the algorithm accordingly. So if you're comparing 10:1 to 1:10 you're comparisons will feel the same wrt to when you're getting increasingly positive feedback?

If this addresses the issue, and is relatively straightforward to do, I'm not sure if it will just introduce another set of challenging behavior somewhere else as an outcome. Perhaps we're a whack-a-mole state?

What happens right now when the antecedent and consequent are the same? Does each hand still have a different range of positive feedback, or are they the same? Just checked, looks feedback is the same for the right and left hand in this case. I think my suggestion above might work then, as the consequent is higher, you'd get the current feedback, as the antecedent is higher you'd get the reverse, and when the antecedent = consequent both sides would be the same. Thoughts?

[zepumph]

I like that idea! I am not conditionally flipping the fitness when the targetRatio is greater than 1. I couldn't find any wack-a-mole gotchas that this caused. Will you please play around with master to see if you like the reciprocal behavior?

@KatieWoe will you also please review to see if this fixes the issue that you reported, and doesn't alter the fitness behavior in another way?

[zepumph]

I went ahead with the next RC, and included this in it. @KatieWoe can review this as part of that issue, phetsims/qa#609. @emily-phet let me know what you think.

[brooklynlash]

There still seems to be issues with the margin for error, it is too small now, and the lock ratio button is really hard to achieve.

[zepumph]

That is expected. It should be the exact same as if the target was 1:10 and you were moving the left hand.

[KatieWoe]

I think this is ok from what I can see. @brooklynlash if you are seeing problems, let me know and we can go over them and this may be reopened.

[KatieWoe]

Nevermind, just saw note not to close

[zepumph]

Thanks for the QA check. Over to @emily-phet to confirm.

[emily-phet]

Looks good to me!