HDTenEightyP/NetNews huggingface dataset:
From: max@Kolmogorov.gac.edu (Max Hailperin)
Newsgroups: comp.lang.logo
Subject: Re: um, maybe this is a silly question
Date: 13 Oct 92 19:17:42 GMT
 <1ba7vcINNpam@agate.berkeley.edu><1992Oct12.163421.24051@sctc.com><1992Oct13.035329.19258@pasteur.Berkeley.EDU>
Reply-To: Max Hailperin <max@nic.gac.edu>
Distribution: usa
Organization: Gustavus Adolphus College, St. Peter, MN
In-reply-to: matt@volga.Berkeley.EDU's message of Tue, 13 Oct 1992 03:53:29 GMTLines: 51

In article <1992Oct13.035329.19258@pasteur.Berkeley.EDU>
 matt@volga.Berkeley.EDU (Matt Wright) writes:

   ...
   int Factorial(int x) {
       int result;
       result = 1;
       while (x > 0) {
           result *= x;
           x--;
       }
       return result;
   }

   Should you initialize result to 1 or 0?  Is it while x >0 or x >= 0, or 
   x > 1 ?  Don't forget to decrement x each time you loop...  etc, etc...

   ...

Ok, I'm going to stop beating the dead horse after this, but it seems
like a good place to plug more concretely what I said in the abstract.
Let's rewrite your procedure a little and show that the various
boundaries, initial values, whatever, are trivial by explicating them
with overkill comments:

int factorial_product(int x, int n){ /* computes x * n! */
   if (n == 0)
     return x;  /* because x * 0! = x * 1 = x */
   else
     return factorial_product(x*n, n-1);
       /* because x * n! = x * (n * (n-1)!) = (x*n) * (n-1)! */
   }

int Factorial(int n) {
   return factorial_product(1, n); /* because n! = 1 * n! */
   }

Surely no one would "initialize the result to 0" because that means
saying to compute 0*n!, which clearly isn't going to equal n!.  You
just need to look at the spec.  The rest follows similarly.

Note that my version generates every bit as iterative a process as
yours, presuming a decent compiler.  The fundamental distinction isn't
between these two version, but rather between the two of them and the
version based directly on n! = n * (n-1)!.  It may be easier to solve
the problem that way (breaking off a subproblem) than this way
(transforming to a simpler problem with the same answer), but the
difference *isn't* the one you suggest.  Any problem you had figuring
out whether to start your "result" variable at 0 or 1 was purely a
product of not packaging the loop in such a way as to make clear what
the functional relationship was between its inputs and output.
From: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
Newsgroups: comp.lang.logo
Subject: Re: um, maybe this is a silly question
Date: 13 Oct 1992 17:32:54 GMT
Organization: University of California, Berkeley
Distribution: usa
NNTP-Posting-Host: anarres.cs.berkeley.edu

Max Hailperin <max@nic.gac.edu> writes:
>I find it mildly odd that you suggest a textbook for colleges, a
>language for high schools.  Of course, since I know you favor the
>"enlightened playing around" approach to "providing a context for
>learning" (as opposed to "teaching"), the environment/language is
>playing somewhat of the same role as a textbook.

I'm just too modest to mention my own textbook, that's all.

But I agree that _The Schemer's Guide_ is a plausible alternative.
To my taste, high school should be more about fooling around with
computers and less about formal learning, but I'm not dogmatic
about it.
Newsgroups: comp.lang.logo
From: matt@volga.Berkeley.EDU (Matt Wright)
Subject: Re: um, maybe this is a silly question
Organization: University of California, at Berkeley
Distribution: usa
Date: Tue, 13 Oct 1992 03:53:29 GMT

Rick Smith writes:
>Re: iteration vs recursion in C, Scheme, and Logo
> [...]
>However, recursion has pretty nasty boundary behavior, i.e., when you
>reach the limits of your machinery, recursive solutions suffer stack
>overflow.

