Re: histrionics

Re: histrionics

[Preben Randhol]

G <Dizzy@interact.net.au> writes:

| A wise man once said that :" 'tis better to keep one's mouth shut and
| appear the fool
| than open it and remove all doubt."

I wouldn't say he was so wise, I'd say: "It's better to ask and learn,
than forever stay a fool" :-) 

Unfortunately I cannot help you with Ada, myself. Just a newbie. But
I'm finding 

      John Barnes: Programming in Ada 95. 2nd ed., Addison-Wesley, 1998, ISBN 0-201-34293-6 

a nice book to learn the language. It is probably not the best, but it
works for me so far. 

I don't think you should learn C++ as it is too complex.
-- 
Preben Randhol             oO     "Don't think about domination,  think
[randhol@pvv.org]        .`  ;     about freedom, it doesn't dominate."
[www.pvv.org/~randhol/]   \ G                  -- RMS, LinuxWorld 1999.
                           `_) n o m e

histrionics

[G]

Matthew Heaney wrote:

> G:
>
> What is your name, BTW?

  My name is Graeme... from Australia... sorry for the histrionics... my
dad is dying
of prostate cancer, I am currently very much unemployed,
I have had to teach myself (from scratch) as much as I can about
programming
because the courses are out of my financial reach
and my nation is (probably) about to go to war (Indonesia is doing
something
very Evil just now - shades of Kosovo)
and I tend to get a bit touchy
at times of stress.  That and the fact that one never can tell
what someone means just through their words...
*sigh*
sorry...
  It is very intimidating to learn a language like this and I am
grateful
for all the support that I have received at times from the many experts,

specialists and poly-capable programmers who frequent here.

>
>
> > I studied systems theory.  This relates to set theory but is
> literally a more
> > dynamic interpretation and extrapolation.  I was working on a
> specific systems
> > theoretical construction involving complexity and elaborating it
> through a
> > spatiotemporal model (yes.. I know its all a tad obscure).
>
> I too study systems theory.  I just finished Introduction To
> Cybernetics, by
> Ross Ashby.  Great book.

  I came through philosophy.  I was attempting to decipher the work of
Niklas Luhmann
in cybernetics, among other things, subjects, intellects and theoretical
abstractions.
 It is not all that I have read but my education has been both
predominantly
autodidactic and eclectic.

  My interests were specifically in the global structure of a system.
Which is to say -
in what ways can we model "total" and "complete" structures.  So,
because I figure that
programming is at least (in some measure) a matter of entities, of
objects persisting
over time (either the patterns of bits which constitute software or the
notional
"objects", control structures and so on of the coding end of things) and
as such is a matter of
ontology.  I had a terrible time at University attempting to use
concepts from
complexity theory, chaos theory and so on (in a non-specialist sense) to

conceptualising social systems, psychological systems and philosophical
models in and with which to
model such structures.  Had I been in Germany, I would have had every
opportunity - but universities
tend to maintain territorial intellectualisms.  (The same undoubtedly
occurs in computer science (?))
  I have studied martial arts practise and philosophy for many years, so
an interest in non-linear strategies is aquired.

>
>
> > I have been trying to find a way to elaborate what is in my mind's
> eye.  Thus
> > ADA has been useful.
>
> In general, that's true.  Ada is a very good language for constructing
> large
> systems, and very good at exactly capturing the nature of an
> abstraction
> (because of its very rich type facility).

   I do not think that I have the comprehension of programming yet to
know
whether or not ADA95 will let me do what I would like to.
  The ability to cast one's own types is certainly appealing to me, from

what I have seen of other languages.  Ada appears to make the matter
so very much less cryptic than Java, for instance... for a novice's
eyes anyway.



>
>
> > But as it seems to me as though I may be the "idiot" referred to
> earlier.  I
> > don't think I should say anymore.
>
> I don't think anyone is calling you an idiot.  The only reference to
> "idiots" that I can recall was by me, and I was referring to the
> members of
> the Kansas State Board of Education who voted against teaching
> Darwin's
> Theory of Evolution in Biology class.

  OK.  Perhaps the Board of Education in Kansas has done something
unique
and proven by their own mental prowess that retrograde evolution is in
fact possible.
We have people like that here...

>
>
> > Inasfar as simulation is concerned - I desire to employ the systems
> theory in
> > battlefield simulation.
>
> I apply systems theory to the construction of software systems too.
> It
> seems we have a lot in common!
>
> > As I am an idiot, I don't suppose I ever will and I am sad that I
> have been
> > deleted from this group every time I have posted.
>
> No, you are not an idiot, nor is anyone deleting your posts.

  It is very difficult to know when one is progressing with this
language.  I try
to learn about four different languages and when I find one stumps me I
turn to another for a while.
For instance, I recently began looking into C++ and found that having
spent some time with Java texts
and manuals had already opened the concepts up for me.  Also, that
spending time in ADA let
me understand more easily the dot notation call to procedures or
function/methods elsewhere.
  Anyway, having said that I probably got it wrong and I should say - I
was originally studying
to be an academic philosopher but things went off that path.  As things
do.  So, I hoped that
I could discuss issues with people such as yourselves.  Issues
pertaining to structure and system.
But it is difficult to insert myself conversationally because the nature
of conversation
is so specialised and cryptic to the novice...

>
>
> Please don't leave the group.  I, and I'm sure others, welcome your
> contributions and questions on comp.lang.ada.
>
> > G
>
> Matt

Thanks Matt.  What you said about the ability of ADA to capture
abstraction through its type
facility - that is why I am more attracted to Ada.

