[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LOGO-L> Total Turtle Trip



On an Ideal computer going to infinity they are the same.

I think I understand Chucks view and it's much like mine. I don't
think Chuck has warmed up to you POLY tree huggers yet :-)

I have never stated otherwise that POLY is an important exercise,
PERIOD.
I hope chuck agrees. Not as a general circle but that it approaches a
circle at its limit.

I know (I'm pretty sure Chuck agrees) that inherently POLY is a
terribly bad way to draw a circle on a non Ideal computer.

But technically from a mathematical (Ideal Computer) point of view
POLY can produce the same approximation. Some of the arguments Chuck
uses below also exist for drawing it with his method. I know they do
because I had to deal with them in ARC which does not use the POLY
method. I had to write special code to handle the starting and
ending points in case they did not land on one of the "regularly"
spaced "dots". ARC actually connects the "DOTs" as well, as ARC's get
huge the screen resolution cannot show its curvature.

Now since most of us work on non Ideal computers the Chuck/ARC
method better. It's (arguably) slightly easier to work with
for the boundary conditions and it does not unnecessarily
accumulate error and "Chucks" method can be optimized easily by
skipping the BK's and FD's and simply calculating the coordinate
of the "DOT" in stead of back to the center to just change the
angle for the next dot (almost as inefficient as poly).

This discussion is also bordering on yet another related thread
drawing from the center versus the edge. I gave up and put in both
(ARC and ARC2) and I'm glad I did because both are very useful.

Chucks method of doing
for [ang 0 360] [PU FD :RAD PD DOT PU BK :RD RT 1]

will produce exactly what

for [ang 0 360] [pu setxy xcor + :rad*sin :ang xcor + :rad*cos :ang PD
DOT PU]

will.

The later is what ARC does except it connects the DOTs and calculates
how many DOTs are needed based on the radius and screen resolution
(like he mentioned, drawing dots just below the screen resolution).

Now perhaps the difference between these two methods that I claim
is not a difference may not meet Chucks "Turtle Geometry" rules.
But they will produce the same exact points and likely even the same
error on a non Ideal machine. Keep in mind that FORWARD's internal
implementation does not comply with Chuck's "Turtle Geometry" rules
either (i.e. it uses trig and SETXY just like ARC does).

On a non Ideal computer POLY will not produce the same curve as
Chuck's/ARC but can "lite" the same pixels (with some fine tuning
and with out going to infinity).

P.S. In 3D the same exact method is used but is translated and rotated
to the turtles current 3D Orientation and 3D position.

Jim Muller wrote:
> 
> At 09:46 PM 10/27/97 -0500, Chuck Shavit wrote:
> >
> >
> >Hi Jim,
> >
> >At 06:23 PM 10/27/97 -0600, you wrote:
> >>Chuck ==>
> >>
> >>Here's a procedure that does just what you stated above. Other than some
> >>added steps, how does this differ from the polygon procedure? It's still FD
> >>1, RT 1 repeated for as many times as required to draw a line equidistant
> >>from a center.
> >>
> >>TO CIRCLE :SIDE
> >>HOME CS PU
> >>REPEAT 360 [FD :SIDE POINT BK :SIDE RT 1]
> >>END
> >
> >The obvious difference between the above CIRCLE and a "classic"
> >polygon-based procedure (call it MCIRCLE) is that CIRCLE draws a circle
> >around the turtle position, while MCIRCLE draw a circle which is tangent to
> >the direction of the turtle.  BTW, I would remove HOME CS from the
> >function, to make it more general.
> 
> HOME CS is simple housekeeping to start from a clean slate.
> 
> >
> >But other than the above, CIRCLE differs from MCIRCLE in two very
> >fundamental ways.
> >
> >A mathematical circle is defined by two parameters: its center, and its
> >radius.  If you have a specific circle in mind (=defined by a specific
> >center+radius), you can use CIRCLE to draw it for you.  But you cannot use
> >MCIRCLE because you never know what center and radius you'll get.  That's
> >why I call it MCIRCLE -- Mystery Circle.  Note that the mystery is even
> >bigger if the caller doesn't know how MCIRCLE is implemented, e.g., with
> >180 iterations of RIGHT 2, vs. 360 iterations of RIGHT 1.
> >
> >The other difference is more subtle, yet important.  MCIRCLE is implemented
> >with three variables: the FORWARD amount, the RIGHT amount, and the
> >iteration count.  The three are interrelated in a somewhat complex way.
> >For example, you have to make sure that 360 modulo the RIGHT amount is
> >zero.  In CIRCLE, the only number that matters is the radius (what you call
> >SIDE).  The RIGHT amount can be any non-zero number.  It can even be a
> >random number, with a different value in each iteration.  And the RIGHT can
> >be replaced with LEFT.  Likewise the iteration count can be any number, and
> >the bigger it gets, the "more" circle you get.
> 
> You've lost me here.  The result I got was definitely not circular. WHen I
> try to change the relationship of...
> 
> REPEAT 360 [... FD 1 ... RT 1]
> 
> the result isn't a circle. POINT is, in effect, the same as FD 1.
> 
> TO POINT
> PD RT 90 FD 1
> BK 1 LT 90 PU
> END
> 
> I'm asking out of ignorance...not as a challenge. I don't understand what
> you're saying.
> 
> >
> >This last issue is related, I think, to what Mike Doyle was saying.  The
> >relation between MCIRCLE and a mathematical circle is somewhat fuzzy.
> >Mike's mistake, if I understand him correctly, is that he thought that
> >MCIRCLE is the only Logo-ish way to draw circles.  But maybe I missed
> >something in what Mike was saying.
> >
> >Chuck Shavit
> >
> >
> >
> >+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>
> Jim Muller
> jmul@cyberramp.net
> The Great Logo Adventure at
> http://www.cyberramp.net/~jmul
> >+>+>+>+>+>+>+>+>+>+>+>+>+>+>+>
> ---------------------------------------------------------------
> Please post messages to the Logo forum to logo-l@gsn.org.  Mail
> questions about the list administration to logofdn@gsn.org.  To
> unsubscribe send    unsubscribe logo-l    to majordomo@gsn.org.

-- 
===============================================================
George Mills (mills@softronix.com)
http://www.softronix.com/
The www page contains some very powerful educational software.
Our single most important investment is our kids.
---------------------------------------------------------------
Please post messages to the Logo forum to logo-l@gsn.org.  Mail
questions about the list administration to logofdn@gsn.org.  To
unsubscribe send    unsubscribe logo-l    to majordomo@gsn.org.



Global SchoolNet Foundation - Linking Kids Around the World!
Copyright GSN - All Rights Reserved - Comments & Questions
Visit GSN's Global Schoolhouse for more exciting learning resources!
Search our Site - Home