It's funny that you refer to reaching your memory limit as "boundary
behavior", because when I first read your article I thought you were going
to say that writing a program recursively makes it difficult to get the
boundary conditions right.  That's not what you said, of course, but it
brings up another point in the recursion/iteration thread...

IMHO, writing a function recursively makes it incredibly easier to get the
boundary conditions right.

int Factorial(int x) {
    int result;
    result = 1;
    while (x > 0) {
	result *= x;
	x--;
    }
    return result;
}

Should you initialize result to 1 or 0?  Is it while x >0 or x >= 0, or 
x > 1 ?  Don't forget to decrement x each time you loop...  etc, etc...


TO FACTORIAL :X
IF :X = 0 [OUTPUT 1]
OUTPUT :X * FACTORIAL :X -1
END

In the recursive version, the only thinking you have to do about boundary
conditions is in the base case.  Furthermore, it's much easier to think
about, because instead of framing it as "what exactly will the computer do
when?" you can just ask yourself "what's 0 factorial?"

(Apologies to Brian Harvey for not writing the WHILE version in Logo; I
don't remember the syntax of the Logo WHILE he made up in CSLS...)

>I suspect the "right" way to teach programming is to start with
>recursion as the essential iterative technique, and then teach
>how to convert from recursive to iterative as an engineering task.

You mean, start with recursion as the essential iterative (and
non-iterative) technique, and then teach how to do tail-recursion
elimination when you take a compiler construction class in college.  :-)

-Matt
From: mills@athena.lkg.dec.com (George Mills)
Newsgroups: comp.lang.logo
Subject: Re: HELP WANTED installing DOSLOGO, MSWLOGO
Keywords: doslogo, mswlogo
Date: 11 Oct 92 01:04:48 GMT

scafati@thor.med.ge.com (Victor-charles Scafati 4-6784 MR Srv) writes:

>In article <mills.718554712@dialup.athena.lkg.dec.com>, mills@athena.lkg.dec.com (George Mills) writes:
>|> s911190@yallara.cs.rmit.OZ.AU (Kym R Thompson) writes:
>|> 
>|> >I am having some problems setting up DOSLOGO and MSWLOGO 2.0.
>|> >They run, BUT:
>|> 

>|> 
>|> >MSWLOGO - The HELP command produces the message "Help file
>|> >          missing ...", even though it (LOGO.HLP) is there !
>|> 
>|> Note that it looks in the area the logo.exe is located.
>|> I've never heard anyone have this problem before. logo.exe
>|> and logo.hlp must be in the same directory.
>|> 

>I hate to correct the author of the software but...

>When I was fooling around with mswlogo, I had this problem, and I solved it by 
>adding "set logopath=e:\logo" (which was my logo directory) to my autoexec.bat.
>The README file told me to do that if my logo directory was anything but c:\logo.
>Why don't you try this Kym?  I think that it will help.

I have no problem being corrected. But I still claim that I'm right.
The only thing logopath is used for is the "lib" directory.
In fact I have logopath pointing at a place that does not have
.exe or .hlp and it works in 3.0 or 3.1 windows.

I can't seem to break it as long as .exe is in the same directory as .hlp.
The code looks up the path the .exe was executed from and uses that for the
.hlp. In fact I plan to get rid of logopath and use the same method for finding
the lib directory but I was lazy.

Now doslogo is another story. The hlp "directory" must be in the logo
directory and the logo directory must be in c:\logo or have logopath set
where ever it is.

Are we mixing up dos versus windows logo or perhaps lib versus hlp.
From: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
Newsgroups: comp.lang.logo
Subject: Re: um, maybe this is a silly question
Date: 12 Oct 1992 18:14:29 GMT
Organization: University of California, Berkeley
Distribution: usa
NNTP-Posting-Host: anarres.cs.berkeley.edu

smith@sctc.com (Rick Smith) writes:
>I suspect the "right" way to teach programming is to start with
>recursion as the essential iterative technique, and then teach
>how to convert from recursive to iterative as an engineering task.

