When using basic equations of motion it’s expected that you would get near accurate results compared to simulating in Roblox. Of course, we should expect a small error that shouldn’t be impactful on a small scale; this is not the case. The following output displays the results from dropping a part with gravity set to 1000 for ~3 seconds.

```
Spring Solver:
Actual Y: -4487.51171875
Expected Y: -4487.5002998815
Difference: -0.011418868496548
Precision Error: 3.8115869238115e-06
PGS Solver:
Actual Y: -4543.853515625
Expected Y: -4537.5689315842
Difference: -6.2845840407535
Precision Error: 0.0020861710895411
```

Actual Y is the where the part ended up.

Expected Y is where it was calculated to end up.

Precision Error is the difference/(gravity*time) or (different/gravity)

The tests are obviously over-the-top, but now we can substitute a gravity number we actually use (32.174)

```
Spring Solver:
Actual Y: -144.783203125
Expected Y: -144.78272288717
Difference: -0.00048023782730411
Precision Error: 4.9754282804296e-06
PGS Solver:
Actual Y: -146.59851074219
Expected Y: -146.39586527024
Difference: -0.20264547195092
Precision Error: 0.0020878773042806
```

The precision errors are both constant for each solver, though PGS is constantly poor. If you’re working with higher gravity or longer simulation times the difference between what you calculate (and expect) vs what is simulated is far less accurate in PGS.

In the above example is the conditions we need to work. A 0.2 stud offset in a low gravity and small simulation time can make it hard to work with PGS. For now we’ve accounted for the percision error by adding a larger offset to accomplish what we want to do, but it adds some unnessecary complications. It feels wrong that over such a small simulation, we have to account for such a large error.