Improve point tool's perceived accuracy

[amanda-phet]

@kathy-phet brought up concerns about the point tool displaying inconsistent values. We know this is because in these cases, not all locations are at exactly x=3 (could actually be 2.999 or 3.001), and the y-value is changing faster than the x-value.

To improve usability, and assist with the goal of using the point tool to identify solutions to the quadratic, @pixelzoom and I brainstormed a few different solutions.

The solution we like best is to do two things: (1) snap the tool to the x-value being displayed in the point tool, so if it says x=3 the tool will be at x=3 (2) calculate the y-value in the point tool using the x-value and the quadratic

This might result in the tool seeming a little jumpy on steep curves, but it seems like it will just be a few pixels and not too dramatic.

[pixelzoom]

Code that handles snapping to the quadratic is in PointToolNode.js:

        // If we're on the graph and the contents of the graph are visible...
        if ( graph.contains( position ) && graphContentsVisibleProperty.value ) {

          // snap to a quadratic, if we're close enough
          const snapQuadratic = pointTool.getQuadraticNear( position,
            GQQueryParameters.snapOffDistance, GQQueryParameters.snapOnDistance );
          if ( snapQuadratic ) {
            position = snapQuadratic.getClosestPoint( position );
          }
        }

[pixelzoom]

Done in master and 1.2 branches. This turned out to be very easy to add.

@amanda-phet @kathy-phet please review in master.

[pixelzoom]

@kathy-phet would like to make it easier to snap to integer x values. Full Slack discussion below. I'm going to add a query parameter that lets you set a tolerance for snapping x to integers.

Slack discussion

Kathy Perkins 11:47 AM I think the way the point tool is working now is good. I couldn't get to every "special point" it seemed due to exact pixel locations, but I think its fine. (e.g. the vertex was at (-1.25, -8.13) on my graph and I just could not hit -1.25 no matter how hard I tried. But it makes sense. we don't have 2000 pixels from -10 to 10. It would be a nice touch though if we could always get onto the integers (x=0,1,2,3,4). I am hitting some spots where I cannot land on an integer value of x. I don't know if there is a way to support being able to land on integers consistently? Chris Malley 11:48 AM Do you mean only on the quadratic, or in general? Kathy Perkins 11:56 AM Specifically I mean on the quadratic. Because its easiest to plug in integer numbers to the equation and calculate the solution. Chris Malley 11:58 AM First, we’d need to know what integer values of x (or values that will display as integers, like 2.99999) are actually on the quadratic — that’s the difficult part. Then we’d need to determine whether the point tool is currently “close enough” to one of those values. (edited) 12:01 For example, suppose that I have y = 1x^2. My point tool is on (1.97,3.88). How do I know that there is an x=2 that I could snap to? 12:02 Oh… I guess it doesn’t matter for x. We could just say “snap to integer if x is within N” Kathy Perkins 12:03 PM There is only one way I've thought of to do it, and I don't know if it is helpful / worth it. In projectile motion we plot "special points" on the curve. You could imagine that in addition to the curve, you also (invisibly) plot its "special integer points", and those are on "top" of the z-order, so if the tool is at one of those, it always displays the (integer, f(integer)) value. So you would need a set of y values for each x (-10 to 10) so array of 21 value pairs (and then plot any of those value pairs that fall between y=10 to -10. That is my thought. 12:04 Or as you say (snap to integer x if within a certain value). 12:06 If you do that approach, I guess I would however do two rules snap to the special points if within say 0.05, if they are being displayed. otherwise snap to integer points if within 0.05. Where 0.05 might have to be tweaked. This way if the vertex is at 1.99, you still get that as opposed to snapping to 2. (Although I could debate myself as which is of more value). Chris Malley 12:07 PM A “special points” approach is going to be a huge amount of work. Kathy Perkins 12:08 PM It's not worth a "huge amount of work" so if something is easy then go with easiest Chris Malley 12:10 PM So do you want me to try to implement something? Or should we hear from @amanda? Kathy Perkins 12:13 PM Hear from Amanda first. Do you have thoughts on what is "easy"? Chris Malley 12:14 PM Snapping to integer x if we’re within N. Finding the appropriate N will take some iterations, probably a query parameter for you to experiment. (edited) Kathy Perkins 12:18 PM OK. I need to work on a proposal. I'll let you and Amanda discuss. Pedagogically it seems nice to be able to hit the x=integers for sure, On smaller devices it will be even harder than it is on my laptop currently. Amanda McGarry:spiral_calendar_pad: 12:58 PM I think this is working really nicely! 1:00 If I think about the learning goals, I am not sure we need to put in a lot of work to make it snap to integers and special points. The Standard Form screen achieves the goal already of identifying the vertex and roots. And the tool works nicely on the Explore screen to approximate those points, or sometimes hit them exactly. On the first screen I think the goal of identifying points that make the equation true is being met. So, I will need to think about this some more, and I have meetings the rest of the day so I will probably need to think about it more tomorrow. Chris Malley 1:01 PM OK. I’m out tomorrow and Friday. Amanda McGarry:spiral_calendar_pad: 1:02 PM I agree that it’s nice to see integer coordinates on a curve, but not all curves will have that possibility once a is changed, so it seems like a feature that optimizes for the default curve and not many others (at least on the Explore screen) 1:02 So, I just need to think some more about this, but I’m really happy with how it’s functioning right now and think it’s a huge improvement! Chris Malley 1:02 PM Agreed, nice change. 1:04 I could implement the snapping to integers, and add a xSnapTolerance query param. This value would be how close x must to be to an integer to snap to that integer. If you set it to 0, it would effectively turn it off. (edited) 1:05 …. if it would help to have something to play with while you’re thinking about it. Kathy Perkins 1:05 PM Seems useful to have this to play with, if its not much work. K 1:06 And since you are out tomorrow.