Not to beat a dead horse, but I really think the alleged dangers of recursion
are overstated.  It may be a problem if you're programming on an 8086 that's
limited to 64K of stack space, but on any real computer, if you have a memory
problem you probably also have an even bigger problem about execution time.

To a first approximation all algorithms are either like searching or like sorting.
If your algorithm is like searching, and you're running out of stack, you're using
a linear algorithm.  If you switch to a log-N algorithm, you'll have plenty of
stack space, unless the size of your problem is very different from what most of
us face.  If your algorithm is like sorting, then you'd better be using a
divide-and-conquer method, in which case you need the stack space whether you
like it or not.  You can go to a lot of trouble to use non-recursive control
structures, but only by building your own data stack by hand, and that won't
help with the space issues.

If you describe recursively an algorithm that's really a loop, then your C
compiler will implement it iteratively.  (You *are* using gcc, aren't you?)
If not, then the technique of recursion elimination will still require a
stack, and not much is saved.

I do agree with the part of the message that says that programmers have
to be trained to learn to think recursively.  That's why colleges should
use Abelson and Sussman as their intro programming course, and high
schools should use Logo!  :-)
From: altenbur@plains.NoDak.edu (Karl Altenburg)
Newsgroups: comp.lang.logo
Subject: Logo Package Request
Date: 14 Oct 92 19:19:15 GMT
Article-I.D.: ns1.Bw4Lo3.E3t
Organization: North Dakota Higher Education Computing Network

I am fowarding this.  Do not reply to my address but to:

	E-mail  yura@polradis.spb.su

-----

From comp.ai.edu Wed Oct 14 14:14:51 1992
From: yura@polradis.spb.su (Yury Suharevsky)
Newsgroups: comp.ai.edu
Subject: HELP me with LOGO for IBM PC
Date: 14 Oct 92 14:43:06 GMT
Reply-To: yura@polradis.spb.su
Organization: JV POLRADIS (St.Petersburg)

Help me ! I need language programming LOGO for IBM PC.

Thanks.

E-mail  yura@polradis.spb.su
----

-- 
Karl R Altenburg				altenbur@plains.NoDak.edu
North Dakota State University, Fargo, ND  58105

All things are artificial, for nature is the art of God.  SIR THOMAS BROWNE
Newsgroups: comp.lang.logo
From: kahn@Csli.Stanford.EDU (Ken Kahn)
Subject: Re: um, maybe this is a silly question
Organization: Stanford University CSLI
Distribution: usa
Date: Thu, 15 Oct 1992 16:53:22 GMT

Brian says:
  So "things that are very important for a programmer to understand" are
  entirely beside the point in talking about how KIDS might learn to program.
  They can learn all that technical stuff in college, if they choose to study
  CS.

I'd like to understand this better.  My feeling is that the good stuff in
Computer Science is like the "Total Turtle Trip Theorem".  General/abstract
knowledge that can be profitably applied when trying to build a program.
I'll admit that much of CS is concerned with efficiency -- algorithms and
understanding how interpreters/compilers/operating systems, etc. work -- and
maybe most of the things kids do (and want to do?) are not constrained by
execution speed or memory usage.  I dunno.

 -ken
Newsgroups: comp.lang.logo
From: s2874066@techst02.technion.ac.il (Eyal Peleg)
Subject: 2 Questions: express logo ? hebrew on obejct logo ?
Organization: Technion, Israel Inst. of Technology
Date: Wed, 14 Oct 1992 22:26:41 GMT

hi all,
both questions are asked for friend :

  1) does anyone know detales of a communication program called
     "express logo" ?
     is it writen in logo ?
     is it a logo dialect ?
     any information would be welcomed.

  2) is it possible to use a hebrew font on object logo (MAC) ?
     the freind who asked me this question said he tried but
     the letters became non-readable.
     if its possible - how should it be done ?
     (as far as i know -but i am not sure- this friend DOES use
      other english fonts, and the problem is with the hebrw font only)

