Path: utzoo!attcan!uunet!husc6!rutgers!aramis.rutgers.edu!porthos.rutgers.edu!webber From: webber@porthos.rutgers.edu (Bob Webber) Newsgroups: comp.misc Subject: Re: Basics of Program Design Message-ID: Date: 2 Jul 88 08:26:00 GMT References: <901@td2cad.intel.com> <3061@rpp386.UUCP> <395@proxftl.UUCP> Distribution: na Organization: Rutgers Univ., New Brunswick, N.J. Lines: 40 In article <395@proxftl.UUCP>, bill@proxftl.UUCP (T. William Wells) writes: > In article , webber@aramis.rutgers.edu (Bob Webber) writes: > > > [recursive strlen which you should all be familiar with by now] > > > 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? Nope. There is more to it than just tail recursion, but tail recursion is an essential part of the optimization. > In the real world, most compilers do NOT deal with tail recursion, ^^^^^^^^^^ -- what makes you think your world is real? > it not often being very useful to do this for C programs. Well, there is a free, high quality C compiler for 68000-based systems and various others that does do tail recurision (i.e., gcc) among other things. [However, it wouldn't catch this particular case -- perhaps that is why you aren't using it? ] Optimizations fall into two categories: those that handle the poor fit between language and architecture and those that save programmer time. While for a language like SCHEME, this would be viewed as a language-related optimization, in a language like C it falls in the second category. > 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. Yes, you have learned the first lesson. Let me introduce you to the second lesson: Not all code is executed the same amount of time. Thus it is more important for some things to be fast than it is for others. Strlen does not make sense as a function to be optimizing the death out of. After all, if it is used all that much -- why isn't it a macro? ------ BOB (webber@athos.rutgers.edu ; rutgers!athos.rugters.edu!webber)