From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fc89c,97188312486d4578
X-Google-Attributes: gidfc89c,public
X-Google-Thread: 109fba,baaf5f793d03d420
X-Google-Attributes: gid109fba,public
X-Google-Thread: 1014db,6154de2e240de72a
X-Google-Attributes: gid1014db,public
X-Google-Thread: 103376,97188312486d4578
X-Google-Attributes: gid103376,public
From: miker3@ix.netcom.com (Mike Rubenstein)
Subject: Re: What's the best language to start with? [was: Re: Should I learn
 C or Pascal?]
Date: 1996/08/09
Message-ID: <320b35a2.43769707@nntp.ix.netcom.com>#1/1
X-Deja-AN: 173141419
references: <31FBC584.4188@ivic.qc.ca>
 <01bb83ad$29c3cfa0$87ee6fce@timpent.airshields.com>
 <4u89c4$p7p@solutions.solon.com>
 <01bb83f5$923391e0$87ee6fce@timpent.airshields.com>
 <4uah1k$b2o@solutions.solon.com>
 <01bb853b$ca4c8e00$87ee6fce@timpent.airshields.com>
organization: Netcom
x-netcom-date: Fri Aug 09  6:04:48 AM PDT 1996
newsgroups: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.lang.ada
Date: 1996-08-09T06:04:48-07:00
List-Id: <comp.lang.ada>


"Tim Behrendsen" <tim@airshields.com> wrote:

> 
> 
> Peter Seebach <seebs@solutions.solon.com> wrote in article
> <4uah1k$b2o@solutions.solon.com>...
> > In article <01bb83f5$923391e0$87ee6fce@timpent.airshields.com>,
> > Tim Behrendsen <tim@airshields.com> wrote:
> > >I agree; my point is that I think the student learns more if they
> > >are thinking purely in terms of fundamental operations (which are
> > >still abstractions above the raw hardware components), rather
> > >than layers and layers of syntax that hide the essential essence
> > >of what the computer is doing.
> > 
> > But your concept of what the "fundemental operations" are is completely
> tied
> > up in how specific hardware you've seen operates.  Algorithms exist in
> terms
> > of abstract operations, not moves and branches.
> 
> Please name me the hardware that does not use moves and branches.
> 
> > Something like CWEB might be a good language in which to learn
> algorithms.
> > Scheme might too.
> > 
> > Let's look at a specific algorithm; the infamous gcd(x, y).
> > 
> > In C, we write
> > 
> > 	int
> > 	gcd(int x, int y) {
> > 		if (y == 0)
> > 			return x;
> > 		return gcd(y, (x % y));
> > 	}
> > 
> > or something similar.
> > 
> > What's important here is not any theories people may have about where the
> x
> > and y are stored, or how a stack works, but the concept that you can
> define an
> > algorithm in terms of a previous case.  Learning that the if() may be
> > implemented with "a branch" does not help the student understand how the
> > *algorithm* works, it helps the student understand how the *compiler*
> works.
> > These are distinct things.
> 
> This is an interesting case, because it is somewhat inefficently
> implemented.  If you're interested in speed, you would do...
> 
> int gcd(int x, int y) {
>     int z;
>     while (y != 0)
>         z = y; y = x % y; x = z;
>     return(y);
> }

I don't understand how going into an infinite loop when y != 0
improves the speed?  I guess I cut class that day.

Nor do I see how dividing by 0 (when y == 0) is an improvement?
Perhaps I just cut too many classes.

Let's review the bidding.  Peter gives an algorithm.  You claim that
knowledge of assembly helps one understand it better and produce a
program that goes into an infinite loop if y is not zero and divides
by 0 if y is zero.

Perhaps you meant

	int gcd(int x, int y) {
	    int z;
	    while (y != 0)
	        { z = y; y = x % y; x = z; }
	    return(y);
	}

This avoids the infinite loop, but can be made even more efficient:

	int gcd(int x, int y)
	{
	  return 0;
	}

Of course this isn't quite equivalent to Peter's function.

I guess, like Peter, I'm a little thick today.  Please explain again
how knowing assembly language helps one understand algorithms?  I got
a little confused when you transformed Peter's correct, but slightly
inefficient function into an infinite loop.


Michael M Rubenstein