Upside-down f vector when d vector and e vector cancel

[Deleted user]

Test Device

MacBook Air

Operating System

macOS 10.14.6

Browser

Safari 13.0.2

Problem Description

For phetsims/qa#445. If you follow the steps to reproduce, you will see an upside-down f vector, which happens to be the zero vector.

macOS 10.13.6, macOS 10.14.6, and macOS 10.15.1 Beta + their respective versions of Safari have this issue.

Steps to Reproduce

I don't think you have to follow these steps in this exact order. Also, I'm not sure it's necessary to have all checkboxes checked.

1. Equations screen.
2. Magenta vector button.
3. d - e = f.
4. All checkboxes checked.
5. Go to the base vectors menu.
6. Increase theta_d to 45 degrees.
7. Decrease |e| to 5.
8. You should see an upside-down |f| = 0.0.

This also works on d + e = f if you have d = -e.

Visuals

Troubleshooting Information

!!!!! DO NOT EDIT !!!!! Name: ‪Vector Addition‬ URL: https://phet-dev.colorado.edu/html/vector-addition/1.0.0-rc.1/phet/vector-addition_all_phet.html Version: 1.0.0-rc.1 2019-10-23 17:30:32 UTC Features missing: touch User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.2 Safari/605.1.15 Language: en-US Window: 1440x837 Pixel Ratio: 1/1 WebGL: WebGL 1.0 GLSL: WebGL GLSL ES 1.0 (1.20) Vendor: WebKit (WebKit WebGL) Vertex: attribs: 16 varying: 15 uniform: 1024 Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 16) Max viewport: 8192x8192 OES_texture_float: true Dependencies JSON: {}

[pixelzoom]

Also relevant to From phetsims/qa#446.

Hmmm... I've followed these steps numerous times immediately after loading the sim, and I can't reproduce. I've tried both master and 1.0.0-rc.1. @lmulhall-phet were these steps reproducible immediately after starting the sim, or did you do some other things before the steps listed?

My test platform is macOS 10.14.6 + Chrome 77. But I would expect this bug to be independent of platform.

[Deleted user]

were these steps reproducible immediately after starting the sim

Yes.

My test platform is macOS 10.14.6 + Chrome 77. But I would expect this bug to be independent of platform.

It doesn't happen on Chrome.

[pixelzoom]

Wow, really odd. I have reproduced on macOS 10.14.6 + Safari 13.0.1, in master and 1.0.0-rc.1.

It is necessary to have the "Values" checkbox checked, but not the "Angles" checkbox. Steps 3-7 can be done in any order.

Investigating...

[pixelzoom]

I verified that it's not a problem on macOS 10.14.6 + Firefox 70.0.

I've also noticed that the position of the 'f' vector label is incorrect, regardless of whether "Value" checkbox is checked. The 'f' vector's tail is at (25,5), and that it where the label should be centered for a zero-magitude vector. Instead, it's a bit above (25,5), around (25,6.5), see screenshots below. This anomaly is also Safari-specific; it's in the correct location on Chrome.

"Values" checked:

"Values" unchecked:

[pixelzoom]

I can't reproduce on the "Cartesian" (blue vectors) scene. The orientation and position of the 'c' label is correct with all of my macOS 10.14.6 browsers, including Safari. E.g.:

[pixelzoom]

Changing d and e to magnitude '6' on Safari, the orientation is correct, see below. And going back to magnitude '5', the problem is still present.

[pixelzoom]

Vector label positioning and rotation are handled in RootVectorNode.updateLabelPositioning.

Here are the lines that rotate the label:

175 const modelAngle = rootVector.angle;
181 const xFlip = ( rootVector.xComponent < 0 ) ? Math.PI : 0;
197 const viewAngle = -modelAngle;
200 this.labelNode.setRotation( viewAngle + xFlip );

Adding this statement immediately after:

console.log( `modelAngle=${modelAngle} `+ 
  `viewAngle=${viewAngle} ` + 
  `rootVector.xComponent=${rootVector.xComponent}` + 
  `xFlip=${xFlip} ` + 
  `rotation=${viewAngle + xFlip} ` );

