A tool that suggests optimized logic for a piece ofcode/module/function

[Richard Tobin]

I don't agree here (perhaps as a compiler writer you are thinking of
"implementation" in terms of generated target code - then I'd agree).
Kids use Logo to learn about programming concepts, and how to get the
computer to do what you want it to do. They learn to write things like:

TO SQUARE :size
REPEAT 4 [ FD :size RT 90 ]
END

This is entirely about writing an imperative implementation of how you
want the system to draw a square.

Well that *is* the natural way to draw a square with a turtle.
But another typical, slightly more advanced, Logo problem is to
draw fractal-like patterns, using recursion.

-- Richard

 

[karthikbalaguru]

The same thing applies to the original question.  If a compiler's
full-blown optimizer, given practically infinite time to ponder the
problem, can't get that analysis job done, then no other tool can, and
certainly not while just looking over the programmers' shoulders as they
type.

I think, the tool
should be trained to develop tiny
logics by giving tiny infos to it.
I think, the tool should also be
trained to develop its own
self decision capabilities by
giving lot of small tasks that might
require tiny decisions initially.
The above should make it
robust in finding alternate logic.
Maybe, it can also bank on the
reliable sources on internet or
other servers to get more info
incase it runs out of steam. But
i think, it is better to avoid some
internet dependencies as
sometimes we might need to
use a PC that is not connected
to internet !

Thx in advans,
Karthik Balaguru

 

[Måns Rullgård]

I think, the tool should be trained to develop tiny logics by giving
tiny infos to it. I think, the tool should also be trained to
develop its own self decision capabilities by giving lot of small
tasks that might require tiny decisions initially. The above should
make it robust in finding alternate logic. Maybe, it can also bank
on the reliable sources on internet or other servers to get more
info incase it runs out of steam. But i think, it is better to avoid
some internet dependencies as sometimes we might need to use a PC
that is not connected to internet !

There's a name for that: outsourced engineer.

 

[Lie Ryan]

I think, the tool
should be trained to develop tiny
logics by giving tiny infos to it.
I think, the tool should also be
trained to develop its own
self decision capabilities by
giving lot of small tasks that might
require tiny decisions initially.
The above should make it
robust in finding alternate logic.
Maybe, it can also bank on the
reliable sources on internet or
other servers to get more info
incase it runs out of steam. But
i think, it is better to avoid some
internet dependencies as
sometimes we might need to
use a PC that is not connected
to internet !

I found a similar tool:
http://xkcd.com/416/

 

[Nick Keighley]

Why bother to compile it?  Just have it interpret on-the-fly.
That way you could even run it in interactive mode, and it's
sufficiently high-level that even non-programmers could usefully use
it.

Unix people call this a "shell".

I'm guessing you're trying to be funny/ironic. But in case you aren't,
Unix has dozens of stranglely incompatible Command Line Interfaces
that Unix people call "shells". None of them are word processors.

 

[dj3vande]

I'm guessing you're trying to be funny/ironic. But in case you aren't,
Unix has dozens of stranglely incompatible Command Line Interfaces
that Unix people call "shells". None of them are word processors.

Right.
But all of them have the property that I can get a word processor by
typing the name of a word processor that's installed on the system.


My point was that the "primitives" provided by a shell (the programs
installed on the system) give a pretty good approximation to
[Jongware]'s suggestion of "type 'word processor' and get a word
processor".


dave

 

[Andy]

I don't agree here (perhaps as a compiler writer you are thinking of
"implementation" in terms of generated target code - then I'd agree).
Kids use Logo to learn about programming concepts, and how to get the
computer to do what you want it to do.  They learn to write things like:

TO SQUARE :size
REPEAT 4 [ FD :size RT 90 ]
END

This is entirely about writing an imperative implementation of how you
want the system to draw a square.

Compare this to a sample program in a real functional programming
language, Haskell:

factorial 0 = 1
factorial n = n * factorial(n - 1)

Here you tell the system what you want - you give a mathematical
description of the results.  You don't care how it gets them - maybe it
uses recursion, maybe it uses iteration, maybe it builds up a cache of
calculated values as it goes along.

The LOGO interpreter/compiler is just as free to implement alternative
solutions to drawing a square as the Haskell compiler is of altering
the described recursive implementation of a factorial. Whether the
compiler is smart enough to do so has nothing to do with the language
being "procedural" or "functional".

Andy

 

[Jasen Betts]

I'm guessing you're trying to be funny/ironic. But in case you aren't,
Unix has dozens of stranglely incompatible Command Line Interfaces
that Unix people call "shells". None of them are word processors.

emacs comes close.



--- news://freenews.netfront.net/ - complaints: (e-mail address removed) ---

 

[Jon Kirwan]

This could be a first step based on available technology.
A simple automated system with compiler static metrics
reported in a test fixture that swaps function implementations
could provide automated evaluations of alternative
implementations that would provide useful although
incomplete results.

I addressed some thoughts of mine to this... in my earliler
response to Jim.