I have a certain mental construct which has been bouncing around my
neuronal architecture
for several years and which I am attempting to find expression for.

It is related to cybernetics, too, I suppose inasmuch as the system is
composed of elements
which support the replication of themselves and through them the global
structure.  I have to think this out a bit
because I am rusty in elaborating these things.

I guess, and it is all but impossible (for now) to explain the system I
will eventually attempt to simulate/model with ada (as
perhaps a seed for more practical enterprises, if I am very lucky),
well... I looked into the philosophy of
space, time, of spacetime and anamorphic (i.e. relativistic) distortions
of such.  What fascinated me was that what may be happening
in biological, cosmological (and several other -"logicals") systems is
that at the level of sequence and time it is the
replication of a process, not of purely (or purely of) static elements
within a system of process.  The process which is being replicated
is precisely the process of replication itself.  Now, there may be a
variety of symmetries to such things, symmetry in
an abstract sense (much as electron may rotate through 720 degrees
before returning to its start point, implying
a dimensional depth of a counter-intuitive nature).

The symmetry involved is the mental image I think will be something to
which Ada could be applied for modelling
and simulation.  Not as a fundamental system, but an extension of
existing systems.  Which may be all that we ever do anyway, extend,
modify and even the Kansas Board of Education is but an example of the
progressive sedimentation of complexity
in biological, cosmological and other systems...

But I am not very good at explaining this.

I don't even know if I can model this mental image.  Something like
Menger's sponge meets a logarithmic spiral and
onto the spiral is mapped an accleration or otherwise increase in
complexity.  There is a subtle dimensional depth though,
drawing this spiral around a conical shape.  The central axis of the
conical structure is itself no less than precisely the same
spiral running orthogonal to the cone.

I just had a gut feeling about this system.  I read all the popular
literature from Hofstadter's Godel, Escher, Bach and onwards.

Are there ways within software systems to model structures which on
every scale of magnification replicate themselves ?  I
do not mean purely materially, say as Cantor's dust and it's (infinite)
structure might represent, but in the sense that the
process of replication is itself what is replicated at every scale of
magnitude.

I just had a feeling that it may be possible to represent this in Ada.

Also... because I am interdisciplinary... it may turn out to be not a
computer-reprsentable concept and
fall through as a horrendously complex social, psychological theory.  I
just have a hunch... and simulation
is a current obsession of mine.

So... I have questions to ask anyone here who will answer... because I
AM a novice.
It is NOT off subject because I am trying to determine how to use Ada
for a theoretical
abstraction.... for modelling that abstraction and then eventually to
employ the structure
as a base structure for simulation.  I enjoy the challenge and the
learning curve of this
fascinating language.

I suppose that one must build such systems from the ground up in Ada.
So, I must be looking
at years of learning.

-Graeme

A wise man once said that :" 'tis better to keep one's mouth shut and
appear the fool
than open it and remove all doubt."

 I may have now achieved the latter twice in one day. Impressive.  I
could say more...
but I have been vociferous enough as is.
:-)

Re: histrionics

[G]

Preben Randhol wrote:

> G <Dizzy@interact.net.au> writes:
>
> | A wise man once said that :" 'tis better to keep one's mouth shut and
> | appear the fool
> | than open it and remove all doubt."
>
> I wouldn't say he was so wise, I'd say: "It's better to ask and learn,
> than forever stay a fool" :-)
>
> Unfortunately I cannot help you with Ada, myself. Just a newbie. But
> I'm finding
>
>       John Barnes: Programming in Ada 95. 2nd ed., Addison-Wesley, 1998, ISBN 0-201-34293-6
>
>
> I don't think you should learn C++ as it is too complex.
> --
> Preben Randhol             oO     "Don't think about domination,  think
> [randhol@pvv.org]        .`  ;     about freedom, it doesn't dominate."
> [www.pvv.org/~randhol/]   \ G                  -- RMS, LinuxWorld 1999.
>                            `_) n o m e

Hey.  Well I have about 6 or 7 html tutorials and vast  quantities of ada95 source code.
I have one hard copy book.

C++... yes... you are right... but I have nothing better to do and caffeine addiction rocks...

G

:-)

Re: histrionics

[Nick Roberts]

Graeme,

Have you introduced yourself to one of the 5GLs (Fifth Generation Languages:
this is a loose classification)? I am keen on Prolog myself, but there is
LISP, Haskell, ML (maybe;-) and quite a few others (some really obscure).

You may find that using a higher-level language, such as Prolog, fits your
'application domain' better than Ada (but not necessarily). Ada may suit you
very well if you need a fully compiled language (i.e. maximum speed), or if
your software ends up being immensely big and complex, but I would guess
these are both unlikely.

Prolog and LISP are (generally) interactive languages; you might find this
way of programming and working suits you better. They are, essentially, a
little simpler than Ada, too.

(Am I a traitor to Ada or what? :-)

I guess further discussion should be by e-mail (CC Preben Randhol and Marin
Condic) rather than in this newsgroup.

-------------------------------------
Nick Roberts
http://www.adapower.com/lab/adaos
-------------------------------------

Re: histrionics

[Robert Dewar]

In article <37d74de9@eeyore.callnetuk.com>,
  "Nick Roberts" <nickroberts@callnetuk.com> wrote:
> Graeme,
>
> Have you introduced yourself to one of the 5GLs (Fifth
Generation Languages:
> this is a loose classification)? I am keen on Prolog myself,
but there is
> LISP, Haskell, ML (maybe;-) and quite a few others (some
really obscure).

I don't think the term 5GL is a useful one here, especially
since LISP is most certainly a 1GL language :-)