thanks
  eyal peleg
From: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
Newsgroups: comp.lang.logo
Subject: Re: um, maybe this is a silly question
Date: 14 Oct 1992 18:32:08 GMT
Organization: University of California, Berkeley
Distribution: usa
NNTP-Posting-Host: anarres.cs.berkeley.edu

brent@ssd.csd.harris.com (Brent Benson) writes:
> [...]  On the other hand, I think that learning (and
>teaching) the difference is not that hard and is worth whatever effort
>it does take.  This knowledge fosters a more thorough understanding of
>interpreters, compilers, machines, etc.  Things that are very
>important for a programmer to understand.

I've said this before, but...

This isn't comp.edu; it's comp.lang.logo, and I think we're talking here
about the education of KIDS, not of professional programmers.  So "things
that are very important for a programmer to understand" are entirely
beside the point in talking about how KIDS might learn to program.  They
can learn all that technical stuff in college, if they choose to study CS.
From: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
Newsgroups: comp.lang.logo
Subject: Re: LOGO riddle/task/thing to think about
Date: 10 Oct 1992 14:51:53 GMT
Organization: University of California, Berkeley
NNTP-Posting-Host: anarres.cs.berkeley.edu

The only way to know for sure about how many pixels per turtle step is to
find out the size of your screen in pixels, see how far forward the turtle
can go without hitting the wall, and dividing.

On a Mac, I'd be surprised if a turtle step weren't one pixel in the
horizontal and vertical directions, although of course diagonals are
more complicated.
Newsgroups: comp.lang.logo
From: dal3@cbnewsg.cb.att.com (dale.e.parson)
Subject: Re: um, maybe this is a silly question
Organization: AT&T
Distribution: usa
Date: Wed, 14 Oct 1992 17:51:40 GMT

In article <92Oct14.033708.24102@acs.ucalgary.ca> quigley@acs.ucalgary.ca (Martyn Thomas Quigley) writes:
>bh@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
>
>>                                                The original problem is to
>>compute n! and instead of getting CLOSER to the solution by computing (n-1)!
>>you get FARTHER AWAY by computing x*n! instead.  This turns out to be helpful
>>but it's a total rabbit-from-hat.
>
>I've never been comfortable with this, but for a different reason.  Children
>invariably start from 1 and work up, they simply do not start from n and
>work down.  Ask them.
>
>Martyn

Not true. Our daughter Sierra originated the following dialog at about age 3,
roughly one month after learning to spell her name:

Mother:	"What's your name?"
Daughter: "Sierra."
Mother: "Oh, Sarah!"
Daughter: "No, SIERRA!!!"
Mother: "How do you spell that?"
Daughter: "S-I-E-R-R-A. Sierra. When I ask you if you think I can spell that
	backwards, you say no. Do you think I can spell that backwards?"
Mother: "No."
Daughter: "A-R-R-E-I-S"

I remember this dialog so well because we repeated it dozens of times
before she got tired of it. She came up with the idea itself. Also the idea
of counting 10-9-8-7-6-5-4-3-2-1-0, followed by liftoff or explosions or
some other loud and usually catastrophic event, seems to resonate with the
kids. Counting backwards subtrahend steps from a minuend to a difference
also seems to be working fine for learning subtraction. Her first crack
at subtraction was counting off the number of screws left to put in her
brother's foot braces at bedtime (thank God that's over). I'll agree that
spelling the name forward and counting forward came first, but of course
that's how they were presented.  If the kids have a good physical model for
a computational process, they'll use the process.

Dale Parson, Bell Labs, dale@mhcnet.att.com

 ---------------------------------------------------------------------- 
|    "These words are too solid, they don't move fast enough           |
|     to catch the blur in the brain that flies by, and is gone..."    |
 ----------------------------------------------------------------------
