Simple program gathers together intelligently?
Mike
Will a main program find subroutines/functions automatically?
Recently, I read a book entitled "Prey" by Michael Crickton. It talks
about agent programs (or should say programmed nonometer machines.
Everyone is programmed with very simple idea. but they unite.)
solidified together intelligently to solve question, e.g. hunting
rabbits, something like that (I haven't finished it).
In practice, I write hundreds (almost I think) of sub/funcs and I have
to look around which is the most suitable ones for my current project
by MYSELF. It's so tedious. So I admire so much if someday this will
happen. Or it has already happend?
I know this may not be proper to talk here. But I am quite curious
that any expert here know if there's any progress about this in
fortran.
Mike
Richard Maine
> Will a main program find subroutines/functions automatically?
This has nothing really to do with Fortran, but basically.... no.
> In practice, I write hundreds (almost I think) of sub/funcs and I have
> to look around which is the most suitable ones for my current project
> by MYSELF. It's so tedious. So I admire so much if someday this will
> happen. Or it has already happend?
Sounds like you have organizational problems. As a general rule, my 35+
years of experience in software development says that software does not
tend to solve organizational problems. To the contrary, you need good
organizational skills to write software of any significant complexity. I
consider it one of the most important fundamental skills in programming.
Without it, you are pretty much limitted to small, throwaway programs.
This is more than just my own 35 years of experience speaking; it is
pretty universally accepted wisdom. Examples abound of people who had
horribly disorganized messes of some manual system and thought that
computerizing things would automatically solve that. They invariably end
up with a horribly disorganized computerized mess.
More specifically to your question...
You darn well need to know what subroutine or function you want to call
- what its name is, what its arguments are, and exactly what it does. If
you hope to be able to just say (In English? I sure wouldn't know how
else you would express it) "find me some program that solves my problem
and don't bug me about the details" then what you need does exist today,
but it is generaly called something like "programmer" or perhaps
"analyst" - not "Fortran" or any other programming language.
Perhaps you are talking about the much simpler problem of finding the
particular file that has the code in question. That one is automatable.
If you do know what the subroutine/function is and all the details
except for what file it was in, then you might be looking for an object
library. Pretty much all current systems support something like that.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
e p chandler
Mike wrote:
> Hi
>
> Will a main program find subroutines/functions automatically?
> Recently, I read a book entitled "Prey" by Michael Crickton. It talks
> about agent programs (or should say programmed nonometer machines.
> Everyone is programmed with very simple idea. but they unite.)
> solidified together intelligently to solve question, e.g. hunting
> rabbits, something like that (I haven't finished it).
Self replicating programs have been around for many years, long before
the current plague of viruses and worms. I'm sure someone has applied
the principles of genetic algorithms to writing computer programs.
[Maybe random aggregation explains the development process in Redmond.
:-).]
> In practice, I write hundreds (almost I think) of sub/funcs and I have
> to look around which is the most suitable ones for my current project
> by MYSELF. It's so tedious. So I admire so much if someday this will
> happen. Or it has already happend?
Classification schemes (taxonomies) already exist for computer programs
(ACM) and mathematical routines (like GAMS).
> I know this may not be proper to talk here. But I am quite curious
> that any expert here know if there's any progress about this in
> fortran.
Data storage and retrieval is a generic problem which is not specific
to a particular computer language. IMO there are better choices for
text processing elsewhere. But modern Fortran does provide the tools
for general purpose programming.
In short, if you are building a library, maybe you need a librarian.
-- elliot
Leif Harcke
> Mike wrote:
>> Recently, I read a book entitled "Prey" by Michael Crichton. It
>> talks about agent programs (or should say programmed nonometer
>> machines. Everyone is programmed with very simple idea. but they
>> unite.) solidified together intelligently to solve question,
>> e.g. hunting rabbits, something like that (I haven't finished it).
>
> Self replicating programs have been around for many years, long
> before the current plague of viruses and worms. I'm sure someone has
> applied the principles of genetic algorithms to writing computer
> programs.
T. Kilburn, R.L. Grimsdale, and F.H. Sumner, "Experiments in machine
learning and thinking," Proc. UNESCO International Conference on
Information Processing, Paris, France, 15-20 June 1959.
Abstract:
This paper describes experiments using the Manchester University
computers [Mark I and Mercury] to demonstrate machine learning and
thinking. A digital computer has been successfully programmed to
generate its own programmes which must satisfy certain given criteria.
For these generated programmes to be novel and interesting it is
essential that there be some degree of randomness in their
construction.
A number of methods are available by which the machine will improve
its ability in programme generation. In one of these a feedback
system is employed in which the probabilities of selection of the
various instructions are varied according to the success of the
generated programmes, thus enabling the machine to learn the most
suitable instructions to use. The machine can also learn by
experience, because all successful programmes are remembered and the
machine can use these to generate new programmes. In this way as the
machine gains in experience, the rate of production of programmes,
and the complexity of these programmes, increases.
The first criterion used was that the programmes should represent
convergent series. Many programmes were produced, some of a very
complex form. None of these could have been predicted and all were
originally unknown to the machine. In a second series of experiments,
the criteria were made less general, and the programmes had to
generate a specified sequence of numbers, the first three terms of
each sequence being supplied to the machine. This experiment clearly
demonstrated how the machine could learn to solve more difficult
problems by referring to the solutions obtained for simpler related
ones.
The paper describes work now in progress to extend the above scheme
in which the machine classifies the programmes it has produced and
proceeds to develop its own criteria.
Gib Bogle
...
> The paper describes work now in progress to extend the above scheme
> in which the machine classifies the programmes it has produced and
> proceeds to develop its own criteria.
>
You have to wonder how much progress has been made since 1959. My guess
is very little. In fact, it almost sounds like something out of Michael
Frayn's satire, The Tin Men.
beli...@aol.com
Richard Maine wrote:
> More specifically to your question...
>
> You darn well need to know what subroutine or function you want to call
> - what its name is, what its arguments are, and exactly what it does. If
> you hope to be able to just say (In English? I sure wouldn't know how
> else you would express it) "find me some program that solves my problem
> and don't bug me about the details" then what you need does exist today,
> but it is generaly called something like "programmer" or perhaps
> "analyst" - not "Fortran" or any other programming language.
Probably Matlab is popular because it comes closer than Fortran or C to
"find me some program that solves my problem and don't bug me about the
details" :).
Finding the right subroutine name can be easier if one uses INTERFACES
with MODULE PROCEDUREs. For any derived type I create, I can write
subroutines "display" (showing its contents with labels), "sort",
"init", etc. A drawback is that finding the underlying subroutine
actually being called can take more time than if all subroutine names
are distinct, as in Fortran 77.