The point that very high level languages may be more appropriate
to a domain is certainly a useful one. It is interesting to
remember that SETL, used to implement the first validated
Ada compiler, is now nearly 30 years old, but the development
of VHLL's has been disappointing. Prolog itself is a very
old language at this point.

The 5GL project in Japan, an AI-oriented big fiasco many years
ago (dig up my quotes at the time for some entertainment) was
prolog based, and promised all kinds of wonderful fixes and
improvements to prolog that did not happen. Prolog is one of
those languages that has a fascinating idea, but ultimately
is disappointing ...


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: histrionics

[Vladimir Olensky]

Robert Dewar wrote in message <7r8c60$b2q$1@nnrp1.deja.com>...
> Prolog is one of
>those languages that has a fascinating idea, but ultimately
>is disappointing ...


There are opinions and opinions :-)
Hope this is not an invitation to start another language flame:-)

As for me I would not blame any existing programming language and state that
it is disappointing.
All of them are  evolution outcome and each has it's merits and drawbacks.

No one will use Prolog for writing  safety critical applications or
operating systems or number crunching.
But for writing applications that exhibit artificial intelligence it is one
of the best choices.
Especially when one has to extract solutions from facts and rules not known
when original  code had been issued.  Prolog program can modify itself and
be self learning. Of course it can be done in Ada or even in Basic (by the
way I have a book somewhere shelf on writing AI application using Basic).
Ada is best suited for safety critical control applications and programming
in general.
Prolog is best suited for writing expert systems.

One of the real  examples of Prolog in action is the Xircom expert system
for installing Xircom adapters on  PC (may be it is not Xircom - I do not
remember exactly the Company name - I remember the idea). Installation
program gathers all the data about PC and user can send it to that expert
system which in turn will analyze all hardware dependencies and
incompatibilities and it will give recommendations regarding best
configuration options.
One may ask why they did not do that in Ada :-)
There are many other examples. I am sure Nick Roberts can supply a lot of
them:-)

The other  example that I enjoy very much  is Axon2000 Idea processor.
( http://web.singnet.com.sg/~axon2000  ).
One of the best tools to help one's vague ideas to take real shape. Very
cool.


Regards.

Re: histrionics

[Robert Dewar]

In article <rtg6mdp71iv13@corp.supernews.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>
> Prolog is best suited for writing expert systems.

Well this is of course the argument that the Japanese were
trying to make in the 5GL project, but at the time, most
US experts in expert systems were unconvinced, and considered
LISP a better choice. That opinion has not significantly
changed, although you probably find more expert systems written
in "conventional" languages like C or Ada these days than
before.

Yes, there are some very convincing examples of Prolog programs,
I think one of the most interesting was the program that
embodied the UK citizenship laws. But the fact of the matter is
that Prolog just has not lived up to the promises we heard in
Tokyo. Yes, of course there will be enthusiasts who see things
otherwise, but it is certainly *very* controversial to claim
that it is obvious that Prolog is the best language for writing
expert systems.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: histrionics

[Ted Dennison]

In article <7r9rkj$g75$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> US experts in expert systems were unconvinced, and considered
> LISP a better choice. That opinion has not significantly
> changed, although you probably find more expert systems written
> in "conventional" languages like C or Ada these days than
> before.

While taking my AI class last summer, it occurred to me that inference
engines share a number of similarities with compilers. There are
differences too of course. But it might be possible to use an
OpenToken-style approach to create a general Ada inference engine and
rule-based-system whose rules could be programmed entirely in Ada.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: histrionics

[Vladimir Olensky]

Robert Dewar wrote in message <7r9rkj$g75$1@nnrp1.deja.com>...
>In article <rtg6mdp71iv13@corp.supernews.com>,
>  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>>
>> Prolog is best suited for writing expert systems.
>
>Well this is of course the argument that the Japanese were
>trying to make in the 5GL project, but at the time, most
>US experts in expert systems were unconvinced, and considered
>LISP a better choice. That opinion has not significantly
>changed, although you probably find more expert systems written
>in "conventional" languages like C or Ada these days than
>before.


May be this is because writing complex programs in Prolog requires
very high level of abstract thinking to be able to express complex
problems using short logic predicates sentences.
It is always more easy to describe something in many words
than in couple of  words:-)
Another thing is that it may be difficult for many people to grasp
the idea of backtracking and recursion and be able to understand
program execution that uses them.
Iterative algorithms implemented using conventional languages may
have much more lines of code but be much more easy  understandable.



> But the fact of the matter is
>that Prolog just has not lived up to the promises we heard in
>Tokyo.

I think that one of the problems  was that they were too enthusiastic
and they underestimated complexity of human thinking.
Not everything can be described by logic predicates and algorithmes.
Irrational thinking, intuition and wisdom that are part of human nature
(some people have  only the number one from that list  :-)   can  hardly
be expressed using any programming language. There are other
ways of doing that.  I am sure that  after breakthrough in nanomolecular
technologies and bio_technologies (probably before 2010 ) we will see
a lot of amazing things.

Regards.

Re: histrionics

[Robert Dewar]

In article <rtiq3si91iv24@corp.supernews.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
> Another thing is that it may be difficult for many people to
grasp
> the idea of backtracking and recursion and be able to
understand
> program execution that uses them.

No, in Prolog, the difficulty is not understanding the
backtracking, that's the easy part, or it would be easy
if it were pure, but the cut operator is like falling
off a semantic cliff, and the frequent need to use cut
is a severe disappointment.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: histrionics

[Robert Dewar]