Separate out algorithmic changes from code optimization
and lets find out how much of this exercise is what the op
was looking for and how much is compiler optimization
weakness.

Do you remember the discussions? (I'm not sure.) If not,
I'd be happy to revisit the topic with you. However, I'd let
you be the judge about the separation. You are in a better
position to guide us on that topic. I can merely present the
topo change required, as I see it.

C compilers do many things that a human programmer
can't easily do by hand, RAM re-use, instruction scheduling,
complete re-implementation with every code change.

Never any doubt in my mind about that. Different subject,
entirely, to the idea of replacing bubble sort code with
stocked versions of quick sort, though, within the context of
the c language.

Our internal data shows that compiled code for last several
years is better than hand written code in size and execution
speed. The underlying reasons are the compiler is better at
control and data flow analysis and makes better use of the
whole instruction set.

There is a simple way that this can be evaluated. Modify the
code generator on an assembler to emit C with a direct translation
per asm statement. Compile the resulting C and compare to
the original assembler.

I was simply addressing myself to the line of reasoning from
Hans-Bernhard Bröker when he wrote:

"Nothing stops a compiler from completely
reorganizing a given function, as long as
it's written in such a way that all effects
to the outside are tightly scoped. I.e. a
compiler is already allowed to detected a
piece of code performs a sort and just call
qsort() instead."

Unless I'm just too sleepy to recognize something you are way
ahead of me on, right now, I'd like to suggest we are talking
at cross purposes.

Jon

 

[Jon Kirwan]

It has been pointed out that recognizing and replacing a bubble
sort with a quick sort may not always be in the best interest
of a given application. I don't agree that C compilers have the
right to argue with the application developer over their choice
implementation algorithm.

I guess I wondered where you were coming down.

The C language as defined by its standards gives compilers
a reasonable amount of freedom to translate applications
as written to the executable machine code. To give a
compiler the additional flexibility to select appropriate
application implementation algorithm at the function level
requires a language designed to describe application
objectives rather than implementation.

As I said, I was following the 'thread' of responses downward
from Hans-Bernhard Bröker's comment. I assumed (wrongly)
that you were addressing yourself along similar lines.

Regarding your assertion here about what a c compiler is
permitted to do and not, I'm not an expert on the subject. I
am merely "somewhat dangerous" and I will defer to your (and
those of others similarly experienced) opinion about it, for
now. You are in far better position than I am to speak to
this.

To illustrate this point. Your exact timing example is not a
C compiler limitation but a language limitation. How do
you describe exact timing all paths in a function in an
unambiguous way in C? Exact timing is an application
objective.

Of course it is. But if you've read the Bulldog thesis (and
I assume you have -- who hasn't who works on compilers? --
even I've read it thoroughly and enjoyed it and I'm merely a
hobbyist on the matter, if that much), you will see how those
kinds of "goals" (as well as other "clues") were provided a
suggested implementation (because it was _actually_
implemented.)

It's possible to extend c for embedded use here just as it
has always _been_ extended. Ad hoc methods. #pragma being a
somewhat "allowable" method among others.

....

I am now left wondering what you meant in the post I first
responded to. I'll have to go reread it again, taking into
account the new information here and see if I can see how it
fits with Mr. Bröker's comments, too.

Jon

 

[Rainer Weikusat]

I'm guessing you're trying to be funny/ironic. But in case you aren't,
Unix has dozens of stranglely incompatible Command Line Interfaces
that Unix people call "shells". None of them are word processors.

UNIX(*) has a single type of 'interactive command processor/ simple
scripting language' and its features are described by an IEEE
standard. You observation that lots of different people and
organizations have written application software for UNIX(*) and that
this different applications differ is nevertheless correct.

Pearls of wisdom ...

 

[Richard Tobin]

UNIX(*) has a single type of 'interactive command processor/ simple
scripting language' and its features are described by an IEEE
standard.

This is pedantry of the most pointless kind. You're welcome to
your "UNIX(*)", but don't pretend that your comments have anything
to do with the real world.

-- Richard

 

[David Brown]

This is pedantry of the most pointless kind. You're welcome to
your "UNIX(*)", but don't pretend that your comments have anything
to do with the real world.

Actually, his comment /does/ have a lot to do with the real world - it
was just very badly expressed. There is a posix standard for shells,
which gives a standard base for almost all shells in the *nix (Linux,
BSD, "real" unix, etc.) world. Most shells have features beyond the
posix base, and those are often incompatible, but if you stick to the
posix subset your scripts should work under any shell.

Of course, this is getting /way/ off topic for this thread...

 

[Boudewijn Dijkstra]

Op Fri, 15 Jan 2010 10:20:47 +0100 schreef Nick Keighley

I'm guessing you're trying to be funny/ironic.

I hope that was pretty obvious to most people.

But in case you aren't,
Unix has dozens of stranglely incompatible Command Line Interfaces
that Unix people call "shells". None of them are word processors.

Indeed. But you misunderstood. Read again.

 