Safari:

modelAngle=null viewAngle=0 rootVector.xComponent=-8.881784197001252e-16 xFlip=3.141592653589793 rotation=3.141592653589793

So on Safari, modelAngle is null, and we're rotating by Math.PI, which is why it's upside down.

[pixelzoom]

Fixed in master and 1.0 in the above commits. The problem was actually the vector magnitude, nothing to do with the console.log stuff in #260 (comment). On Chrome and Firefox, magnitude was precisely zero. On Safari, it was a very small non-zero value (8.881784197001252e-16), and that resulted in the label getting run through the wrong layout algorithm. So the solution was to treat any value smaller than 1E-10 as effectively zero.

@lmulhall-phet please verify in master. The label's rotation and position should be correct. Specifically, its rotation should be zero, and it should be centered at (25,5), see screenshots below. If it looks OK, unassign and change the label to "fixed-awaiting-deploy".

"Values" checked:

"Values" unchecked:

[arouinfar]

Looks like this was a tricky one. Nice find @lmulhall-phet!

[pixelzoom]

One more cleanup step... I factored out const ZERO_MAGNITUDE_THRESHOLD = 1E-10; in the above commits to master and 1.0.

[Deleted user]

Looks fixed to me, @pixelzoom.

Just for my edification, could you explain to me why this bug occurred? From what I understand, all numbers in JavaScript are double-precision IEEE 754 values. From what you said, it sounds like |d| - |e| was being compared to 0 and |d| - |e| = 0 + epsilon. I'm wondering how this could be the case if both |d| and |e| have the exact same encoding.

[pixelzoom]

Sorry @lmulhall-phet, I have no idea why Chrome and Firefox result in a vector magnitude that is exactly 0, while Safari results in 8.881784197001252e-16. Could be indicative of a more subtle sum bug, or DOT/Vector2 bug, or difference in Safari. If I can find time, I might come back to this. But unfortunately I don't have time to investigate further right now.

[pixelzoom]

As a quick experiment in the browser console:

> var d = phet.dot.Vector2.createPolar( 5, Math.PI / 4 )
> var e = phet.dot.Vector2.createPolar( 5, Math.PI / 4 )
> d.plus( e ).magnitude
10
> d.minus( e ).magnitude
0

This yields the same results on Chrome, Firefox, and Safari. So this would point to this being a sim-specific problem.

[Deleted user]

Thanks, @pixelzoom. I was just curious because this is what we're learning in Computer Systems.

[pixelzoom]

Investigating further, because I'm curious.... I added these lines of code to EquationVectorSet, to print the vector values to the console:

vector.vectorComponentsProperty.link( vectorComponents => {
  console.log( `${symbol} x=${vectorComponents.x} y=${vectorComponents.y} magnitude=${vectorComponents.magnitude} angle=${vectorComponents.angle}`)
} );

 this.sumVector.vectorComponentsProperty.link( vectorComponents => {
  console.log( `${this.sumVector.symbol} x=${vectorComponents.x} y=${vectorComponents.y} magnitude=${vectorComponents.magnitude} angle=${vectorComponents.angle}`)
} );

Here's the output for the scenario shown in #260 (comment):

// Chrome and Firefox
d x=3.5355339059327378 y=3.5355339059327373 magnitude=5 angle=0.7853981633974483
e x=3.5355339059327378 y=3.5355339059327373 magnitude=5 angle=0.7853981633974483
f x=0 y=0 magnitude=0 angle=0

// Safari
e x=3.5355339059327386 y=3.5355339059327373 magnitude=5.000000000000001 angle=0.7853981633974481
d x=3.5355339059327378 y=3.5355339059327373 magnitude=5 angle=0.7853981633974483
f x=-8.881784197001252e-16 y=0 magnitude=8.881784197001252e-16 angle=3.141592653589793

The discrepancy here is that |e| is 5.000000000000001 on Safari, which results in a different magnitude (and angle!) I have no immediate guess as to why |e| is different on Safari.

[pixelzoom]

Passed QA in for phetsims/qa#445 and phetsims/qa#446. Closing.