In article <rtiq3si91iv24@corp.supernews.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote

> May be this is because writing complex programs in Prolog
> requires very high level of abstract thinking to be able to
> express complex problems using short logic predicates
> sentences.

Actually I disagree strongly with your criticisms of Prolog.
On the contrary, I think it is MUCH easier to think at the
prolog level, than to think in the low level sequential
manner that conventional programming requires (as I mentioned
the sad thing in Prolog, is that once you use cut, which in
practice you do need to in real programs, you have to go back
to much lower level thinking).

> It is always more easy to describe something in many words
> than in couple of  words:-)

No, again I disagree, the power of very high level languages
is directly related to the fact that you want to be able
to describe things at a much higher level, and of course
the descriptions are shorter. If I can say (this is SETL,
without the nice character set :-)

primes = {n in 2 .. 100 |
           notexists j in 2 .. n - 1 |
             n mod j = 0};

that's a WHOLE lot easier to understand than a seive programmed
in a conventional procedural language. Vladimir, you can supply
the corresponding prolog program if you like :-) I prefer the
statement in SETL, since it seems close to the mathematical
definition of primes, both syntactically and semantically

> Another thing is that it may be difficult for many people to
> grasp= the idea of backtracking

Actually the nice thing about angelic non-determinism is
precisely that you DON'T need to think about it, the right
thing happens. Backtracking is not a fundamental part of
the semantics of Prolog at a high level, rather it is an
implementation mechanism for acheiving a correct pattern
match as required by angelic ND. Of course, once again,
if you worry about cut, then suddenly the backtracking
becomes non-transparent. A very similar situation happens
in SNOBOL-4 pattern matching, which at best can be considered
to be fully declarative, but which provides lots of cut-like
low level junk that requires you to know the procedural
algorithm that is used.

> and recursion

Surely you are not saying recursion is hard to understand. Sure
I know that beginning students may have trouble, but surely
anyone who considers themselves a competent professional
programmer has got past this long ago, and is completely
comfortable with recursion ...

> Iterative algorithms implemented using conventional languages
> may have much more lines of code but be much more easy
> understandable.

This is the kind of criticism you expect from someone who
basically does not like Prolog :-) I would strongly disagree
an elegant program written in Prolog is far far easier to
understand than the extended gobbledygook that passes for
low level procedural programming :-)

So, it's interesting, Dewar and Olensky have almost
diametrically opposed views of Prolog.

Dewar likes very high level languages in general, and finds
examples of programs written in these languages compelling,
and for examples, that feeling applies to Prolog. Elegant
Prolog examples, even quite complex ones are quite
beautiful, easy to understand, concise, and clear.

Where Dewar gets off the Prolog admiration bus is where people
claim that it is an appropriate and practical language for
writing large scale applications, including expert systems.

Olensky on the other hand is rather suspicious of Prolog, thinks
it is hard to understand because of backtracking, logic etc, but
nevertheless thinks it is the language of choice for large
complex expert systems.

Interesting ....




Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: histrionics

[Vladimir Olensky]

Robert Dewar wrote in message <7rcddd$bfd$1@nnrp1.deja.com>...
>In article <rtiq3si91iv24@corp.supernews.com>,
>  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote
>
>> May be this is because writing complex programs in Prolog
>> requires very high level of abstract thinking to be able to
>> express complex problems using short logic predicates
>> sentences.
>
>Actually I disagree strongly with your criticisms of Prolog.
>On the contrary, I think it is MUCH easier to think at the
>prolog level, than to think in the low level sequential
>manner that conventional programming requires (as I mentioned
>the sad thing in Prolog, is that once you use cut, which in
>practice you do need to in real programs, you have to go back
>to much lower level thinking).
>
>> It is always more easy to describe something in many words
>> than in couple of  words:-)
>
>No, again I disagree, the power of very high level languages
>is directly related to the fact that you want to be able
>to describe things at a much higher level, and of course
>the descriptions are shorter. If I can say (this is SETL,
>without the nice character set :-)
>
>primes = {n in 2 .. 100 |
>           notexists j in 2 .. n - 1 |
>             n mod j = 0};
>
>that's a WHOLE lot easier to understand than a seive programmed
>in a conventional procedural language. Vladimir, you can supply
>the corresponding prolog program if you like :-) I prefer the
>statement in SETL, since it seems close to the mathematical
>definition of primes, both syntactically and semantically
>
>> Another thing is that it may be difficult for many people to
>> grasp= the idea of backtracking
>
>Actually the nice thing about angelic non-determinism is
>precisely that you DON'T need to think about it, the right
>thing happens. Backtracking is not a fundamental part of
>the semantics of Prolog at a high level, rather it is an
>implementation mechanism for acheiving a correct pattern
>match as required by angelic ND. Of course, once again,
>if you worry about cut, then suddenly the backtracking
>becomes non-transparent. A very similar situation happens
>in SNOBOL-4 pattern matching, which at best can be considered
>to be fully declarative, but which provides lots of cut-like
>low level junk that requires you to know the procedural
>algorithm that is used.
>
>> and recursion
>
>Surely you are not saying recursion is hard to understand. Sure
>I know that beginning students may have trouble, but surely
>anyone who considers themselves a competent professional
>programmer has got past this long ago, and is completely
>comfortable with recursion ...
>
>> Iterative algorithms implemented using conventional languages
>> may have much more lines of code but be much more easy
>> understandable.
>
>This is the kind of criticism you expect from someone who
>basically does not like Prolog :-) I would strongly disagree
>an elegant program written in Prolog is far far easier to
>understand than the extended gobbledygook that passes for
>low level procedural programming :-)
>
>So, it's interesting, Dewar and Olensky have almost
>diametrically opposed views of Prolog.
>
>Dewar likes very high level languages in general, and finds
>examples of programs written in these languages compelling,
>and for examples, that feeling applies to Prolog. Elegant
>Prolog examples, even quite complex ones are quite
>beautiful, easy to understand, concise, and clear.
>
>Where Dewar gets off the Prolog admiration bus is where people
>claim that it is an appropriate and practical language for
>writing large scale applications, including expert systems.
>
>Olensky on the other hand is rather suspicious of Prolog, thinks
>it is hard to understand because of backtracking, logic etc, but
>nevertheless thinks it is the language of choice for large
>complex expert systems.
>
>Interesting ....
>


