Home > Archive > Prolog > September 2007 > An even more basic question...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
An even more basic question...
|
|
| Chip Eastham 2007-09-12, 7:07 pm |
| On Sep 11, 10:55 pm, summ <sum...@gmail.com> wrote:
> And probably very stupid :-)
> I have been reading some tutorials but the most interesting
> things are still mystery to me.
>
> Let's suppose that we have a timer, or rather simple clock in Prolog
> program.
> Every second the time is increasing by 1.
> Will we have (after one hour) 3600 facts (?) like
> time(1).
> time(2).
> .
> .
> .
> time(3600).
>
> I'd like to have just one fact i.e.
> time(3600).
>
> However - even then we would know current time BEFORE
> we check that the fact: time(3600) is true ;-) Another solution is
> quick checking all the facts ;-)
> In "normal" language we would check the value of proper variable,
> where we keep current time.
>
> Regards,
> summ
Hi, summ:
For what purpose do you need "a timer, or rather simple
clock in Prolog program" ?
Recording a bunch of facts (time(1), time(2), etc.) as
you can see doesn't really help much. Perhaps you are
interested in tracking when certain events occurred,
but in that case you would need facts that reflect a
relationship between the time and the specific event,
eg. time(1,start), time(2,fileopen), time(5,fileclose),
etc.
If you want to know what time is it now, i.e. read the
system clock, this is naturally an extension to Prolog
in the form of built-in predicate supplied by many
implementations.
Possibly you want to use a timer to measure relative
performance of different codings/algorithms. I don't
know what advice to offer without a clearer picture
of your purpose.
regards, chip
| |
|
| On 12 Wrz, 16:52, Chip Eastham <hardm...@gmail.com> wrote:
> For what purpose do you need "a timer, or rather simple
> clock in Prolog program" ?
Hi, Chip
My Prolog skills are very poor so I am feel a bit
tongue-tied by such specialists like you or Markus Triska.
My purpose is to create a very simple artificial world
to simulate behavior of lonely digital creature, and to
test its ability of selfteaching. Its life is determined
by the need to avoid pain and embrace pleasure. Selfteaching
would be possible through statistics e.g some events lead
more often to something pleasant, while others not. Thanks
to selfteaching this creature could predict future effects
of current events and properly adjust its behavior.
Very important sequence of events could be remembered.
Internal clock is esential to reflect dynamics of events.
I'd like to have the possibility to interfere e.g to change
something inside while running the program.
Regards, summ
| |
| Tom Davies 2007-09-13, 4:16 am |
| You will probably want predicates which provide transitions between
states in your virtual world. One component of these states would be
the current time.
Do you have Bratko's "Prolog Programming for Artificial Intelligence"?
It has an example of a monkey getting a banana which illustrates this
approach.
One predicate from this example is:
move(
state(middle, onbox, middle, no),
grasp,
state(middle, onbox, middle, yes)
).
you could modify this to:
move(
state(middle, onbox, middle, no, T1),
grasp,
state(middle, onbox, middle, yes, T2)
) :- T2 = T1+1.
to record time as you move from state to state.
Tom
| |
| Matthew Huntbach 2007-09-13, 4:16 am |
| On Wed, 12 Sep 2007, summ wrote:
> On 12 Wrz, 16:52, Chip Eastham <hardm...@gmail.com> wrote:
[color=darkred]
> My Prolog skills are very poor so I am feel a bit
> tongue-tied by such specialists like you or Markus Triska.
> My purpose is to create a very simple artificial world
> to simulate behavior of lonely digital creature, and to
> test its ability of selfteaching. Its life is determined
> by the need to avoid pain and embrace pleasure. Selfteaching
> would be possible through statistics e.g some events lead
> more often to something pleasant, while others not. Thanks
> to selfteaching this creature could predict future effects
> of current events and properly adjust its behavior.
> Very important sequence of events could be remembered.
> Internal clock is esential to reflect dynamics of events.
> I'd like to have the possibility to interfere e.g to change
> something inside while running the program.
Why do you want to do it in Prolog?
Matthew Huntbach
| |
|
| On 13 Wrz, 10:33, Matthew Huntbach <m...@dcs.qmul.ac.uk> wrote:
> Why do you want to do it in Prolog?
Because Prolog can find solution instead of me. My role is to
define proper rules and facts. At least I hope ;-)
summ
| |
| Matthew Huntbach 2007-09-13, 8:05 am |
| On Thu, 13 Sep 2007, summ wrote:
> On 13 Wrz, 10:33, Matthew Huntbach <m...@dcs.qmul.ac.uk> wrote:
[color=darkred]
> Because Prolog can find solution instead of me. My role is to
> define proper rules and facts. At least I hope ;-)
This was the sales pitch used for Prolog when it was first developed in
the 1970s. We were very naive and optimistic about it then. It is
surprising to find people still repeating it now, long after bitter
experience has shown it just isn't so. My experience is that Prolog
is strongly dependent on its operational mechanism, and to attempt to
program with it without being thoroughly aware of how that mechanism works
will get you nowhere.
This was to some extent recognised when Prolog was first developed - I think
there was the idea that though it was very limited, it was at least a
demonstration that something which was arguably logic could also be a
programming language, and in time more sophisticated operational
mechanisms could be discovered which would really mean it would "find
a solution" without you having to think about it. Hence the continuing
confusion between "Prolog" - a language heavily dependenent on left-to-right
search with backtracking, and "logic programming" - the more general idea of
writing logic and executing it as a program. Sadly, despite many experiments,
the dream of pure logic programming has not resulted in a successful language.
The prototype logic language, Prolog, survives, because it does have the
benefit of reasonably simple operational behaviour. Given the huge problems
newbies have getting to grips with this simple language, no wonder none of
the more complex logic languages proposed have ever got anywhere.
My advice - since you admit your Prolog skills are very weak, don't bother
using the language. It doesn't do what you seem to think it will do.
Matthew Huntbach
| |
|
| On 13 Wrz, 14:37, Matthew Huntbach <m...@dcs.qmul.ac.uk> wrote:
> On Thu, 13 Sep 2007, summ wrote:
[color=darkred]
>
> This was the sales pitch used for Prolog when it was first developed in
> the 1970s. We were very naive and optimistic about it then. It is
> surprising to find people still repeating it now, long after bitter
> experience has shown it just isn't so.
Hmm. I don't think, that Prolog has Artificial Intelligence built in.
> My experience is that Prolog
> is strongly dependent on its operational mechanism, and to attempt to
> program with it without being thoroughly aware of how that mechanism works
> will get you nowhere.
That's why coding in Prolog is so boring and effects are
unpredictible, unless
you are a very experienced master.
> My advice - since you admit your Prolog skills are very weak, don't bother
> using the language. It doesn't do what you seem to think it will do.
I'm afraid you are right. My conclusion - nothing compares to
Python :-)
I must take a closer look at:
http://labix.org/python-constraint
summ
| |
| Matthew Huntbach 2007-09-13, 7:07 pm |
| On Thu, 13 Sep 2007, summ wrote:
> On 13 Wrz, 14:37, Matthew Huntbach <m...@dcs.qmul.ac.uk> wrote:
[color=darkred]
> That's why coding in Prolog is so boring and effects are
> unpredictible, unless you are a very experienced master.
There's nothing in particular unpredictable about it, its operational behaviour
is quite simple and can easily be described, it has very little syntax It's
far less complex to deal with than, say, some of the things you can do with
pointers in an imperative language, let alone the complexities introduced when
we add object-oriented features as in C++.
Matthew Huntbach
| |
|
| I'd be interested to hear from folks what, if any, commercial-level
problems that prolog HAS been appropriate for. I had been considering this
as a good environment for modeling constraint problems, both sets and
minimization but find that these are all libraries added to the fundamental
language and typically written in other languages. and yet, systems like
AMPL seem to give the same functionality with a lower learning curve.
Further, so many of the modern concepts of code development,
maintainability and best practice seem to be absent.
seems if Prolog should be considered in the same class as SQL - a
specialized language for addressing a specific problem as a library for more
professional languages, although I'm looking to you folks to clarify what
problem set prolog covers.. for example - noone expects SQL to support GUI
programming, and prolog doesn't seem to be appropriate for that either. One
thing about SQL that is interesting is that behind the scenes, SQL
interpreters are designed to optimize execution / scheduling of the queries
to the underlying dataset, whereas in prolog, no such concept of built-in
search optimization seems to exist.
"Matthew Huntbach" <mmh@dcs.qmul.ac.uk> wrote in message
news:Pine.LNX.4.64.0709131319000.11388@frank.dcs.qmul.ac.uk...
> On Thu, 13 Sep 2007, summ wrote:
>
>
>
> This was the sales pitch used for Prolog when it was first developed in
> the 1970s. We were very naive and optimistic about it then. It is
> surprising to find people still repeating it now, long after bitter
> experience has shown it just isn't so. My experience is that Prolog
> is strongly dependent on its operational mechanism, and to attempt to
> program with it without being thoroughly aware of how that mechanism works
> will get you nowhere.
>
> This was to some extent recognised when Prolog was first developed - I
> think
> there was the idea that though it was very limited, it was at least a
> demonstration that something which was arguably logic could also be a
> programming language, and in time more sophisticated operational
> mechanisms could be discovered which would really mean it would "find
> a solution" without you having to think about it. Hence the continuing
> confusion between "Prolog" - a language heavily dependenent on
> left-to-right
> search with backtracking, and "logic programming" - the more general idea
> of
> writing logic and executing it as a program. Sadly, despite many
> experiments,
> the dream of pure logic programming has not resulted in a successful
> language.
> The prototype logic language, Prolog, survives, because it does have the
> benefit of reasonably simple operational behaviour. Given the huge
> problems
> newbies have getting to grips with this simple language, no wonder none of
> the more complex logic languages proposed have ever got anywhere.
>
> My advice - since you admit your Prolog skills are very weak, don't bother
> using the language. It doesn't do what you seem to think it will do.
>
> Matthew Huntbach
| |
| Matthew Huntbach 2007-09-14, 4:19 am |
| On Fri, 14 Sep 2007, sdw wrote:
(top posting switched to bottom posting)
> "Matthew Huntbach" <mmh@dcs.qmul.ac.uk> wrote in message
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
> I'd be interested to hear from folks what, if any, commercial-level
> problems that prolog HAS been appropriate for. I had been considering this
> as a good environment for modeling constraint problems, both sets and
> minimization but find that these are all libraries added to the fundamental
> language and typically written in other languages. and yet, systems like
> AMPL seem to give the same functionality with a lower learning curve.
> Further, so many of the modern concepts of code development,
> maintainability and best practice seem to be absent.
Yes, I am not making any claims that Prolog is a very useful language.
I don't think it is. I cannot think of any task where it would be my
language of choice.
Matthew Huntbach
| |
| Chip Eastham 2007-09-14, 7:07 pm |
| On Sep 14, 3:48 am, "sdw" <warw...@jps.net> wrote:
> I'd be interested to hear from folks what, if any, commercial-level
> problems that prolog HAS been appropriate for. I had been considering this
> as a good environment for modeling constraint problems, both sets and
> minimization but find that these are all libraries added to the fundamental
> language and typically written in other languages. and yet, systems like
> AMPL seem to give the same functionality with a lower learning curve.
Prolog is a pretty decent platform for some "knowledge
engineering" applications, where there are a number of
well-defined rules and facts that need to be "checked"
in some sense, repetitively.
In a larger sense Prolog is ideal for "reference"
implementations of algorithms. The syntax of Prolog
programs is often very concise, esp. with a good
design, and the "semantics" of the declarative style
programming can be advantageous for clarity in
understanding the program's correctness.
Having said this, a procedural implementation of the
algorithm will almost always be faster (at the expense
of semantic clarity). Thus a role for the reference
implementation in testing of an "optimized" one is
something to consider, esp. if coding the reference
implementation is done quickly in comparison to the
overall testing needed for the optimized procedural
implementation.
> Further, so many of the modern concepts of code development,
> maintainability and best practice seem to be absent.
This may be more a question of volume. Modularity
in design, library reuse, and "object-oriented"
extensions to Prolog syntax are available. However
much of the literature is devoted to research on
extending logic programming in various ways, not
on "best practices" because of a dwindling audience.
> seems if Prolog should be considered in the same class as SQL - a
> specialized language for addressing a specific problem as a library for more
> professional languages, although I'm looking to you folks to clarify what
> problem set prolog covers.. for example - noone expects SQL to support GUI
> programming, and prolog doesn't seem to be appropriate for that either. One
> thing about SQL that is interesting is that behind the scenes, SQL
> interpreters are designed to optimize execution / scheduling of the queries
> to the underlying dataset, whereas in prolog, no such concept of built-in
> search optimization seems to exist.
I like the analogy with SQL, because it's also based
largely on some first-order logic of relations.
Another decent analogy is with XSLT. SQL is hardly
ever implemented in a recursion-friendly way, but
XSLT is.
I'm interested in various means (indexing, sorting)
of query optimization in Prolog, and I posted a
thread recently asking about the literature on that
subject. It seems ripe for exposition since many
Prolog implementations have such mechanisms, but
there's no standardized consensus.
regards, chip
| |
|
| thanks to both of you for your thoughts. Assuming you speak for the
community at large, let me follow on by asking - since there was a
relatively recent standardization of prolog, how come the prolog community,
especially the vendors, has not continued the effort to develop a language
with more, um, functional capabilities beyond the clear use as a teaching
environment ( ala the original Pascal! ). As an example, for those who are
familiar with mathematica, for instance, one sees a very rich mixture of
rules, goals, list processing, procedures, etc, although it is not
applicable as a standalone language for product development. programmers
tend to be loathe to tie themselves to a particular vendors' toolset or
library, so the need for a standards based system is really critical.
"sdw" <warwick@jps.net> wrote in message
news:13ekf792m386g28@corp.supernews.com...
> I'd be interested to hear from folks what, if any, commercial-level
> problems that prolog HAS been appropriate for. I had been considering
> this as a good environment for modeling constraint problems, both sets and
> minimization but find that these are all libraries added to the
> fundamental language and typically written in other languages. and yet,
> systems like AMPL seem to give the same functionality with a lower
> learning curve. Further, so many of the modern concepts of code
> development, maintainability and best practice seem to be absent.
>
> seems if Prolog should be considered in the same class as SQL - a
> specialized language for addressing a specific problem as a library for
> more professional languages, although I'm looking to you folks to clarify
> what problem set prolog covers.. for example - noone expects SQL to
> support GUI programming, and prolog doesn't seem to be appropriate for
> that either. One thing about SQL that is interesting is that behind the
> scenes, SQL interpreters are designed to optimize execution / scheduling
> of the queries to the underlying dataset, whereas in prolog, no such
> concept of built-in search optimization seems to exist.
>
>
>
>
>
>
> "Matthew Huntbach" <mmh@dcs.qmul.ac.uk> wrote in message
> news:Pine.LNX.4.64.0709131319000.11388@frank.dcs.qmul.ac.uk...
>
>
| |
| Matthew Huntbach 2007-09-17, 7:09 pm |
| I think I have already answered this in the points I made which you quoted.
What you seem to be asking for is a much richer logic programming language,
but in that case why call it Prolog? You don't, after all, insist that every
imperative programming language is called "Pascal". Pascal was one simple
model of imperative programming, the good thing it had goiong for it was
that it had a simple operational model. Other much richer imperative languages
were called something else. In the same way, there have been proposals for
other much richer logic programminmg languages - but because they are different
forms of the logic programming paradigm, they are not "Prolog".
Matthew Huntbach
On Fri, 14 Sep 2007, sdw wrote:
> thanks to both of you for your thoughts. Assuming you speak for the
> community at large, let me follow on by asking - since there was a
> relatively recent standardization of prolog, how come the prolog community,
> especially the vendors, has not continued the effort to develop a language
> with more, um, functional capabilities beyond the clear use as a teaching
> environment ( ala the original Pascal! ). As an example, for those who are
> familiar with mathematica, for instance, one sees a very rich mixture of
> rules, goals, list processing, procedures, etc, although it is not
> applicable as a standalone language for product development. programmers
> tend to be loathe to tie themselves to a particular vendors' toolset or
> library, so the need for a standards based system is really critical.
[color=darkred]
[color=darkred]
|
|
|
|
|