Motion and Position Bug

Bug reports
1

Please fill out these questions for all feature requests and bug reports. If you're requesting a feature, please let us know why this feature is important or useful, not just what it should do.
Thanks!

  1. What browsers show this problem? Chrome
  2. Please share an example project (if possible). Here
  3. Describes the steps to reproduce this issue. Run the main script and stop it
  4. What does Snap! currently do? The sprite disappears and its position is incorrect. For example, if you use a go to (0,0) block, it reports its position as (30,-30), and going to (-30,30) makes it report (0,0)
  5. What should Snap! do instead? Keep the sprite visible and report its position correctly

Also, setting the variable throttle to 0 should make it go nowhere, but it instead it accelerates rapidly.
For some reason, running a 'point in direction' block fixes it, but reloading the page resets the bug. If anyone has any ideas as to why this is happening, please mention them.

2

Confirmed. But it works for me in Firefox.

Just examining the direction is enough to fix it; you don't have to change the direction.

3

Yes @legoman3.14, it is an ugly behavior (@bh, is running for you?)

The problem here is JS floating-point numbers. We have no integers and so, we know some ugly behaviors with decimals... but also we have the same problems when numbers are to big ( MAX_SAFE_INTEGER is ( 2^53 - 1 ).

In this project you are using go to x: () y: () block with bigger inputs... and so, he have "mathematical problems".

You can think using BigNums lib, but it won't be ok, because here we have internal JS calculus, and you will get some NaN results.

I have not a quick solution. I can see some issues, with big integers and also with decimals. Maybe we must check the final position. I know we need to use moveBy because we need the path (maybe we are painting when we move something), but we can check the final position (because "movingBy" is using canvas positions, and doing some extra calculus).

Joan
Joan

4

Ah. The official Logo solution to this problem is to do turtle positioning in long integer with a unit of 1/1000 pixel or 1/10000 pixel. Then we could use bignums if necessary. Most Logo implementations do it that way, not for fear of overflow, but because with enough cleverness, integer arctan can be very fast, even on old computers with slow floating point.