[pixelzoom]

In the above commits (to master and 1.2 branches), I added snapping of x to integer values. This issue is now labeled "blocks-sim-publication", until we wrap up this issue.

Query parameter xSnapTolerance has a range of [0,0.5], and a default of 0.05 (as suggested by @kathy-phet). When the x coordinate (as displayed on the point tool) is xSnapTolerance or closer to an integer value, it will snap to that integer value. Setting this to 0 effectively disables the snapping to integers.

Reminder that this is an internal query parameter. If you provide an illegal value, it will complain in the browser console, and ignore your value. So you should probably experiment with the console open.

Finallly... The default value of 0.05 feels to large to me, especially since the precision of the point tool is 0.01. It makes it impossible to get to x values that are close to integers.

@amanda-phet @kathy-phet please review in master. Let me know what you want to change.

[amanda-phet]

When I experiment with xSnapTolerance it seems like the point tool just skips over the values close to the integer, which is strange to me. Even with a small value like .02 it is strange to me, so I would prefer to not add any snapping to the point tool.

[pixelzoom]

@amanda-phet I agree that it feels strange when it skips over x values close to integers. Since the point tool displays values to 2 decimal places (0.01), I think that xSnapTolerance needs to be < 0.01. Could you please try ?xSnapTolerance=0.00999999 and see if that feels better, and still snaps to x integers?

[amanda-phet]

I hadn't considered such a small value! I am comparing xSnapTolerance=0 and xSnapTolerance=0.00999999 and I don't notice a difference. Is it still valuable to have a snap tolerance, even if I don't really feel it, because it guarantees that I'll be able to put the point tool on the integer value? If so, I think 0.01 seems to work just fine. It doesn't feel skippy to me, but it also doesn't feel snappy. I just know I can get to the integer value.

[pixelzoom]

If you don't notice a difference, then my recommendation is to ditch the xSnapTolerance feature.

[pixelzoom]

I spoke with @kathy-phet and @amanda-phet separately.

@kathy-phet like the behavior with xSnapTolerance=0.00999999.

@amanda-phet didn't notice a difference between xSnapTolerance=0.00999999 and xSnapTolerance=0 (effectively disabled) but is OK with keeping the feature.

I'm going to remove the query parameter, change the logic from <= to <, and use 0.01 as the snap interval.

[pixelzoom]

Done in the above commit.

Ready for testing in the next RC. To test, while sliding a point tool along a curve:

• Verify that you do not see the same x value with different y values as you're dragging.
• Verify that you can put the point tool at integer x values, e.g. ( 3, 3.33 ).

[Nancy-Salpepi]

-x values change when y values do -I can place point tool at integer x values

[amanda-phet]

@pixelzoom I'm using https://phet-dev.colorado.edu/html/graphing-quadratics/1.2.0-rc.2/phet/graphing-quadratics_en_phet.html and the point tool is behaving as though it is snapping at .05. This is noticeable to me because yesterday I was easily able to get values around an integer and can't with this version.

[KatieWoe]

Adding on to what Amanda is saying, this snapping behavior seems to happen around the x whole integer values, which is mostly what seems odd to me.

[Nancy-Salpepi]

I see what you are saying @amanda-phet. The snapping occurs .05 away from an integer. Otherwise, all x values can be seen.

[pixelzoom]

I'll need some specific examples. There's are lots of different varieties of snapping going on here.

[pixelzoom]

Oh rats, I see what happened. I cleaned things up in master, forgot to cherry-pick https://github.com/phetsims/graphing-quadratics/commit/f6a6dc5d8864aece9650fef279f070f855a0a385 to the 1.2 branch. So the completed work didn't make it into 1.2.0-rc.2.

We'll need another RC. 😡

[Nancy-Salpepi]

OK...so no need for my video then?

[pixelzoom]

No @Nancy-Salpepi, but thank you. No need to do anything else with this issue until the next RC.

I've patched the 1.2 branch in the above commit. Ready for testing in the next RC.

[pixelzoom]

On second thought... Before we published the next RC, I'd like @amanda-phet to verify the behavior again in master please.

[amanda-phet]

Looks good on phettest now.

[pixelzoom]

Great, thanks @amanda-phet. Ready for the next RC.

[stemilymill]

https://github.com/phetsims/qa/issues/704

The snapping behavior of the point tool is correct, but I noticed that in the Focus & Diretrix screen, the Point on Parabola graph option shows the old behavior with multiple y-values for one x-value. @amanda-phet is this ok, or should the behavior match the point tool?

[pixelzoom]

Thanks @stemilymill, good observation about the Point On Parabola.

While this behavior would be similar to the Point Tool, it does not involve the Point Tool, and would be a new feature. So I've move that change to https://github.com/phetsims/graphing-quadratics/issues/172.

Closing this issue, since the Point Tool has been verified.