Answered by:
Strange output from nested loop for squares using the Turtle
Question

Does anyone know why that after the 13th square is drawn the following squares become skewed?
Sub ClosedSquares x = 320 y = 320 Turtle.X = x Turtle.Y = y For i = 5 To 205 Step 10 Turtle.PenUp() Turtle.MoveTo(x  i/2, y + i/2) Turtle.Turn(135) Turtle.PenDown() For n = 1 To 4 Step 1 Turtle.Move(i) Turtle.TurnRight() EndFor EndFor
Saturday, December 29, 2012 1:04 PM
Answers

That is indeed strange behavior. I can not explain it, but I can offer an alternative method. Import: GVG321 Link: here
It works much faster and it doesn't get skewed. Probably the reason why it skewed would be that the way the turtle turns is off by less than a degree. So after a few turns, it's not noticeable. But after, say, the thirteenth turn, it becomes quite noticeable. I'm not sure of that, but it's all I can offer.
I am a 10 year old that loves math, games, and computers. 'Binary is as easy as 1, 10, 11.'
 Marked as answer by Jibba j Saturday, December 29, 2012 10:38 PM
Saturday, December 29, 2012 3:54 PM 
I suspect an rounding error after so many turns. If you let the turtle run longer (end of the for loop e.g. 305) you will see that the fourteenth square is tilted to the right, the 15th is good, the 16th is tilted to the left, the 17th is again good, and so on.
It is not dependent on the coordinates (tried that with Step 20), or on the position on the GraphicsWindow.
Jan [ WhTurner ] The Netherlands
 Edited by WhTurner33Editor Saturday, December 29, 2012 5:10 PM
 Marked as answer by Jibba j Saturday, December 29, 2012 10:52 PM
Saturday, December 29, 2012 4:16 PMAnswerer 
Internally, the Turtle.Move is turned into and angle and distance  this does result in rounding errors. My guess is that somewhere, different accuracies of pi are being used.
We can see this if we print the turtle angle:
Turtle.Speed = 10 x = 320 y = 320 Turtle.X = x Turtle.Y = y For i = 5 To 205 Step 10 Turtle.PenUp() Turtle.MoveTo(x  i/2, y + i/2) Turtle.Turn(135) Turtle.PenDown() 'Turtle.Angle = Math.Round(Turtle.Angle) TextWindow.WriteLine(Turtle.Angle) For n = 1 To 4 Step 1 Turtle.Move(i) Turtle.TurnRight() EndFor EndFor
If you now uncomment the line that sets the turtle angle to the nearest integer, all is well.
 Marked as answer by Jibba j Saturday, December 29, 2012 11:24 PM
Saturday, December 29, 2012 6:24 PM
All replies

That is indeed strange behavior. I can not explain it, but I can offer an alternative method. Import: GVG321 Link: here
It works much faster and it doesn't get skewed. Probably the reason why it skewed would be that the way the turtle turns is off by less than a degree. So after a few turns, it's not noticeable. But after, say, the thirteenth turn, it becomes quite noticeable. I'm not sure of that, but it's all I can offer.
I am a 10 year old that loves math, games, and computers. 'Binary is as easy as 1, 10, 11.'
 Marked as answer by Jibba j Saturday, December 29, 2012 10:38 PM
Saturday, December 29, 2012 3:54 PM 
I suspect an rounding error after so many turns. If you let the turtle run longer (end of the for loop e.g. 305) you will see that the fourteenth square is tilted to the right, the 15th is good, the 16th is tilted to the left, the 17th is again good, and so on.
It is not dependent on the coordinates (tried that with Step 20), or on the position on the GraphicsWindow.
Jan [ WhTurner ] The Netherlands
 Edited by WhTurner33Editor Saturday, December 29, 2012 5:10 PM
 Marked as answer by Jibba j Saturday, December 29, 2012 10:52 PM
Saturday, December 29, 2012 4:16 PMAnswerer 
Internally, the Turtle.Move is turned into and angle and distance  this does result in rounding errors. My guess is that somewhere, different accuracies of pi are being used.
We can see this if we print the turtle angle:
Turtle.Speed = 10 x = 320 y = 320 Turtle.X = x Turtle.Y = y For i = 5 To 205 Step 10 Turtle.PenUp() Turtle.MoveTo(x  i/2, y + i/2) Turtle.Turn(135) Turtle.PenDown() 'Turtle.Angle = Math.Round(Turtle.Angle) TextWindow.WriteLine(Turtle.Angle) For n = 1 To 4 Step 1 Turtle.Move(i) Turtle.TurnRight() EndFor EndFor
If you now uncomment the line that sets the turtle angle to the nearest integer, all is well.
 Marked as answer by Jibba j Saturday, December 29, 2012 11:24 PM
Saturday, December 29, 2012 6:24 PM 
Thanks for your generous insight, most helpful. I will check your link when i get a chance. I think the turtle has some issues.Saturday, December 29, 2012 10:38 PM

Thanks for that. Yes i think for the turtle for this type of graphic needs to be dependent on coordinates and not angles and length.
I wouldn't have thought that the position of the GraphicsWindow would impact on this. I suspect your right about coordinates, the logic would be coordinates within the GraphicsWindow.
 Edited by Jibba j Saturday, December 29, 2012 10:51 PM
Saturday, December 29, 2012 10:43 PM 
Great answer, Thanks. You've introduced me to some good concepts to considor for future programming, in particular that there certain limitations in certain approaches for particular problems.
Limits could be:
 rounding for TurnRight, however this should = 90.00 degrees.
 rounding for Move(i), however this should = i.
So maybe the rounding errors come about when the above statements internally reference the beginning and end coodinates as the coordinates would begin to require large amounts of decimal places.
Therefore it could well be a matter of truncating.
http://en.wikipedia.org/wiki/Truncation
So sorry turtle, not your issue, an issue for mathematics in computer science.
My mistake. Bottom line is find an approach that actually works. Although it is interesting and imformative to explore the reasons why some approaches don't work.
Thanks for your insight.
Saturday, December 29, 2012 11:24 PM 
I did last night some more experimenting:
When you change the TurtleTurn(135) to TurtleTurn(225) with no other change the program can easily draw 70 squres with no deviation.
Jan [ WhTurner ] The Netherlands
Sunday, December 30, 2012 10:55 AMAnswerer 
That's an interesting trick on the truncating limit for this approach.
I think the most robust approach is by only running coordinates. Here's a never ending loop that should never skew.
http://smallbasic.com/program/?KTH055
To run any calculation refering to distance and or angles is exposing the program to truncation limitations.
Sunday, December 30, 2012 1:37 PM