|     Suzanne Vega                                                     |
 ----------------------------------------------------------------------
Newsgroups: comp.lang.logo
Subject: Re: um, maybe this is a silly question
From: max@Kolmogorov.gac.edu (Max Hailperin)
Date: 13 Oct 92 10:30:00
Reply-To: Max Hailperin <max@nic.gac.edu>
 <1ba7vcINNpam@agate.berkeley.edu><1992Oct12.163421.24051@sctc.com> <1bcfa5INN4bs@agate.berkeley.edu>
Distribution: usa
Organization: Gustavus Adolphus College, St. Peter, MN
In-reply-to: bh@anarres.CS.Berkeley.EDU's message of 12 Oct 1992 18:14:29 GMTLines: 45

In article <1bcfa5INN4bs@agate.berkeley.edu>
 bh@anarres.CS.Berkeley.EDU (Brian Harvey) writes:

   I do agree with the part of the message that says that programmers have
   to be trained to learn to think recursively.  That's why colleges should
   use Abelson and Sussman as their intro programming course, and high
   schools should use Logo!  :-)

I find it mildly odd that you suggest a textbook for colleges, a
language for high schools.  Of course, since I know you favor the
"enlightened playing around" approach to "providing a context for
learning" (as opposed to "teaching"), the environment/language is
playing somewhat of the same role as a textbook.

Still, let me suggest an alternative language that merits serious
consideration for the high school level, and complete the parallelism
by suggesting a high school level textbook for it.  The language: also
scheme, the same as for the college level.  The text: The Schemer's
Guid, by Iain Ferguson, with Edward  Martin and Burt Kaufman.

Back to the original thread, I pointed out offline that the key
distinction in learning isn' between recursive and iterative but
between faith and tracing out in your head.  The big problem with the
way most people learn iteration is that they think about it in the
trace-it-out style, by looping around and around until done.  But,
then again, the same mind-bug affects recursion as well -- these
self-same learners typically wind up trying to chase down all the
branches of a recursion tree to the leaves in their heads too.  The
right approach in either case is to take on faith that a procedure
(even the one you are writing) does what it claims to.  So, the way
you think about recursive factorial is by assuming that the factorial
procedure applied to n-1 really does compute (n-1)! and therefore
concluding that n times that will be n!.  Equally well for iteration,
you assume on faith that the procedure fact.help meets its spec that
(fact.helper :n :x) computes n! * x.  Therefore, in the body of
fact.helper, when it does
  fact.helper (:n - 1) (:n * :x)
you can just take on inductive faith that this is computing the
factorial of its first argument times the second argument, i.e.
(n-1)!*(n*x), which by a little juggling equals n!*x as desired.
The real problem is trying to trace it all through instead of having
faith (of the inductive variety).

[Pardon any logo syntax errors, it's been a long time since I did
logo.]
Newsgroups: comp.lang.logo
From: liberte@cs.uiuc.edu (Daniel LaLiberte)
Subject: Re: um, maybe this is a silly question
Organization: University of Illinois, Urbana-Champaign, Dept CS
	<1bhp38INN2qv@agate.berkeley.edu>
	<1992Oct15.165322.682@Csli.Stanford.EDU>
	<1bkbruINNf4r@agate.berkeley.edu>
Distribution: usa
Date: Fri, 16 Oct 1992 19:00:46 GMT

   From: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
   My concern is that the whole idea of curriculum gets in the way of 
   learning.  

While there are certainly bad curriculums and bad implementations of
them, this should not rule out the possibility of a good
implementation of a good curriculum.  In other words, a curriculum
does not necessarily get in the way of learning, though it often may.

I think that the idea of "imposing" a curriculum on students is
reflects the wrong attitude.  Rather, there should be incentives and
challenges to channel the natural energy of students in the direction
towards the curriculm goals.

   If a teacher walks into class with the idea that today everyone is going to
   learn the TTTT, that doesn't feel very "Logo-like" to me.  

