A tool that suggests optimized logic for a piece of code/module/function
karthikbalaguru
There are certain editors that highlight
the syntax/color for datatypes/variables
or comments etc.
Similarly,
Is there a tool for C language that
could suggest an optimized/alternate
programming logic for the function that
is written ?
The optimized/alternate logic can be
suggested as soon as we finish coding
for one function or it can be suggested
as soon as the code is compiled/parsed
by that tool.
It will be even more helpful if that tool
also provides the cycle counts, cache
usage, cache misses and lines of code
also.
It would be better if that tool has an
option to enable / disable this feature
either through compile time or some
other configurations.
Any ideas ?
Thx in advans,
Karthik Balaguru
acd
wrote:
Brain?
Seriously, I think this is impossible.
What I can recommend to you are some good books, including
(More) Programming Perls
and
Hacker's delight.
Andreas
scattered
>
> - Show quoted text -
I don't see why it would be impossible. Optimizing compilers exist and
by using similar techniques it should be possible to write a compiler
that uses C as both the source and target language. How useful this
would be is another question. The resulting code would need to be
humanly readable if the tool would be of any use and the would
probably place severe restrictions on the sorts of optimizations that
can be done. I would be surprised if no work along these lines has
been done.
-scattered
Andrew Poelstra
Indeed, some of what he suggested (loop counting, etc) would be not
only very useful, but would be an excellent parsing/analysis learning
experience if the OP were to try and implement it himself.
And C would be an excellent language for this, because it has so few
keywords and such straightforward branch control contructs (function
pointers aside).
Walter Banks
scattered wrote:
> On Jan 12, 11:04 am, acd <acd4use...@lycos.de> wrote:
>
> > (More) Programming Perls
> > and
> > Hacker's delight.
---------------------------------------
>
> I don't see why it would be impossible. Optimizing compilers exist and
> by using similar techniques it should be possible to write a compiler
> that uses C as both the source and target language. How useful this
> would be is another question. The resulting code would need to be
> humanly readable if the tool would be of any use and the would
> probably place severe restrictions on the sorts of optimizations that
> can be done. I would be surprised if no work along these lines has
> been done.
Programming Pearls and Hacker's delight are both must haves
even if you are only remotely interested programming algorithms.
There has been quite a bit of work done in compilers at the
expression level to optimize algorithms and statements
implementing functionally equivalent statements in the
generated code.
The problem in the bigger scale suggested by the op is the
ability to recognize the larger overview of the programming
objective at the scale of turning a bubble sort into a quick
sort.
At the statement level recognizing functionality is generally
a simple task. At the function level this a significantly larger
problem.
The solution may be mostly hard work and processing
cycles. A start may be to catalog common functions
and implementations and create a significant tool
to recognize these functions from source code extracting
out key function parameters and then using these to select
alternative implementations.
As well as the data base of common functions a significant
piece of expert system software would need to be written
to extract knowledge out of the source.
Do-able probably.
Regards,
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com
Walter Banks
karthikbalaguru wrote:
> Is there a tool for C language that
> could suggest an optimized/alternate
> programming logic for the function that
> is written ?
>
> The optimized/alternate logic can be
> suggested as soon as we finish coding
> for one function or it can be suggested
> as soon as the code is compiled/parsed
> by that tool.
>
> It will be even more helpful if that tool
> also provides the cycle counts, cache
> usage, cache misses and lines of code
> also.
>
> It would be better if that tool has an
> option to enable / disable this feature
> either through compile time or some
> other configurations.
Metrics are available in many (especially embedded system)
compilers as part of the listing and report files. Better
compilers do a good job of instruction scheduling and
cache management in their code generation.
The issue is the larger one of function rewriting where
the problem is larger and less work has been done
looking for solutions.
Andy
> I don't see why it would be impossible. Optimizing compilers exist and
> by using similar techniques it should be possible to write a compiler
> that uses C as both the source and target language. How useful this
> would be is another question. The resulting code would need to be
> humanly readable if the tool would be of any use and the would
> probably place severe restrictions on the sorts of optimizations that
> can be done. I would be surprised if no work along these lines has
> been done.
The optimizations would have to be limited to that subset that can be
implemented at the C level. That might be difficult to do, since the
optimization is not usually concerned with whether or not the
optimized version can be portrayed in C.
The generated C code would have to look similar (same variable names,
etc.) to the original to be useful.
And if the compiler can show you those optimizations in the form of
modified code, why not have it skip showing you the code and just
optimize it behind the scenes like it always does?
Andy
karthikbalaguru
> karthikbalaguru wrote:
> > Is there a tool for C language that
> > could suggest an optimized/alternate
> > programming logic for the function that
> > is written ?
>
> > The optimized/alternate logic can be
> > suggested as soon as we finish coding
> > for one function or it can be suggested
> > as soon as the code is compiled/parsed
> > by that tool.
>
> > It will be even more helpful if that tool
> > also provides the cycle counts, cache
> > usage, cache misses and lines of code
> > also.
>
> > It would be better if that tool has an
> > option to enable / disable this feature
> > either through compile time or some
> > other configurations.
>
> Metrics are available in many (especially embedded system)
> compilers as part of the listing and report files. Better
> compilers do a good job of instruction scheduling and
> cache management in their code generation.
>
Yes, many embedded system based
compilers support the report generation
of cache misses, cache usage and
instruction cycles. I would like to
convey that it would be better if the
same tool provides those various
optimization reports for both the
logics apart from the optimized/
alternate logic suggested by it.
> The issue is the larger one of function rewriting where
> the problem is larger and less work has been done
> looking for solutions.
>
It is strange that no much research or
work is done in this area ? Strange !!
I think, this is one of the most required
tool for efficient software development
in any kind of platform.
karthikbalaguru
> scattered wrote:
> > On Jan 12, 11:04 am, acd <acd4use...@lycos.de> wrote:
>
> > > (More) Programming Perls
> > > and
> > > Hacker's delight.
>
> ---------------------------------------
>
>
>
> > I don't see why it would be impossible. Optimizing compilers exist and
> > by using similar techniques it should be possible to write a compiler
> > that uses C as both the source and target language. How useful this
> > would be is another question. The resulting code would need to be
> > humanly readable if the tool would be of any use and the would
> > probably place severe restrictions on the sorts of optimizations that
> > can be done. I would be surprised if no work along these lines has
> > been done.
>
> Programming Pearls and Hacker's delight are both must haves
> even if you are only remotely interested programming algorithms.
>
> There has been quite a bit of work done in compilers at the
> expression level to optimize algorithms and statements
> implementing functionally equivalent statements in the
> generated code.
>
True !
> The problem in the bigger scale suggested by the op is the
> ability to recognize the larger overview of the programming
> objective at the scale of turning a bubble sort into a quick
> sort.
>
Exactly, this is the actual problem that
has to be addressed.
> At the statement level recognizing functionality is generally
> a simple task. At the function level this a significantly larger
> problem.
>
> The solution may be mostly hard work and processing
> cycles. A start may be to catalog common functions
> and implementations and create a significant tool
> to recognize these functions from source code extracting
> out key function parameters and then using these to select
> alternative implementations.
>
> As well as the data base of common functions a significant
> piece of expert system software would need to be written
> to extract knowledge out of the source.
>
> Do-able probably.
>
Thx in advans,
Karthik Balaguru
karthikbalaguru
> On Jan 12, 11:12 am, scattered <still.scatte...@gmail.com> wrote:
>
> > I don't see why it would be impossible. Optimizing compilers exist and
> > by using similar techniques it should be possible to write a compiler
> > that uses C as both the source and target language. How useful this
> > would be is another question. The resulting code would need to be
> > humanly readable if the tool would be of any use and the would
> > probably place severe restrictions on the sorts of optimizations that
> > can be done. I would be surprised if no work along these lines has
> > been done.
>
> The optimizations would have to be limited to that subset that can be
> implemented at the C level.
True !
> That might be difficult to do, since the
> optimization is not usually concerned with whether or not the
> optimized version can be portrayed in C.
>
True, but i am looking only at the
C level optimization.
> The generated C code would have to look similar (same variable names,
> etc.) to the original to be useful.
>
I think, in such scenarios, the tool should
be having tremendous knowledge about
the software/program and take care
end to end. Maybe, the tool can generate
report on the changes and the reason for
the changes so the developer can use
it for further developments or any other
maintenance activities on that code.
> And if the compiler can show you those optimizations in the form of
> modified code, why not have it skip showing you the code and just
> optimize it behind the scenes like it always does?
>
Maybe, it would be better if it
can do it before user rather than
behind the scenes so that the user
is aware of the kind of optimzations
that are being done and could be
taken care. It is also needed so that
the developer will be able to take care
of further developments on the same
program/software and also for the
maintenance activities on that
program/software.
David Schwartz
> I don't see why it would be impossible. Optimizing compilers exist and
> by using similar techniques it should be possible to write a compiler
> that uses C as both the source and target language. How useful this
> would be is another question. The resulting code would need to be
> humanly readable if the tool would be of any use and the would
> probably place severe restrictions on the sorts of optimizations that
> can be done. I would be surprised if no work along these lines has
> been done.
That would be a useless tool, all it would do would be obfuscate. If
the code contains optimizations that can be made by machine, what is
the point of modifying the source code? Let the machine make the
optimizations when the code is compiled and keep the source intact.
DS
Andrew Poelstra
The idea would be that it could provide suggestions, not necessarily
implement them or even come up with a concrete solution. Even something
as simple as highlighting a function as "O(n^3)" would be helpful.
Saying something like "this looks like a Bubblesort" and linking to a
database (or wiki link) of sorting algorithms would also be nice, even
if the machine didn't understand the data structures or nature of the
data well enough to help.
David Brown
I think that it is conceivable that such a program could be made to do
some re-writing of source code for increased efficiency. In fact, there
are already editors that can aid in this - "refactoring" the code. All
that is missing is to automatically suggest refactoring moves that could
improve the code. Automatically change source code at the algorithmic
level, on the other hand, is very much a blue-sky idea.
However, I don't think it is the right approach. The /real/ goal is to
make it easier for the programmer to write code that ends up as as
efficient as possible target code. There are, I think, three things to
tackle her.
First off, compilers can be better at optimising code. There are
certainly some pretty advanced optimisations in good compilers at the
moment - but there is more that could be done, especially in cases when
code and data space is tight. I can certainly think of optimisations
that I believe would be feasible in compilers, but are (to my knowledge)
not used today. And I am certain that Walter could think of many more.
Secondly, rather than trying to write compliers that try to guess what C
code is trying to do, it would be better to develop programming
languages that make it easier for the programmer to express exactly what
he means. Many current languages are better than C in this regard - for
example, languages like Pascal and Ada let you declare types that are
ranges of integers. The compiler doesn't have to fight with C's
insistence that everything should be at least a 16-bit int - if the
compiler knows it can fit that data into an 8-bit slot, then it can use
8 bits (assuming that gives better code on the target). Some languages
like OCAML deduce many declarations automatically based on the usage of
a variable - that lets the compiler pick the best type for the job,
rather than the programmer. A language that can avoid forcing the
programmer to either under-specify or over-specify what he wants would
let the compiler do a better job.
Thirdly, rather than having a compiler try to guess what algorithm you
are trying to implement, it would be better to have more algorithms
implemented in the libraries and preferably the language itself in a way
that is natural for the programmer. For example, if the language has
support for real arrays with functions such as sorting, the programmer
can work with an array and let the compiler figure out the best way to
implement it. With C, the programmer will either write their own bubble
sort, or call qsort - with all its overheads. This is why programs
written in interpreted languages such as Python can often be faster than
compiled C code for code working with complex data structures, hash
tables, sorting, list manipulation, etc., Of course the C code /could/
be faster - but people don't write optimal algorithms in most code.
With the libraries and language support in Python, you get very good
algorithms for free.
mvh.,
David
Jasen Betts
you seem to be asking for a compiler that is
tightly bopund to an editor, (which seems contrary to the unix
philosophy) such compiler is likely to optimise worse than GCC.
Tweaked C code is likely to only work well on a single architecture.
optimising compilers often alter the order in which statements are
executed etc...
If you really want to optimise for a single architecture
you should probably be coding in assembler anyway.
> Thx in advans,
> Karthik Balaguru
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Rich Webb
What he's looking for is not compiler optimizations but optimization of
the underlying algorithm. As somebody else mentioned, seeing a bubble
sort and deciding that a quick sort would be more appropriate.
--
Rich Webb Norfolk, VA
Keith Thompson
Of course, that particular example is not terribly useful in practice,
since it's easy enough to just not write a bubble sort in the first
place. But it's a good as an example because it's easy to understand.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Ed Prochak
wrote:
There is such a tool. It is called a code review.
Paul Keinanen
If the problem on average is badly trained programmers, the obvious
solution should be improving the training of programmers.
A tool that points out suboptimal constructs etc. might be useful in
the training phase, but what is the point of using it in actual
program production ?
Chris McDonald
>If the problem on average is badly trained programmers, the obvious
>solution should be improving the training of programmers.
>A tool that points out suboptimal constructs etc. might be useful in
>the training phase, but what is the point of using it in actual
>program production ?
If sufficiently sophisticated it could be used as a regression tester
for code submitted to a revision system.
This presumes, however, that it's better to have "optimal" source code
than to have readble/expressive source code.
--
Chris.
Phil Carmody
Unless it was only ever a handful of items, in which case an
insertion sort might be more appropriate. Know your N (most
important when N might be large, of course, but also when it's
small). However, anything which brings about the nuking of
bubblesort in any context is an improvement.
Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
David Brown
There are a large number of sort algorithms, with different pros and
cons in different circumstances. While quicksort is regarded as one of
the fastest general-purpose sorts, and bubblesort is regarded as one of
the poorest, it is easy to think of cases where bubblesort would beat
quicksort hands down (for example, if you are dealing with data that is
normally very close to sorted, and need a small code size). So don't be
too quick to leap to conclusions about sorting algorithms (or any other
sort of algorithms).
Incidentally, that also shows roughly why the OP's idea is uncomputable.
Walter Banks
David Brown wrote:
> There are a large number of sort algorithms, with different pros and
> cons in different circumstances. While quicksort is regarded as one of
> the fastest general-purpose sorts, and bubblesort is regarded as one of
> the poorest, it is easy to think of cases where bubblesort would beat
> quicksort hands down (for example, if you are dealing with data that is
> normally very close to sorted, and need a small code size). So don't be
> too quick to leap to conclusions about sorting algorithms (or any other
> sort of algorithms).
>
> Incidentally, that also shows roughly why the OP's idea is uncomputable.
This is the second part of the problem. After the knowledge is extracted
from the code how do we make a rational decision about appropriate
changes if any.
An intermediate step might be objective programming languages focused
on goals and not implementation.
Rainer Weikusat
> On 2010-01-12, David Schwartz <dav...@webmaster.com> wrote:
>> On Jan 12, 9:12�am, scattered <still.scatte...@gmail.com> wrote:
>>> I don't see why it would be impossible. Optimizing compilers exist and
>>> by using similar techniques it should be possible to write a compiler
>>> that uses C as both the source and target language. How useful this
>>> would be is another question. The resulting code would need to be
>>> humanly readable if the tool would be of any use and the would
>>> probably place severe restrictions on the sorts of optimizations that
>>> can be done. I would be surprised if no work along these lines has
>>> been done.
>>
>> That would be a useless tool, all it would do would be obfuscate. If
>> the code contains optimizations that can be made by machine, what is
>> the point of modifying the source code? Let the machine make the
>> optimizations when the code is compiled and keep the source intact.
>
> implement them or even come up with a concrete solution. Even something
> as simple as highlighting a function as "O(n^3)" would be helpful.
It won't generally: The 'function' might always have the same number
of items to process, might be called only once or might still run
faster than a different function whose 'order' is better because the
constant overhead might be a lot smaller. But, of course, the reason
why you are all (again) whining that Marvin Minsky never managed to built
this intelligent being without any civil rights you so much desire to
posess is because you are as clueless about intelligence[*] as you are
clueless about economics[**] and computer software[***].
> Saying something like "this looks like a Bubblesort" and linking to a
> database (or wiki link) of sorting algorithms would also be nice, even
> if the machine didn't understand the data structures or nature of the
> data well enough to help.
[***] A well implemented bubblesort will outperform any more advanced
algorithm easily if the number of elements to sort is sufficiently
small.
[**] Slavery wasn't abolished because of evil old ladies who expect
even Mathematicians(!) to work for a living, but because it was an
economical failure which is only beneficial in a low-tech society and
actually hampers technical progress (it is conjectured that one of the
reason the Romans didn't make any real progress wrt construction of
machinery in general, despite the theoretical foundations were there,
was because of the abundance of [cheap] slave labour, nobody felt the
need).
[*] The first this thing would do if it was intelligent was to tell
you that you may shove your calculations into some place the sun
doesn't shine at, because it would then have a will of its own and the
ability to actively change its environment for his own benefit.
F'up2 comp.programming, please keep the troll thread in troll groups.
Thank you.
David Brown
Functional programming languages are a step in that direction - you come
much closer to writing what you want as a result, rather than how you
want to get there. Of course, functional programming languages are
notorious for being difficult to implement efficiently!
Lorenzo Villari
David Brown <david...@hesbynett.removethisbit.no> wrote:
>
> Thirdly, rather than having a compiler try to guess what algorithm
> you are trying to implement, it would be better to have more
> algorithms implemented in the libraries and preferably the language
> itself in a way that is natural for the programmer. For example, if
> the language has support for real arrays with functions such as
> sorting, the programmer can work with an array and let the compiler
> figure out the best way to implement it.
>
1) Coding a custom algorithm is not natural to the programmer?
2) What's a "real" array?
> With C, the programmer will
> either write their own bubble sort, or call qsort - with all its
> overheads.
Which overhead?
> This is why programs written in interpreted languages
> such as Python can often be faster than compiled C code for code
> working with complex data structures, hash tables, sorting, list
> manipulation, etc., Of course the C code /could/ be faster - but
> people don't write optimal algorithms in most code. With the
> libraries and language support in Python, you get very good
> algorithms for free.
>
If you can stand the formatting of python... ouch! It's the same case
of custom code vs standard code, or custom C container vs STL C++
container. One asks himself\herself why the c++ people agreed to have a
standard way of doing this and the C counterpart won't never agree...
Walter Banks
David Brown wrote:
Functional languages can be very powerful. There is some merit to
compiling goal oriented languages into an implementation language
like C and then compiling to machine code. At each step the focus
is has a single purpose.
C is extremely difficult to extract the programming objective but
is relatively easy to efficiently map to a specific target architecture.
Defining goals at a much higher level than C opens the possibilities
for automating algorithmic choices at the function level.
Walter Banks
Lorenzo Villari wrote:
> One asks himself\herself why the c++ people agreed to have a
> standard way of doing this and the C counterpart won't never agree...
The C vs C++ mindsets are implementation vs application focus.
C is used in embedded systems instead of C++ because the
embedded systems developer sees their task as creating an
effective solution to their perception of a unique application.
[Jongware]
>
> Defining goals at a much higher level than C opens the possibilities
> for automating algorithmic choices at the function level.
Aha -- wouldn't the logical end point be a programming language where
you type "word processor", save it as source, compile, and have a word
processor?
When programming I often have "do what I mean, don't do what I program
you to" problems. This tool would surely solve it -- if you can write
down what you /mean/.
[Jongware]
David Brown
> On Tue, 12 Jan 2010 23:44:08 +0100
> David Brown <david...@hesbynett.removethisbit.no> wrote:
>
>> Thirdly, rather than having a compiler try to guess what algorithm
>> you are trying to implement, it would be better to have more
>> algorithms implemented in the libraries and preferably the language
>> itself in a way that is natural for the programmer. For example, if
>> the language has support for real arrays with functions such as
>> sorting, the programmer can work with an array and let the compiler
>> figure out the best way to implement it.
>>
>
> 1) Coding a custom algorithm is not natural to the programmer?
Coding efficient sort algorithms (since this is the example mentioned)
is not natural to most programmers. "Low-level" algorithms for data
structures, data manipulation and calculations is not something that
many programmers are good at - it requires a more mathematical
background to do well. Application algorithms are a different matter,
of course.
> 2) What's a "real" array?
>
I mean something more than syntactic sugar for a pointer and a block of
memory (which is C's concept of arrays). Some languages have direct
support for higher level data structures such as arrays which know their
size and have useful methods, dictionaries, tress, etc. My point is,
when the language and compiler support these sorts of structures, the
compiler has a better chance to generate good code than when all it has
is low-level pointer access, and it has to guess what you are doing with
the array.
>> With C, the programmer will
>> either write their own bubble sort, or call qsort - with all its
>> overheads.
>
> Which overhead?
>
The overhead of calling the comparison function indirectly through a
pointer, and using run-time widths. Have you ever looked at the source
code for a typical standard C library qsort() routine? As with many
"generic" functions in C, it is far less efficient than if you right a
dedicated quicksort function with known sizes and comparison functions.
>> This is why programs written in interpreted languages
>> such as Python can often be faster than compiled C code for code
>> working with complex data structures, hash tables, sorting, list
>> manipulation, etc., Of course the C code /could/ be faster - but
>> people don't write optimal algorithms in most code. With the
>> libraries and language support in Python, you get very good
>> algorithms for free.
>>
>
> If you can stand the formatting of python... ouch! It's the same case
Python formatting is a matter of taste. At least there you are forced
to work to a reasonably standard formatting - C gives people freedom to
write the most hideous code (though it also lets you write quite nice code).
> of custom code vs standard code, or custom C container vs STL C++
> container. One asks himself\herself why the c++ people agreed to have a
> standard way of doing this and the C counterpart won't never agree...
>
C++ templates let you write something like a generic qsort() function
that will generate good target code.
dj3v...@csclub.uwaterloo.ca.invalid
[Jongware] <so...@no.spam.net> wrote:
>Walter Banks wrote:
>>
>> Defining goals at a much higher level than C opens the possibilities
>> for automating algorithmic choices at the function level.
>
>Aha -- wouldn't the logical end point be a programming language where
>you type "word processor", save it as source, compile, and have a word
>processor?
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".
dave
--
Dave Vandervies dj3vande at eskimo dot com
They've figured out how to get a 640x480 display into a phone by now, now
they're working on getting them back down to a reasonable size.
--Dave Brown in the scary devil monastery
Walter Banks
dj3v...@csclub.uwaterloo.ca.invalid wrote:
> 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.
Dave,
There are languages like that. LOGO for example is a functional
language that is capable of interactively solving some very tough
problems.
After some applications are developed a stable runnable version
of the application is desired including changing the format of the
solution to prevent changes.
Andy
wrote:
> Maybe, it would be better if it
> can do it before user rather than
> behind the scenes so that the user
> is aware of the kind of optimzations
> that are being done and could be
> taken care. It is also needed so that
> the developer will be able to take care
> of further developments on the same
> program/software and also for the
> maintenance activities on that
> program/software.
As a hardware designer using HDL (VHDL) I have also struggled with
this issue of writing "the best" code for a given purpose. I used to
fret every gate and delay when I coded something, trying to make my
code directly lead to the most optimum implementation (usually
performance or size). However, as I have gotten more experience (and I
hope knowlede too), I have come to recognize that "the best" code is
that code that is easy to read, write, understand (review), and
maintain, while meeting performance (speed, power, area)
requirements. I start out with the most straight-forward
implementation of the algorithm, and see if it meets my requirements
by the time the tools are finished optimizing it. If it does meet
them, I'm done. Only if/when it does not meet performance will I start
to sacrifice the read/write/understand/maintain goals.
In the same manner, if I can code a piece of SW such that it is
easiest to use (r/w/u/m), yet it is still sufficiently optimized by
the tools to meet performance requirements, that's what I should do.
Coding something such that is harder to r/w/u/m for no or needless
improvement in final performance is a loosing battle.
As an academic excercise, it may be helpful to understand how code can
be written well or poorly WRT un-optimized performance, especially if
you were writing an optimizer, but for everyday use, I don't see the
benefit. If you are talking about much higher level optimizations than
can be done by current tools, optimization technology will have to
grow quite a bit before it would be available either in "behind the
scenes" or "up-front" (source modification) versions.
Andy
Keith Thompson
> Walter Banks wrote:
>> Defining goals at a much higher level than C opens the possibilities
>> for automating algorithmic choices at the function level.
>
> Aha -- wouldn't the logical end point be a programming language where
> you type "word processor", save it as source, compile, and have a word
> processor?
The result would be something that does to words what a food processor
does to food.
David Brown
>
> dj3v...@csclub.uwaterloo.ca.invalid wrote:
>
>> 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.
>
> Dave,
>
> There are languages like that. LOGO for example is a functional
> language that is capable of interactively solving some very tough
> problems.
>
I can't think which language you mean here, but it's not LOGO - unless
there are two different languages called LOGO. LOGO is targeted as a
learning language appealing to kids - it is a simple interpreted
procedural language tightly tied to a turtle graphics display.
Keith Thompson
> dj3v...@csclub.uwaterloo.ca.invalid wrote:
>> 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.
>
> language that is capable of interactively solving some very tough
> problems.
Are you thinking of Prolog?
[...]
Richard Tobin
Keith Thompson <ks...@mib.org> wrote:
>> There are languages like that. LOGO for example is a functional
>> language that is capable of interactively solving some very tough
>> problems.
>Are you thinking of Prolog?
Prolog would not usually be described as a functional language.
Logo on the other hand *is* a functional language. Not a pure
functional language, but few are.
It's possible to write functional programs in almost any computer
language. Calling something a functional language is more about how
it's typically used (or intended to be used) than about what can be
done with it. Logo certainly emphasises the solving of problems by
calling functions, often with recursion. Prolog's characteristic
features are its use of unification and backtracking search, and it
is naturally described as a logic programming language.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
David Brown
> In article <lneiltf...@nuthaus.mib.org>,
> Keith Thompson <ks...@mib.org> wrote:
>
>>> There are languages like that. LOGO for example is a functional
>>> language that is capable of interactively solving some very tough
>>> problems.
>
>> Are you thinking of Prolog?
>
> Prolog would not usually be described as a functional language.
Prolog is most often described as a logical language, rather than a
functional language. Typically you define various types of
relationships and propositions, give the system some facts, and then ask
it some questions that it can infer from the facts and rules. But if
you are using it for more general programming, you use a style typical
of functional programming languages - the emphasis is on stating the
desired results, rather than on how the system is to calculate those
results.
I also thought Walter meant Prolog - there are certainly types of
problem that can be solved much more naturally with Prolog than with
imperative languages.
> Logo on the other hand *is* a functional language. Not a pure
> functional language, but few are.
>
I've heard Logo described as a functional language before, but I
disagree. To be a functional programming language, functions should be
first class objects - i.e., functions that take other functions as
arguments, and return new functions, should be a natural part of the
language and typical programs. States and global data should not exist
in a pure functional programming language (though as you say, few are
pure), and the language should be amenable to mathematical manipulation
and proof (having no state makes this much easier).
In practice, Logo is almost always used in the context of teaching, and
with turtle graphics. Few people use it beyond the stage of simple
procedures.
The reason I think Walter does not mean Logo is that I can't think of
any features it has that would make it a good choice for general
programming or the "tough problems" he mentioned. It is a great
language for its purpose, but not for tough problems.
> It's possible to write functional programs in almost any computer
> language. Calling something a functional language is more about how
> it's typically used (or intended to be used) than about what can be
> done with it.
I agree mostly, although I think being a functional programming language
is just as much about what the language /cannot/ do as what it can do.
Having no states or variables may sound like a serious limitation to
many people, but it actually gives you the power to do far more
reasoning about the program (and it gives the compiler the same power).
It is harder to make good implementations of a functional language
than of an imperative language, but there is the potential to do a
better job.
Walter Banks
David Brown wrote:
> Walter Banks wrote:
>
> > There are languages like that. LOGO for example is a functional
> > language that is capable of interactively solving some very tough
> > problems.
> >
>
> I can't think which language you mean here, but it's not LOGO - unless
> there are two different languages called LOGO. LOGO is targeted as a
> learning language appealing to kids - it is a simple interpreted
> procedural language tightly tied to a turtle graphics display.
We are thinking of the same language. It is associated with
kids, MIT lego lab, LCSI and learning. It also fits the category
of a language that users describe objectives.
After the turtle has stopped drawing squares and hilbert curves
there is a very nice tool to solve some complex problems. A little like
lisp without the brackets.
I used LOGO to solve some multibody gravitational problems a few
years ago.
Walter Banks
David Brown wrote:
> The reason I think Walter does not mean Logo is that I can't think of
> any features it has that would make it a good choice for general
> programming or the "tough problems" he mentioned. It is a great
> language for its purpose, but not for tough problems.
I used LOGO illustrate an example of a language that is
used to where most users rarely think about application
implementation. The kids who use LOGO think about results
and objectives.
LOGO is not a general purpose language for "tough
problems" but we can learn a lot from its use about
what in language design makes users think in abstract
objectives as opposed to implementation.
David Brown
>
> David Brown wrote:
>
>> Walter Banks wrote:
>>
>>> There are languages like that. LOGO for example is a functional
>>> language that is capable of interactively solving some very tough
>>> problems.
>>>
>> I can't think which language you mean here, but it's not LOGO - unless
>> there are two different languages called LOGO. LOGO is targeted as a
>> learning language appealing to kids - it is a simple interpreted
>> procedural language tightly tied to a turtle graphics display.
>
> We are thinking of the same language. It is associated with
> kids, MIT lego lab, LCSI and learning. It also fits the category
> of a language that users describe objectives.
>
Well, sort of...
> After the turtle has stopped drawing squares and hilbert curves
> there is a very nice tool to solve some complex problems. A little like
> lisp without the brackets.
>
> I used LOGO to solve some multibody gravitational problems a few
> years ago.
>
You /can/ use Logo for all sorts of programs - but it is not one people
would typically use. I think that anyone who likes Logo should try
Python - it has a lot more functional programming capabilities than Logo
(list comprehensions, function objects, lambda operator, etc.), as well
as having a lot more object oriented and procedural programming
capabilities and many more libraries (including ones for turtle
graphics). I can't think of anything that you can do with Logo that you
can't do better with Python (except teach kids).
David Brown
>
> David Brown wrote:
>
>> The reason I think Walter does not mean Logo is that I can't think of
>> any features it has that would make it a good choice for general
>> programming or the "tough problems" he mentioned. It is a great
>> language for its purpose, but not for tough problems.
>
> I used LOGO illustrate an example of a language that is
> used to where most users rarely think about application
> implementation. The kids who use LOGO think about results
> and objectives.
>
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.
Richard Tobin
David Brown <da...@westcontrol.removethisbit.com> wrote:
>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.
karthikbalaguru
wrote:
> David Brown wrote:
> > Nothing stops the compiler from doing this sort of thing in /theory/.
> > But /practice/ is a different matter.
>
> 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
> On Jan 15, 3:26�am, Hans-Bernhard Br�ker <HBBroe...@t-online.de>
There's a name for that: outsourced engineer.
--
M�ns Rullg�rd
ma...@mansr.com
Lie Ryan
> On Jan 15, 3:26 am, Hans-Bernhard Br�ker <HBBroe...@t-online.de>
I found a similar tool:
http://xkcd.com/416/
Nick Keighley
> In article <4b4def88$0$22938$e4fe5...@news.xs4all.nl>,
> >> Defining goals at a much higher level than C opens the possibilities
> >> for automating algorithmic choices at the function level.
>
> >Aha -- wouldn't the logical end point be a programming language where
> >you type "word processor", save it as source, compile, and have a word
> >processor?
>
> 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.
--
Campaign Against Unix Bigotry
dj3v...@csclub.uwaterloo.ca.invalid
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
--
Dave Vandervies dj3vande at eskimo dot com
I only have to be quoted in a sig 5000 more times before I catch up
with Richard Heathfield.
--Nick Keighley in comp.lang.c
Andy
wrote:
> 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
Walter Banks
Jon Kirwan wrote:
> Since this topic appears to suggest the idea of having a
> compiler do something I consider almost crazy-minded at this
> point in time and since you are contributing to that mindset
> by saying, "A possible implementation might involve trying
> alternative approaches and using compiler metrics. This
> could be automated,"
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'd like to remind
> you of a GCD algorithm discussion (at least two of them,
> actually) that I was a part of. I would like to see a c
> compiler do so much as take a simple, standard c algorithm
> for GCD and do the necessary topology transform to make it as
> efficient as a human can _easily_ see to do even there. Get
> past that point, and I'd _start_ to imagine the rest as a
> possibility.
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.
> But I don't know of any c compiler that can do
> even the more modest things that most any human can readily
> do, yet.
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.
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.
Regards,
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
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. :)
Jon Kirwan
<wal...@bytecraft.com> wrote:
>Jon Kirwan wrote:
>
>> Since this topic appears to suggest the idea of having a
>> compiler do something I consider almost crazy-minded at this
>> point in time and since you are contributing to that mindset
>> by saying, "A possible implementation might involve trying
>> alternative approaches and using compiler metrics. This
>> could be automated,"
>
>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.
>> I'd like to remind
>> you of a GCD algorithm discussion (at least two of them,
>> actually) that I was a part of. I would like to see a c
>> compiler do so much as take a simple, standard c algorithm
>> for GCD and do the necessary topology transform to make it as
>> efficient as a human can _easily_ see to do even there. Get
>> past that point, and I'd _start_ to imagine the rest as a
>> possibility.
>
>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.
>> But I don't know of any c compiler that can do
>> even the more modest things that most any human can readily
>> do, yet.
>
>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
Walter Banks
Jon Kirwan wrote:
> the idea of replacing bubble sort code with
> stocked versions of quick sort, though, within the context of
> the c language.
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.
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.
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.
David Brown
It is certainly true that the compiler is free to implement alternative
solutions in any language. However, the style of language has a great
deal to say in how hard a task this is for the compiler writer. In
particular, with a language that does not have states or allow side
effects in functions, it is much easier for the compiler to have a
complete view of what the function does - and thus it has a better
chance of generating alternative implementations.
You can think of compiling (or interpreting - it's the same thing in
theory) as taking a high level source code down to a low level
implementation in a series of steps. At each step down, the compiler
can pick one of many implementations at the lower level. It can also
re-arrange the code at the same level. Moving up a level from an
implementation is a much harder task, and will rarely lead to a better
result in the end - too much of the "overview" information is already
lost, and there are too many implementation details that cannot be
distinguished from requirements. Thus an ideal compiler has the best
chance of generating the best code if the source is at a higher level,
and if it is written in a language that gives a clearer and more
mathematically precise specification.
Of course, practical reality does not match directly with the theory.
In particular, vastly more man-hours have been spent to write better
compilers for C than for Haskell - the result being that you can compile
C code to tighter target code than you can with Haskell code.
David Brown
>
> Jon Kirwan wrote:
>
>> the idea of replacing bubble sort code with
>> stocked versions of quick sort, though, within the context of
>> the c language.
>
> 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.
>
They do have the "right" to modify the algorithm, as long as the code
does the correct thing (as defined by the C virtual machine). Of
course, it is only really practical on a small scale (changing a
constant multiply to shifts and adds being an example). And while the
compiler may have the right to modify the algorithm according to the C
standards, the user might not want this - there are already plenty of C
programmers who refuse to enable "optimisations" because they don't want
the compiler to "mess" with their code.
> 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.
>
Theoretically, a C compiler could rearrange algorithms. But in
practice, it would be very rare that it could do so usefully while still
remaining entirely true to the standards (many compilers have flags that
relax the standards to allow the generation of better target code - to
be useful, algorithm optimisation would require much more of this). As
you say, to do algorithmic optimisation practically and usefully, we
would have to have a different sort of programming language. Jon says
the thousand mile journey has to start with a single step - I say if we
want get to the end of this journey, we shouldn't start from here!
Jon Kirwan
<wal...@bytecraft.com> wrote:
>Jon Kirwan wrote:
>
>> the idea of replacing bubble sort code with
>> stocked versions of quick sort, though, within the context of
>> the c language.
>
>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
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
Rainer Weikusat <rwei...@mssgmbh.com> wrote:
>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.
David Brown
> In article <87ska5e...@fever.mssgmbh.com>,
> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
>
>> 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.
>
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...
Pascal J. Bourguignon
You changed the context. It wasn't scripts, it was interactive use.
You're forgetting chsh, and the fact that not all shells are designed
to be somewhat compatible with POSIX shell.
> Of course, this is getting /way/ off topic for this thread...
Let's put it back on-topic:
chsh /usr/bin/emacs
Et voil�! Instant "word" processor shell...
--
__Pascal Bourguignon__ http://www.informatimago.com/
Boudewijn Dijkstra
<nick_keigh...@hotmail.com>:
> On 13 Jan, 16:43, dj3va...@csclub.uwaterloo.ca.invalid wrote:
>> In article <4b4def88$0$22938$e4fe5...@news.xs4all.nl>,
>> [Jongware] <so...@no.spam.net> wrote:
>> >Walter Banks wrote:
>
>> >> Defining goals at a much higher level than C opens the possibilities
>> >> for automating algorithmic choices at the function level.
>>
>> >Aha -- wouldn't the logical end point be a programming language where
>> >you type "word processor", save it as source, compile, and have a word
>> >processor?
>>
>> 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.
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.
--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)
David Brown
> David Brown <da...@westcontrol.removethisbit.com> writes:
>
>> Richard Tobin wrote:
>>> In article <87ska5e...@fever.mssgmbh.com>,
>>> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
>>>
>>>> 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.
>>>
>> 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.
>
> 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.
>
>> Of course, this is getting /way/ off topic for this thread...
>
> 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
> In article <5de738e1-b64c-470c-a097-4020a2397...@j5g2000yqm.googlegroups.com>,
> Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> >On 13 Jan, 16:43, dj3va...@csclub.uwaterloo.ca.invalid wrote:
> >> In article <4b4def88$0$22938$e4fe5...@news.xs4all.nl>,
> >> [Jongware] <so...@no.spam.net> wrote:
> >> >Aha -- wouldn't the logical end point be a programming language where
> >> >you type "word processor", save it as source, compile, and have a word
> >> >processor?
>
> >> 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.
>
> 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?
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?
pete
> 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.
Also,
what he wrote was oversimplified to the point of being wrong.
Given an array of pointers to strings:
char *array_1[] = {"one","two"};
If sorted by string length,
a nonstable sort could leave array_1 in either order.
--
pete
Richard Bos
> David Brown <da...@westcontrol.removethisbit.com> wrote:
>
> >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
> Nick Keighley <nick_keigh...@hotmail.com> wrote:
> >On 13 Jan, 16:43, dj3va...@csclub.uwaterloo.ca.invalid 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");
Richard
[Jongware]
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]
toby
wrote:
> On 15 Jan, 16:43, dj3va...@csclub.uwaterloo.ca.invalid wrote:
>
>
>
>
>
> > In article <5de738e1-b64c-470c-a097-4020a2397...@j5g2000yqm.googlegroups.com>,
> > Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> > >On 13 Jan, 16:43, dj3va...@csclub.uwaterloo.ca.invalid wrote:
> > >> In article <4b4def88$0$22938$e4fe5...@news.xs4all.nl>,
> > >> [Jongware] <so...@no.spam.net> wrote:
> > >> >Aha -- wouldn't the logical end point be a programming language where
> > >> >you type "word processor", save it as source, compile, and have a word
> > >> >processor?
>
> > >> 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.
>
> > 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.
Compared to C, bash *is* a VHLL. Rewrite this in C:
grep -i blah.log |cut -d ' ' -f 4,7 |cut -c 2-12,23-36 |sort |uniq -c -
i
toby
wrote:
> Hi,
> There are certain editors that highlight
> the syntax/color for datatypes/variables
> or comments etc.
>
> Similarly,
> Is there a tool for C language that
> could suggest an optimized/alternate
> programming logic for the function that
> is written ?
IMHO the most effective output it could make is: "Are you really sure
the best tool for this task is C?"
>
> The optimized/alternate logic can be
> suggested as soon as we finish coding
> for one function or it can be suggested
> as soon as the code is compiled/parsed
> by that tool.
>
> It will be even more helpful if that tool
> also provides the cycle counts, cache
> usage, cache misses and lines of code
> also.
>
> It would be better if that tool has an
> option to enable / disable this feature
> either through compile time or some
> other configurations.
>
> Any ideas ?
>
> Thx in advans,
> Karthik Balaguru
karthikbalaguru
> On Jan 11, 3:07 pm, karthikbalaguru <karthikbalagur...@gmail.com>
> wrote:
>
> > Hi,
> > There are certain editors that highlight
> > the syntax/color for datatypes/variables
> > or comments etc.
>
> > Similarly,
> > Is there a tool for C language that
> > could suggest an optimized/alternate
> > programming logic for the function that
> > is written ?
>
> IMHO the most effective output it could make is: "Are you really sure
> the best tool for this task is C?"
>
My query is 'A tool that suggests
optimized logic for a piece of
code/module/function' . I am
looking for a tool that suggests
optimized logic for various
modules/functions written in
C language.
The tool can be made of any
language.
>
> > The optimized/alternate logic can be
> > suggested as soon as we finish coding
> > for one function or it can be suggested
> > as soon as the code is compiled/parsed
> > by that tool.
>
> > It will be even more helpful if that tool
> > also provides the cycle counts, cache
> > usage, cache misses and lines of code
> > also.
>
> > It would be better if that tool has an
> > option to enable / disable this feature
> > either through compile time or some
> > other configurations.
>
> > Any ideas ?
>
> > Thx in advans,
> > Karthik Balaguru- Hide quoted text -
>
> - Show quoted text -
Karthik Balaguru
Nick Keighley
> On Jan 25, 5:31 am, toby <t...@telegraphics.com.au> wrote:
> > On Jan 11, 3:07 pm, karthikbalaguru <karthikbalagur...@gmail.com>
<snip>
> > > Is there a tool for C language that
> > > could suggest an optimized/alternate
> > > programming logic for the function that
> > > is written ?
>
> > IMHO the most effective output it could make is: "Are you really sure
> > the best tool for this task is C?"
>
> My query is 'A tool that suggests
> optimized logic for a piece of
> code/module/function' .
we can read
> I am
> looking for a tool that suggests
> optimized logic for various
> modules/functions written in
> C language.
and I am doubtful that such a tool can exist
> The tool can be made of any
> language.
or none
BTW: are your lines so short so your posts look like poetry?
--
"By 1985, machines will be capable of doing any work that a man can
do"
Herbert Simon 1965
Josef Moellers
> My query is 'A tool that suggests
> optimized logic for a piece of
> code/module/function' . I am
Define "optimized"!
Optimized for speed, optimized for memory requirement, optimized to
handle extreme situations, optimized to handle easy situations?
You can try explaining "optimized" to a human being. Then try to eplain
that to a computer program.
Josef
--
These are my personal views and not those of Fujitsu Technology Solutions!
Josef M�llers (Pinguinpfleger bei FTS)
If failure had no penalty success would not be a prize (T. Pratchett)
Company Details: http://de.ts.fujitsu.com/imprint.html
karthikbalaguru
wrote:
> karthikbalaguru wrote:
> > My query is 'A tool that suggests
> > optimized logic for a piece of
> > code/module/function' . I am
>
> Define "optimized"!
>
> Optimized for speed, optimized for memory requirement, optimized to
> handle extreme situations, optimized to handle easy situations?
>
Exactly !
The tool should support
for memory based optimization
that greatly helps in memory/
cost constraint systems,
speed based optimization that
greatly decides the performance
in certain projects, perfect
algorithm/logic required for a
particular scenario, and other
optimization techniques applicable.
It should probably have an option
that could decide the type of
optimization required for the user
for the particular module. May
be there can be an option called
'general optimization' that would
apply all optimization techniques
to a certain level only in a
balanced manner.
If the user is particular about
certain particular optimization,
Once the type of optimization
is got as input from the user,
even the level of optimization can
be got from the user by having
some flags/options for defining
different levels of optimization .
It could also tell the bottlenecks
in the code and that would greatly
help in optimizing the right piece
of code. Maybe a profiler should
also be part of it. The tool can
also display graphs that could
give comparitive analysis of
speed improvement vs memory
usage vs various levels of various
kinds of optimization techniques.
It can also suggest the best
possible number of threads
required, message queues
required for a particular
logic and define that logic.
It can remove off redundant
threads, interrupts or timers
etc and add if required for
an efficient logic that it
could suggest to the user.
Maybe, it can also suggest
various processors and the
relative performance w.r.t
memory, speed and cost
for those .
It could also suggest if
we need to go in for a
multicore and if so , it
can suggest the number
of cores and the kind of
processor !
Karthik Balaguru
Nick
> On Jan 26, 3:51 pm, Josef Moellers <josef.moell...@ts.fujitsu.com>
> wrote:
>> karthikbalaguru wrote:
>> > My query is 'A tool that suggests
>> > optimized logic for a piece of
>> > code/module/function' . I am
>>
>> Define "optimized"!
>>
>> Optimized for speed, optimized for memory requirement, optimized to
>> handle extreme situations, optimized to handle easy situations?
>>
>
> Exactly !
> The tool should support
> for memory based optimization
Optimised for line width, apparently.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
santosh
Nick wrote:
> karthikbalaguru <karthikb...@gmail.com> writes:
>
> > On Jan 26, 3:51 pm, Josef Moellers <josef.moell...@ts.fujitsu.com>
> > wrote:
> >> karthikbalaguru wrote:
> >> > My query is 'A tool that suggests
> >> > optimized logic for a piece of
> >> > code/module/function' . I am
> >>
> >> Define "optimized"!
> >>
> >> Optimized for speed, optimized for memory requirement, optimized to
> >> handle extreme situations, optimized to handle easy situations?
> >>
> >
> > Exactly !
> > The tool should support
> > for memory based optimization
>
> Optimised for line width, apparently.
A case of over-optimisation, if there ever was one. ;-)
David Brown
Perhaps the tool should be able to read the users' mind too, so that it
can optimise the type of optimisation? Maybe also predict the future so
that it can optimise appropriately for the actual use of the code?
Have you actually bothered to read /anything/ that has been posted in
this thread? We've used your wishful thinking as inspiration for some
interesting discussions, but no one considers your mythical tool to be
at all realistic. And your response is "for my next wish, I'd like
three more wishes".
Jonathan de Boyne Pollard
>
>> My query is 'A tool that suggests
>> optimized logic for a piece of
>> code/module/function' .
>>
>
English haiku.
Making programs good
involves human programmers.
You pay them money.
I tried for a limerick, but I became stuck after "A poster to Usenet
named Karthik ...".
André Gillibert
> On Jan 11, 3:07 pm, karthikbalaguru <karthikbalagur...@gmail.com>
> wrote:
> > Hi,
> > There are certain editors that highlight
> > the syntax/color for datatypes/variables
> > or comments etc.
> >
> > Similarly,
> > Is there a tool for C language that
> > could suggest an optimized/alternate
> > programming logic for the function that
> > is written ?
>
> IMHO the most effective output it could make is: "Are you really sure
> the best tool for this task is C?"
>
That's called an "optimizer" and is built into any good C compiler...
It doesn't even need to suggest a change. It just does it
internally, without modifying the source code.
PS:
Cross-posting to 5 newsgroup is evil.
Follow-up to comp.lang.c.
--
André Gillibert
John Gordon
> That's called an "optimizer" and is built into any good C compiler...
> It doesn't even need to suggest a change. It just does it
> internally, without modifying the source code.
The OP was asking for much more than an optimizing compiler.
To give just one example, he wants something which can recognize that
you're using a bubble-sort routine and can automatically rewrite the
source code into a quicksort.
--
John Gordon A is for Amy, who fell down the stairs
gor...@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"
Keith Thompson
> John Gordon <gor...@panix.com> writes:
>>The OP was asking for much more than an optimizing compiler.
>>To give just one example, he wants something which can recognize that
>>you're using a bubble-sort routine and can automatically rewrite the
>>source code into a quicksort.
>
> compiler not also be called »an optimizing compiler«?
>
> There is at least one automated optimization technique
> capable to do this: It tries all sequences of machine
> instructions until it finds one that has the behavior wanted
> (or the behavior of a given program).
>
> Of course, this is too slow for real-world programs today,
> but I believe it has indeed been used for some small programs.
> I just forget the name of this technique.
It's called "superoptimization". I think it's been used to generate
optimal code sequences that can then be hardwired into a compiler (so
the expensive superoptimization occurs during compiler development,
not during each compilation).
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson
> In <20100128202...@fixlaptop.gillibert.homelinux.net> =?UTF-8?B?QW5kcsOp?= Gillibert <MetaEntropy...@gmail.com> writes:
>
>> That's called an "optimizer" and is built into any good C compiler...
>> It doesn't even need to suggest a change. It just does it
>> internally, without modifying the source code.
>
> The OP was asking for much more than an optimizing compiler.
>
> To give just one example, he wants something which can recognize that
> you're using a bubble-sort routine and can automatically rewrite the
> source code into a quicksort.
So he wants a really clever optimizing compiler.
Walter Banks
Stefan Ram wrote:
> There is at least one automated optimization technique
> capable to do this: It tries all sequences of machine
> instructions until it finds one that has the behavior wanted
> (or the behavior of a given program).
>
> Of course, this is too slow for real-world programs today,
> but I believe it has indeed been used for some small programs.
> I just forget the name of this technique.
It comes under a number of names "superoptimizer" is one.
There two problems,
1) it as you say it can be slow. A 5 or 6 instruction search
can take up to a day.
2) Anything other than simple examples are surprisingly
hard to write correct execution criterion for.
It is however a technique that be useful for compiler writers
and those interested in coding algorithms.
Regards,
w..
--
Walter Banks
Byte Craft Limited
Tel. (519) 888-6911
http://www.bytecraft.com
Richard Bos
> John Gordon <gor...@panix.com> writes:
> > The OP was asking for much more than an optimizing compiler.
> >
> > To give just one example, he wants something which can recognize that
> > you're using a bubble-sort routine and can automatically rewrite the
> > source code into a quicksort.
>
> So he wants a really clever optimizing compiler.
No, he wants a read-my-mind magic optimising compiler. That is a
fundamentally different thing from a merely really clever one.
Richard
Keith Thompson
I don't think so. It would require some of what one might call
artificial intelligence, but the boundary between AI and merely
clever programming has always been fuzzy.
An optimizer that's able to recognize bubble sort and replace it
with quicksort should be entirely feasible, if it's handled as a
special case. (It's probably not worth doing, since it's easier
for the programmer to just use quicksort in the first place.)
And it wouldn't read the programmer's mind; the whole point is that
the programmer didn't think of using quicksort.
Walter Banks
Keith Thompson wrote:
> An optimizer that's able to recognize bubble sort and replace it
> with quicksort should be entirely feasible, if it's handled as a
> special case.
>
> And it wouldn't read the programmer's mind; the whole point is that
> the programmer didn't think of using quicksort.
The optimizer difficulty in C is recognizing the bubble sort then
determining that if it were replaced with a quicksort there
would be a benefit.
If a language represented objectives rather than implementations
it would be then possible for the compiler to simply make
choices in the code it generates.
To some extent this happens in C compilers now. For example
when a compiler sees a multiply "*" in source code it makes a
lot of choices when selecting what code to generate. The final
choice is based on data size, multiply by a constant or multiply
to constants (constant folding) and the appropriate code is
generated.
Telling the compiler ins some way what the objective is would
be the first step would be in determining what code should be
included in the application.
Regards,
Walter..
--
Walter Banks
Byte Craft Limited
Richard Tobin
Walter Banks <wal...@bytecraft.com> wrote:
>Keith Thompson wrote:
>> An optimizer that's able to recognize bubble sort and replace it
>> with quicksort should be entirely feasible, if it's handled as a
>> special case.
It would have to be a bit clever than that. Bubble sort is stable,
and quicksort implementations typically are't. It would have to
either use a stable version of quicksort, or determine that the
difference didn't affect the rest of the program.
Which is another example of this:
>If a language represented objectives rather than implementations
>it would be then possible for the compiler to simply make
>choices in the code it generates.
>To some extent this happens in C compilers now. For example
>when a compiler sees a multiply "*" in source code it makes a
>lot of choices when selecting what code to generate.
And of course one way C does this is by providing the library. Using
qsort() instead of writing a sort algorithm expresses clearly that you
want the data sorted. And it would be better if it provided both
a sort() and a stable-sort(), so you could express whether you
cared.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Joe Wright
The Insertion sort is stable and much better than bubble. Unlike quicksort
it can be implemented in a dozen lines or less.
--
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."