As I matter of fact it is not my personal opinion of Prolog.
I tried to imagine what could think about that an ordinary
person with conventional programming language experience.
The formula  "if I were someone else"  sometimes very useful
when one tries to understand why something is happening this
particular way.  (Your remark that many expert systems are written
 in other languages than Prolog).

Along with technical reasons there are always psychological reasons such
as people mentality, habits, influence of the environment etc.
Very often human factor prevails over technical reasons.

As for me I never blame people that they are doing something their own way.
I always try to put myself in their place and understand their reasons.

As far as for very high level abstract logic thinking not all the people
have such ability. May be 2-5 % of all. Such people became professors in
their field.
And most of the programmers are not CS professors. This explains a lot of
things.
Moreover a lot of people are very reluctant to learn something new that are
beyond
their current experience and knowledge.

Regards.

Re: histrionics

[Vladimir Olensky]

Robert Dewar wrote in message <7rcckp$b12$1@nnrp1.deja.com>...
>In article <rtiq3si91iv24@corp.supernews.com>,
>  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>> Another thing is that it may be difficult for many people to
>grasp
>> the idea of backtracking and recursion and be able to
>understand
>> program execution that uses them.
>
>No, in Prolog, the difficulty is not understanding the
>backtracking, that's the easy part, or it would be easy
>if it were pure, but the cut operator is like falling
>off a semantic cliff, and the frequent need to use cut
>is a severe disappointment.


I had this in mind when was talking about backtracking.
In Prolog  cut operator significantly complicates
comprehending of the backtracking process.

Regards.

Re: histrionics

[Bob Collins]

In article <7rb5lm$dhu$1@nnrp1.deja.com>, Ted Dennison
<dennison@telepath.com> wrote:

> In article <7r9rkj$g75$1@nnrp1.deja.com>,
>   Robert Dewar <robert_dewar@my-deja.com> wrote:
> > US experts in expert systems were unconvinced, and considered
> > LISP a better choice. That opinion has not significantly
> > changed, although you probably find more expert systems written
> > in "conventional" languages like C or Ada these days than
> > before.
> 
> While taking my AI class last summer, it occurred to me that inference
> engines share a number of similarities with compilers. There are
> differences too of course. But it might be possible to use an
> OpenToken-style approach to create a general Ada inference engine and
> rule-based-system whose rules could be programmed entirely in Ada.

Now getting far afield, but no further than our hero (RD)
in discussions about Prolog, both if-then expert system
rules and parser rewrite rules are variants of Post
Production Systems. One of my doctoral students wrote a
thesis that used LR parsing as the inference engine for
an expert system. He combined an earlier idea about using
Finite State Automata to provide procedural control for
expert systems, and his resulting grammars served as both
procedural control and as the if-then rules. Of course, the
grammars were ambiguous, so as to allow conflict resolution
heuristics.

He showed that his method outdid the Rete algorithm (in the
lab). The AI journal he submitted the work to did not publish
his results (I think) because they did not understand LR
parsing and the PL journal he submitted was not interested in
the AI implications.

To bring the subject back to Ada, he did get a conference
invitation to one of the Ada and AI conferences at George
Mason University. The parser, the AI hooks, the parser
generators, the semantics were all written in Ada, just as
suitable as LISP or Prolog for big AI work. (Big = thousands
of productions).

-- 
Bob Collins     <mailto:b-collins@home.com>

Re: histrionics

[Vladimir Olensky]

Bob Collins wrote in message ...

>He showed that his method outdid the Rete algorithm (in the
>lab). The AI journal he submitted the work to did not publish
>his results (I think) because they did not understand LR
>parsing and the PL journal he submitted was not interested in
>the AI implications.

This may be considered as  an illustration to what I wrote in my other post:

-- Along with technical reasons there are always psychological reasons such
-- as people mentality, habits, influence of the environment etc.
-- Very often human factor prevails over technical reasons.

-- <snipped>

-- Moreover a lot of people are very reluctant to learn something new
-- that are beyond their current experience and knowledge.


Regards.

Re: histrionics

[Robert Dewar]

In article <rtk7od9h1iv79@corp.supernews.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
> I had this in mind when was talking about backtracking.
> In Prolog  cut operator significantly complicates
> comprehending of the backtracking process.

OK, so we are in complete agreement here. Unfortunately, large
real world Prolog programs tend to depend heavily on cut.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: histrionics

[Ted Dennison]

In article <b-collins-1109991310150001@192.168.0.10>,
  b-collins@home.com (Bob Collins) wrote:

> in discussions about Prolog, both if-then expert system
> rules and parser rewrite rules are variants of Post
> Production Systems. One of my doctoral students wrote a
> thesis that used LR parsing as the inference engine for
> an expert system. He combined an earlier idea about using
...
> lab). The AI journal he submitted the work to did not publish
> his results (I think) because they did not understand LR
> parsing and the PL journal he submitted was not interested in
> the AI implications.