But it could be done in a Logo-like fashion if the students were led
(in such a way that they didn't know they were being led) to discover
the TTTT themselves.  Giving kids Logo by itself may be sufficient for
some, but others might needs some occasional hints to move them in the
"right" direction.

   Max's argument that it isn't really so hard.  But for the sake of argument,
   let's suppose we think it is hard.)

Hard things can be made simple, and simple things can be made hard.
But once solved, most problems appear simple.  So it seems obvious to
me that the way to teach is to make things appear as simple as they
are.  This may require first developing a simple framework from which
more complex things can be simply built.

   At one point I asked about kids hanging out in the lab after school,
   and the teacher proudly (!!) replied that no, kids used to hang out in
   the lab, but since they started teaching Computer Science the kids
   have learned that programming is unimportant in itself and merely a
   means to the end of learning Computer Science.  Gack!

Double Gack!!  This teacher's attitude is deplorable and I hope it is
not too wide spread.  If it is, that might partly explain the
deplorable state of our education system.  All the things I really
learned (and remember) I learned on my own because it was fun.

Dan LaLiberte
liberte@cs.uiuc.edu
(Join the League for Programming Freedom: league@prep.ai.mit.edu)
"If we don't succeed, we run the risk of failure.
		-- Vice President Dan Quayle."
From: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
Newsgroups: comp.lang.logo
Subject: Re: um, maybe this is a silly question
Date: 9 Oct 1992 14:20:53 GMT
Organization: University of California, Berkeley
Distribution: usa
NNTP-Posting-Host: anarres.cs.berkeley.edu

The answer
		make "x 12
is correct but really only answers part of the question.

In languages like BASIC and C, there is a heavy emphasis on the style of
programming in which instructions are executed in sequence, and most of
those instructions change the values of variables.  (In BASIC this is
because the language is not capable of any alternative; in C, it's because
the can't-teach-an-old-dog programmers aren't.)

In Logo it's not very common to use MAKE at all, or to change the value
of a variable in any other way.  Instead, Logo emphasizes functional
programming, in which the computation progresses when a function calls
another function.  (The function can call itself; that's recursion, which
Logo uses instead of conventional looping structures like WHILE.)

Example: Euclid's GCD algorithm, both ways:

------------------------------ C ------------------------------

int gcd(int a, int b)
{
    while (b != 0) {
	int temp = b;
	b = a % b;
	a = temp;
    }
    return a;
}

------------------------------ Logo ------------------------------

to gcd :a :b
if :b = 0 [output :a]
output gcd :b (remainder :a :b)
end

======================================================================

The point to notice is the complete absence of assignment instructions
in the Logo (recursive) version.  (Also, along with that, there's no
need for the extra variable temp.)  It would be possible to write it
the same way in C, but most C programmers wouldn't.

I hope I'm not insulting you by telling you things you knew already;
the original message didn't make that clear.
Newsgroups: comp.lang.logo
From: omitchel@jarthur.claremont.edu (Ocie *crow* Mitchell)
Subject: um, maybe this is a silly question
Organization: Harvey Mudd College, Claremont, CA 91711
Distribution: usa
Date: Fri, 9 Oct 1992 06:57:08 GMT

I was playing around with logo and I was wondering, how do you set the 
value/type of a variable?

[BASIC] x=10
[C] int x=10
[Logo] ?...

----------------------------------------------+-------------------------------
``What do you think sirs?''  -Joel (mst3k)    | do not write above this line
----------------------------------------------+------------------------------- 
   __             _ _ _                       | Ocie Mitchell
  / ')           ' ) ) )  _/_    /      /) /) | omitchel@jarthur.claremont.edu
 /  / _. o _      / / / o /  _. /_  _  // //  | Q:is that your real name? 
(__/ (__(_(<_    / ' (_(_(__(__/ /_(<_(/_(/_  | A:yes, it is my real name.
----------------------------------------------+-------------------------------