Re: Prediction of local code modifications

Chris F Clark <cfc@shell01.TheWorld.com>
Sat, 05 Apr 2008 09:43:16 -0400

          From comp.compilers

Related articles
[10 earlier articles]
Re: Prediction of local code modifications gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-04-03)
Re: Prediction of local code modifications max@gustavus.edu (Max Hailperin) (2008-04-03)
Re: Prediction of local code modifications plfriko@yahoo.de (Tim Frink) (2008-04-03)
Re: Prediction of local code modifications find@my.address.elsewhere (Matthias Blume) (2008-04-04)
Re: Prediction of local code modifications gneuner2@comcast.net (George Neuner) (2008-04-04)
Re: Prediction of local code modifications cfc@shell01.TheWorld.com (Chris F Clark) (2008-04-04)
Re: Prediction of local code modifications cfc@shell01.TheWorld.com (Chris F Clark) (2008-04-05)
Re: Prediction of local code modifications mayan@bestweb.net (Mayan Moudgill) (2008-04-05)
Re: Prediction of local code modifications plfriko@yahoo.de (Tim Frink) (2008-04-08)
Re: Prediction of local code modifications gneuner@gis.net (gneuner) (2008-04-19)
| List of all articles for this month |

From: Chris F Clark <cfc@shell01.TheWorld.com>
Newsgroups: comp.compilers
Date: Sat, 05 Apr 2008 09:43:16 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 08-03-105 08-03-109 08-04-003 08-04-009 08-04-015
Keywords: optimize, theory
Posted-Date: 06 Apr 2008 01:18:23 EDT

Matthias Blume <find@my.address.elsewhere> writes:


> I think you are confusing dynamic programming with branch-and-bound
> methods. (What you are describing sounds more like branch-and-bound.)


I'm not sure what I have it confused with. However, having refreshed
my memory, I realize that I have at least one part of it completely
inverted, the need for backtracking. My incorrect recollection was
that it was used in the case where backtracking was required (and in
some sense described that need). However, it, of course, applies to
the opposite case, where one can memoize a value and thus not repeat
calculating it when needed again. From that fundamental flaw, all
else follows.


Sometimes we post to help, and sometimes to get helped. Not always
when we think we are.


Thanks,
-Chris


******************************************************************************
Chris Clark Internet: christopher.f.clark@compiler-resources.com
Compiler Resources, Inc. or: compres@world.std.com
23 Bailey Rd Web Site: http://world.std.com/~compres
Berlin, MA 01503 voice: (508) 435-5016
USA fax: (978) 838-0263 (24 hours)


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.