Cool! It didn't seem possible that I'd be the only person to ever
think of that. Is there anywhere I can get a look at it? Or did he not
publish his work on the web either?

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: histrionics

[Robert I. Eachus]

Robert Dewar wrote:

> No, again I disagree, the power of very high level languages
> is directly related to the fact that you want to be able
> to describe things at a much higher level, and of course
> the descriptions are shorter. If I can say (this is SETL,
> without the nice character set :-)
> 
> primes = {n in 2 .. 100 |
>            notexists j in 2 .. n - 1 |
>              n mod j = 0};
> 
> that's a WHOLE lot easier to understand than a seive programmed
> in a conventional procedural language. Vladimir, you can supply
> the corresponding prolog program if you like :-) I prefer the
> statement in SETL, since it seems close to the mathematical
> definition of primes, both syntactically and semantically

    I agree, I prefer APL for this kind of thinking even though there is
the problem that you really need to rewrite the "program" in a readable
language once you have it correct.  For example, I know of three short
definitions (taking 18, 17 and 16 characters respectively) for primes. 
The longest--but most efficient, defines a prime as an integer with
exactly two positive integer divisors.  The next definition is that a
prime is an integer that is not a member of the set of products of all
the integers greater than one.  The shortest definition corresponds to
Wilson's theorem:  An integer N is prime iff
(N-1)! is congruent to -1 mod N.

   Note that none of these is the algorithm I would use to find out
whether or not a large integer is prime, but even those algorithms are
easier to think about in a higher level notation that supports number
theory well.

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: histrionics

[Ehud Lamm]

On Tue, 21 Sep 1999, Robert I. Eachus wrote:

