Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ttrdc.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!mgnetp!ltuxa!ttrdc!levy
From: levy@ttrdc.UUCP (Daniel R. Levy)
Newsgroups: net.lang.c
Subject: Re: Lisp to C conversion
Message-ID: <628@ttrdc.UUCP>
Date: Sun, 8-Dec-85 01:57:42 EST
Article-I.D.: ttrdc.628
Posted: Sun Dec  8 01:57:42 1985
Date-Received: Mon, 9-Dec-85 03:43:34 EST
References: <391@bcsaic.UUCP> <10200028@ada-uts.UUCP>
Organization: AT&T, Computer Systems Division, Skokie, IL
Lines: 21

In article <10200028@ada-uts.UUCP>, richw@ada-uts.UUCP writes:
>"topaz!root"  says:
>Can you be more specific about "more optimization"?
>"Optimize" is a horrible word for "code-size/execution-time reduction".
>Did you ever consider that ALL programs which don't read any input
>(e.g. a program to calculate the first 1000 digits of pi) would be,
>theoretically, totally consumed by true "optimizing" compilers?
>That is, you tell the compiler to optimize your pi-calculating program
>and it spews out "3.14159..."
>
>-- Rich Wagner
That would be a marvel of "artificial intelligence" -- an optimizer that
can recognize algorithms.  Imagine--it would replace your bubble sorts
with Shell sorts (or better); linear searches would become binary or hashed;
all sorts of neat stuff.  The optimizer itself would crunch for long, long
periods of time; for "inputless" problems it might as well BE the task.  And
how well would this apply to a gargantuan problem like the current attempt to
calculate the mass of the proton from an entirely theoretical basis on a bevy
of high-powered IBM CPUs?  This is the kind of program where the data needed
could well be hardcoded in; I'd hate to wait for your "optimizer" to finish
with something of this kind!