Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!umd5!uflorida!novavax!proxftl!bill
From: bill@proxftl.UUCP (T. William Wells)
Newsgroups: comp.misc
Subject: Re: Basics of Program Design
Summary: tail recursion?
Message-ID: <395@proxftl.UUCP>
Date: 30 Jun 88 18:35:24 GMT
References: <901@td2cad.intel.com> <3061@rpp386.UUCP> 
Distribution: na
Organization: Proximity Technology, Ft. Lauderdale
Lines: 33

In article , webber@aramis.rutgers.edu (Bob Webber) writes:
> In article <3061@rpp386.UUCP>, jfh@rpp386.UUCP (John F. Haugh II) writes:
> > strlen (s)
> > char        *s;
> > {
> >     if (*s)
> >             return (strlen (s + 1) + 1);
> >     else
> >             return (0);
> > }
> >
> > not such a smart move.  always consider the cost of your algorithm.
>
> A perfectly fine algorithm.  Any decent compiler would remove the tail
> recursion.

Ahhhh.  Last I heard, tail recursion implies a function call
immediately before a return.  This function has an add (or
increment) before the return.  Has the definition of tail
recursion changed?

Also, get REAL.  Merely asserting that "any decent compiler
would..." is not relevant.  This just asserts that YOU think that
a compiler that does not deal with tail recursion is not decent.
In the real world, most compilers do NOT deal with tail recursion,
it not often being very useful to do this for C programs.

A perfectly good algorithm can be a BAD choice in the real
world.  Yes, the algorithm is "good", which is to say, it works
and is of the best possible order, but it is poorer than the
standard implementation since its constant factor is going to be
larger.  What you learn in school are the tools of the trade,
what that unfortunate is running into is that school does not
teach how to select the right tool for the job.