|  But these programs are very clear
|(if you have an APL character set available


Or try J instead (J uses plain old ASCII). 

Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

Re: histrionics

[p.obry]

Just to fix some syntax error in Robert example:

  with Ada.Integer_Text_IO;
  procedure Primes (N:Positive) is
    Total: Natural;
  begin
    for I in 1..N loop
      Total := 0;
      for J in 1..I loop
        if I mod J = 0 then 
           Total := Total + 1;
        end if;
        exit when Total > 2;
      end loop;
      if Total = 2 then 
         Ada.Integer_Text_IO.Put(I);
      end if;
    end loop;
  end Primes;

Pascal.

Re: histrionics

[Robert I. Eachus]

Robert Dewar wrote:
 
> primes := {x in 2 .. N |
>             not exists y,z in 2 .. x-1 | x = y*z}
 
   Just as compact as APL, although I notice you optimized by using a
range
of 2..x-1 instead of 2..x or 1..x-1.

   How does Wilson's Theorem look in SETL?  Note that I am not knocking
SETL,
I just happen to use APL when working on certain types of problems.  An
appropriate higher level language can a great tool for designing and
documenting algorithms, and SETL and APL overlap domains.  SETL is much
better for set theory, and APL for numerical methods.  In either case,
detailed efficiency is secondary while getting the algorithm right.  For
example, when using PROLOG as a design language, you usually want to
forget about cut points.

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: histrionics

[Ehud Lamm]

If we are on the subject of VHLLs and SETL, let me ask a SETL question. I
really don't knwo the language, only the basic idea - and since I can not
find a PC version, it'll take some time for me to get to know it better
(but learning something Dewar was involved in is likely to be a pleasure:
SNOBOL, GNAT etc.)

How would you find all numbers like 407=4^3+0^3+7^3 that are equal to the
sum of their digits' cubes?

A not very illuminating essay on this problem can be found in the
E-Archive - see my home page. It contains a solution in J.

Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

Re: histrionics

[Ehud Lamm]

On Thu, 23 Sep 1999, Ehud Lamm wrote:

|How would you find all numbers like 407=4^3+0^3+7^3 that are equal to the
|sum of their digits' cubes?
|

In SETL of course...

By the way: these are call "Narcisstic Numbers", see
http://www.treasure-troves.com/math/NarcissisticNumber.html

Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

Sums of cubes (was Re: histrionics)

[Robert I. Eachus]

Ehud Lamm wrote:
> 
> If we are on the subject of VHLLs and SETL, let me ask a SETL question. I
> really don't knwo the language, only the basic idea - and since I can not
> find a PC version, it'll take some time for me to get to know it better
> (but learning something Dewar was involved in is likely to be a pleasure:
> SNOBOL, GNAT etc.)

    Good point.  It might be a nice idea to implement SETL in Ada so it
is
easily portable.  (This would be going full circle, since the first
validated
Ada implementation was in SETL!)
 
> How would you find all numbers like 407=4^3+0^3+7^3 that are equal to the
> sum of their digits' cubes?

    Interesting question, but I have found that programming in Ada works
best with a "sandwich" approach, or maybe you want to call it meet in
the middle.  To illustrate, note that one operation that we will be
doing a lot is cubing numbers.  This can be implemented in the form of a
table:

   procedure Sum_of_Cubes is 
     Cube_Table: array(0..9) of Integer :=
       (0, 1, 8, 27, 64, 125, 216, 343, 512, 729);
     -- There are other ways to initialize this table, but cut and paste
from
     -- APL and add commas is pretty quick.
     
     function Cubes(N: Integer) return Integer
       is begin return Cube_Table(N); end Cubes;
     pragma Inline(Cube);

   begin
     TBD;
   end Sum_of_Cubes;

   Okay, now to the algorithm.  There is no need to generalize to more
digits yet, and it is simple enough to write three loops.  I'll keep the
convention
that 000 and 001 are three digit numbers...

   procedure Sum_of_Cubes is
     Cube_Table: array(0..9) of Integer :=
       (0, 1, 8, 27, 64, 125, 216, 343, 512, 729);
     -- There are other ways to initialize this table, but cut and paste
from
     -- APL is very quick.
     
     function Cube(N: Integer) return Integer
       is begin return Cube_Table(N); end Cube;
     pragma Inline(Cube);

   begin
     for I in 0..9 loop
       for J in 0..9 loop
         for K in 0..9 loop
           if Cube(I) + Cube(J) + Cube(K) = 100*I + 10*J + K
           then Print_Result;
           end if;
         end loop;
       end loop;
     end loop;
   end Sum_of_Cubes;

   Now back to the low level, the computation on the right side of the
equality
can be strenth reduced.  A compiler might be smart enough to do it, but
there is no reason not to "do it ourselves" since the algorithm becomes
cleaner, IMHO.
 
   procedure Sum_of_Cubes is
     Cube_Table: array(0..9) of Integer :=
       (0, 1, 8, 27, 64, 125, 216, 343, 512, 729);
     Number: Integer := 0;     
     function Cube(N: Integer) is
       begin return Cube_Table(N); end Cube;
     pragma Inline(Cube);

   begin
     for I in 0..9 loop
       for J in 0..9 loop
         for K in 0..9 loop
           if Cube(I) + Cube(J) + Cube(K) = Number;
           then Print_Result;
           end if;
           Number := Number + 1;
         end loop;
       end loop;
     end loop;
   end Sum_of_Cubes;

   Should we do the same optimization for the sums of cubes?  It looks
like the
best solution/compromise is to do half of it:

   procedure Sum_of_Cubes is
     Cube_Table: array(0..9) of Integer :=
       (0, 1, 8, 27, 64, 125, 216, 343, 512, 729);
     Number: Integer := 0;
     Partial: Integer;     
     function Cube(N: Integer)return Integer
       is begin return Cube_Table(N); end Cube;
     pragma Inline(Cube);

   begin
     for I in 0..9 loop
       for J in 0..9 loop
         Partial := Cube(I) + Cube(J);
         for K in 0..9 loop
           if  Partial + Cube(K) = Number
           then Print_Result;
           end if;
           Number := Number + 1;
         end loop;
       end loop;
     end loop;
   end Sum_of_Cubes;

   Next step write Print_Result.  This could be done as an inline
procedure,
but it is now simple enough to do in place:

   with Ada.Integer_Test_IO; with Ada.Text_IO;
   procedure Sum_of_Cubes is
      subtype Digit is Integer range 0..9;
      Cube_Table: array(Digit) of Integer :=
           (0, 1, 8, 27, 64, 125, 216, 343, 512, 729);
     Number: Integer := 0;
     Partial: Integer;     
     function Cube(N: Integer) return Integer is
        begin return Cube_Table(N); end Cube;
     pragma Inline(Cube);

   begin
     for I in 0..9 loop
       for J in 0..9 loop
         Partial := Cube(I) + Cube(J);
         for K in 0..9 loop
           if  Partial + Cube(K) = Number;
           then Ada.Integer_Text_IO.Put(Number, 4);
           end if;
           Number := Number + 1;
         end loop;
       end loop;
     end loop;
   Ada.Text_IO.New_Line;
   end Sum_of_Cubes;

   A last cleanup that might help the compiler, but will certainly help
readers and maintainers.  There are too many instances of 0..9 in the
code.  Time for a subtype:

   with Ada.Integer_Text_IO; with Ada.Text_IO;
   procedure Sum_of_Cubes is
     subtype Digit is Integer range 0..9;
     Cube_Table: array(Digit) of Integer :=
           (0, 1, 8, 27, 64, 125, 216, 343, 512, 729);
     Number: Integer := 0;
     Partial: Integer;     
     function Cube(N: Digit) return Integer is
        begin return Cube_Table(N); end Cube;
     pragma Inline(Cube);

   begin
     for I in Digit loop
       for J in Digit loop
         Partial := Cube(I) + Cube(J);
         for K in Digit loop
           if  Partial + Cube(K) = Number
           then Ada.Integer_Text_IO.Put(Number, 4);
           end if;
           Number := Number + 1;
         end loop;
       end loop;
     end loop;
   Ada.Text_IO.New_Line;
   end Sum_of_Cubes;

   Modifying to check four digit numbers results in no new matches, but
is very easy (two new lines, two modified, if you don't count the name. 
Also, execution doesn't take long enough to measure.  Changing from
cubes to fourth power (but keeping four digits) results in an output of
    0    1 1634 8208 9474
and only requires changing one line (again ignoring name changes...) 
-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Sums of cubes (was Re: histrionics)

[Robert Dewar]

In article <37EA8DEA.61D49E6A@mitre.org>,
  "Robert I. Eachus" <eachus@mitre.org> wrote:
>     Good point.  It might be a nice idea to implement SETL in
Ada so it
> is
> easily portable.  (This would be going full circle, since the
first
> validated
> Ada implementation was in SETL!)

The current SETL implementations are in C and C++ and are fully
portable and have been ported to many platforms.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Sums of cubes (was Re: histrionics)

[Wes Groleau]

>    procedure Sum_of_Cubes is
>      Cube_Table: array(0..9) of Integer :=
>        (0, 1, 8, 27, 64, 125, 216, 343, 512, 729);
> 
>      function Cubes(N: Integer) return Integer
>        is begin return Cube_Table(N); end Cubes;
>      pragma Inline(Cube);


Perhaps I should study the whole message before 
shooting my mouth off, but here goes:

Is there any significant difference between the above
and the simpler

    procedure Sum_of_Cubes is

      Cubes: array (0..9) of Integer :=
        (0, 1, 8, 27, 64, 125, 216, 343, 512, 729);

?

Re: Sums of cubes (was Re: histrionics)

[Wes Groleau]

> > How would you find all numbers like 407=4^3+0^3+7^3 that are equal to the
> > sum of their digits' cubes?

Not as efficient as Robert Eachus's example, but IMHO, clearer and more
general:

    generic
      type Nat is range <>;
    procedure Sum_of_Cubes;

    with Ada.Text_IO;
    procedure Sum_of_Cubes is

      Cube : array (Character range '0'..'9') of Nat :=
                      (0, 1, 8, 27, 64, 125, 216, 343, 512, 729);

      Counter : Nat := 0;


      function Sum_Of_Cubes_Matches (N : Nat) return Boolean is

         N_Str : constant String := Nat'Image (N);
         Sum   :          Nat    := Nat'First;
    
      begin

         -- skip the non-digit first character of 'Image

         for I in N_Str'First + 1 .. N_Str'Last loop

            Sum := Sum + Cube (N_Str(I));

        end loop;

        return (abs N) = Sum;  -- ignore sign

      end Sum_Of_Cubes_Matches;


    begin  -- Sum_Of_Cubes

      Find_Numbers:
        loop  

          Check_One:
            begin

            if Sum_Of_Cubes_Matches (Counter) then
            -- no semicolon after conditional expression :-)
               Ada.Text_IO.Put_Line (Nat'Image (Counter));
            end if;

            exception
              when Constraint_Error =>
                null;  -- If the sum gets a constraint error
                       -- and the number didn't, it's not a match.
                       -- In a block because we don't want an
                       -- error on 9,999 to prevent checking 10,000
                       -- (I think Robert missed this detail.)
            end Check_One;

            exit Find_Numbers when Counter := Nat'Last;

            Counter := Counter + 1;

        end loop Find_Numbers;

    end Sum_Of_Cubes;

Sacrificing clarity for efficiency is not usually good, though it might
be worthwhile in this case.  (Takes ten seconds to do 0..999_999 on a
366 MHz
SPARC--takes longer than one can endure to do Natural'Range in GNAT).
I'm sure 'Image on every number has a big impact.

Re: Sums of cubes (was Re: histrionics)

[Robert I. Eachus]

Wes Groleau wrote:
>               when Constraint_Error =>
>                 null;  -- If the sum gets a constraint error
>                        -- and the number didn't, it's not a match.
>                        -- In a block because we don't want an
>                        -- error on 9,999 to prevent checking 10,000
>                        -- (I think Robert missed this detail.)
 
   Nope, the sum of cubes of 999 is 3*729 = 2187, the sum of cubes for
9999 is
2916, etc.  If you were going for something like the tenth power it
would be an issue.
-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Sums of cubes (was Re: histrionics)

[Robert I. Eachus]

Robert Dewar wrote:
 
> The current SETL implementations are in C and C++ and are fully
> portable and have been ported to many platforms.

   Ah, I knew there was a C implementation, I wasn't aware that it was
easily portable.  (I notice that I tend to assume that an Ada program is
easily portable and a C program is not, although there are many
counterexamples to both assumptions.

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Sums of cubes (was Re: histrionics)

[Robert Dewar]

In article <37EB82AE.49B875C8@ftw.rsc.raytheon.com>,
  Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:
> Is there any significant difference between the above
> and the simpler
>
>     procedure Sum_of_Cubes is
>
>       Cubes: array (0..9) of Integer :=
>         (0, 1, 8, 27, 64, 125, 216, 343, 512, 729);
>


For sure you want a constant keyword here, I don't think you
want to allow (as you do above)

Cubes (3) := 42;


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Sums of cubes (was Re: histrionics)

[Wes Groleau]

"Robert I. Eachus" wrote:
> 
> Wes Groleau wrote:
> >               when Constraint_Error =>
> >                 null;  -- If the sum gets a constraint error
> >                        -- and the number didn't, it's not a match.
> >                        -- In a block because we don't want an
> >                        -- error on 9,999 to prevent checking 10,000
> >                        -- (I think Robert missed this detail.)
> 
>    Nope, the sum of cubes of 999 is 3*729 = 2187, the sum of cubes for
> 9999 is
> 2916, etc.  If you were going for something like the tenth power it
> would be an issue.

Or if the package is instantiated with 0..1000 (for example).  Without
the handler for constraint_error, my version would stop at 99.
(I should have used 99 in the comment.)  Since Robert's version used
non-generic integers, it did not have that problem.  
(i.e., I apologize for my false accusation.)

Robert's version is undoubtedly more efficient, but mine is simpler.
However, if you're doing five digits or less, either version will take
longer to compile than to run.  Six digits runs in ten seconds
on a slow SPARC.  Seven digits is runs under 2.5 minutes.  So up to
seven digits, the optimizing analysis takes longer than a very
UNoptimized computation.

But Robert's fact about 9999:2916 made me think:

The largest possible sum-of-cubes for six digits is 6 * 9**3 = 4374
The smallest possible six-digit number is bigger than that.
So it's pointless to go beyond five digits.  Or is my math wrong?

Took less than a minute to show with a spreadsheet that

with power of      you can stop at
2                       3 digits
3                       5 digits
4                       5 digits
5                       6 digits
6                       7 digits
7                       8 digits
8                       9 digits
9                      10 digits