#486 Cannot go down to [500,-500] in FENCE mode

[Sera Veni]

FENCE
SETPOS [500 -480]
SETHEADING 180
FD 20

This throws 'turtle out of bounds'.
While SETPOS [500 -500] does not.

[David Costanzo]

Thanks for reported this. I'd characterize this as "turtle sometimes cannot walk along the fence". This code also shows the problem

FENCE
CLEARSCREEN
RIGHT 90
FORWARD 500
RIGHT 90
FORWARD 1

This seems to be a problem with the interaction between FMSLogo's source code and gcc's optimizer (I cannot reproduce this in an unoptimized build). The "fence or wrap" logic compares floating point numbers (turtle's position) with integers (screen boundary). Without getting into technical details, this sort of "rounding error" is acceptable in C, so gcc is not at fault. It's up to FMSLogo to tolerate the rounding errors.

UCBLogo solves this problem by adding 0.5 to the screen boundaries (integer) before determining if it needs to wrap. Probably FLT_EPSILON would be enough.

If you need an immediate fix, you might be able to use the OWL version of 6.35.0, as that was compiled with a different compiler and I cannot reproduce the problem there. I can point you to if you can't find it.

Is FENCE important to you, or is this just some weirdness that you noticed and reported in the spirit of collaboration? I ask because there are a lot of features in FMSLogo that I have no idea if anyone uses. To me, FENCE seems like a weird feature.

[Sera Veni]

I use FENCE to determine the canvas size because not all Logo implementations have the same canvas size or have a primitive for querying canvas size, so it is easy to avoid triggering this. This is still worth fixing as there are scenarios where you ask the user for how to move but don't want turtles to go beyond canvas nor wrap around.

[David Costanzo]

I use FENCE to determine the canvas size because not all Logo implementations have the same canvas size or have a primitive for querying canvas size

Did you know that MACHINE outputs the canvas size in FMSLogo and MSWLogo? The canvas limits are the width/height, divided by two, truncated to an integer, as with INT. By default it's 1000x1000, but it can change depending on command-line parameters. Until the bug is fixed, that will be more reliable. And even after the bug is fixed, that will work even on versions that have the bug.

[Sera Veni]

Yes, but my code is meant to run on a variety of Logo implementations, not all of which have MACHINE. FENCE is one of the core primitives, and I could expect it available.

[David Costanzo]

I have checked in a fix for this. It will be available in FMSLogo 7.0.

I was wrong about UCBLogo solving the problem by adding 0.5 of tolerance. After reading the code more closely, the 0.5 is to account for the turtle location being in the middle of a pixel. UCBLogo does not handle FENCE correctly (particularly for small movements), as this code wraps

FENCE REPEAT 1000 [ FORWARD 1 ]

My fix was to allow for a tolerance beyond the screen extent before wrapping. DBL_EPISILON was too small, so I used the name number that POS uses to round the turtle's position (1/1,000,000, I think). This fixes the problem of the impercision after converting decimals to radians and computing the destination point (which in the case mentioned in the bug would waver 1e-14 over the extent). It's not perfect, but it handles the case cited in this bug, handles the "FOWARD 1" case that UCBLogo doesn't handle, and a few more cases that are now included in my regression tests.

I don't know if there is a perfect solution that doesn't involve a major design change. The turtle's position uses floating point numbers, but the screen extents, being in pixels, must be integers. C does not provide any guarantees that if you mix integers and floating point numbers, you'll be able to have well-defined inequalities.