[David Brown]

You changed the context. It wasn't scripts, it was interactive use.

The same actually applies for interactive use - you can stick to posix
for compatibility. But it is most relevant for scripts - when you are
using a shell interactively, you are more likely to know what shell you
are using, and more likely to use a powerful shell like bash. With
scripts, you more often want to be compatible with lots of different
shells, and thus use the common posix subset.

You're forgetting chsh, and the fact that not all shells are designed
to be somewhat compatible with POSIX shell.

Yes, there are plenty of non-posix shells around. But the most commonly
used shells in *nix are at least fairly close to posix compatible.

Let's put it back on-topic:

chsh /usr/bin/emacs

Et voilà! Instant "word" processor shell...

Since emacs is also a shell, can't you do something like :

/usr/bin/emacs --execute="eshell /usr/bin/emacs"



Or "sh wordgrinder", which is (apparently) more of a real word processor.

<http://lightlinux.blogspot.com/2009/08/wordgrinder-word-processor-for-linux.html>

 

[Nick Keighley]

[Jongware] <[email protected]> wrote:

I'm guessing you're trying to be funny/ironic. But in case you aren't,
Unix has dozens of stranglely incompatible Command Line Interfaces
that Unix people call "shells". None of them are word processors.

Right.
But all of them have the property that I can get a word processor by
typing the name of a word processor that's installed on the system.

I thought you were claiming Unix uniquely had some sort of VHLL. Apart
from the weird embedded ones, don't *all* OSs have a way to run the
programs that are installed on them?

Wasn't jongware suggesting something even more magical? The VHLL that
can create appications that aren't stored on the machine?

My point was that the "primitives" provided by a shell (the programs
installed on the system) give a pretty good approximation to
[Jongware]'s suggestion of "type 'word processor' and get a word
processor".

 

[Lie Ryan]

Wasn't jongware suggesting something even more magical? The VHLL that
can create appications that aren't stored on the machine?

app-get, emerge, yum?

 

[Richard Bos]

I don't agree here (perhaps as a compiler writer you are thinking of
"implementation" in terms of generated target code - then I'd agree).
Kids use Logo to learn about programming concepts, and how to get the
computer to do what you want it to do. They learn to write things like:

TO SQUARE :size
REPEAT 4 [ FD :size RT 90 ]
END

This is entirely about writing an imperative implementation of how you
want the system to draw a square.

Well that *is* the natural way to draw a square with a turtle.
But another typical, slightly more advanced, Logo problem is to
draw fractal-like patterns, using recursion.

How does the possibility of recursion make a language functional? Even
C, which is about as imperative as they come, explicitly makes
allowances for recursion.

Richard

 

[Richard Bos]

I'm guessing you're trying to be funny/ironic. But in case you aren't,
Unix has dozens of stranglely incompatible Command Line Interfaces
that Unix people call "shells". None of them are word processors.

Right.
But all of them have the property that I can get a word processor by
typing the name of a word processor that's installed on the system.

My point was that the "primitives" provided by a shell (the programs
installed on the system) give a pretty good approximation to
[Jongware]'s suggestion of "type 'word processor' and get a word
processor".

That is an iffy comparison, because you need to install the word
processor separately from the shell before you can call it. In other
words, the programs you install are much more like third-party libraries
in a programming language, not like the primitives. In this respect, a
normal programming language like C is no different from a shell: from C,
you can also call the function process_words() - or if you wish,
system("wordprocessor");

Richard

 

[[Jongware]]

On 13 Jan, 16:43, (e-mail address removed) wrote:
Unix people call this a "shell".
I'm guessing you're trying to be funny/ironic. But in case you aren't,
Unix has dozens of stranglely incompatible Command Line Interfaces
that Unix people call "shells". None of them are word processors.

Right.
But all of them have the property that I can get a word processor by
typing the name of a word processor that's installed on the system.

My point was that the "primitives" provided by a shell (the programs
installed on the system) give a pretty good approximation to
[Jongware]'s suggestion of "type 'word processor' and get a word
processor".

That is an iffy comparison, because you need to install the word
processor separately from the shell before you can call it. In other
words, the programs you install are much more like third-party libraries
in a programming language, not like the primitives. In this respect, a
normal programming language like C is no different from a shell: from C,
you can also call the function process_words() - or if you wish,
system("wordprocessor");

It was a deliberate exaggeration, referring to the OP's idea: a compiler
sees someone struggling with an unsigned array of characters, save and
load routines, and display and edit stuff. On compiling, it simplifies
the entire program to "system("wordprocessor);"

Compilers can use clock cycle optimizations to speed up programs -- and
it optimizes *everything* -- where a human could eyeball it and speed up
an entire program by using a different algorithm for a single routine. I
can't see how counting clock cycles could do *that*!

Oh, apart from a genetic algorithm that simply tries out everything, or
a smarter compiler that *can* infer O(n) count from looking at code.

Perhaps it'll also understand "Tea -- Earl Grey, hot."

[Jw]