info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Dealing with uncertainty - in a way
59 views
Skip to first unread message
mmoel
Jun 16, 2015, 9:29:43 AM6/16/15
to
Hi,
I'm interested to know how other Prolog users deal
with the following problem.
As you all know critical software can be made more
reliable if it gets written in different languages
and subsequently compiled and run on different machines.
The results should match, which they normally do.
Otherwise ways and means of debugging are obvious.
While there rarely are serious issues regarding the
well known procedural languages, different Prolog
compilers produce different results on the same machine
even with simple text book code. Just to give an example,
one Prolog says no, while the other one says yes in
reply to the very same query. Tracing quickly reveals
the reason for this: The first one stops its search at
some point, while the second one continues until it
succeeds. However, problems usually are less clear.
This is a very different situation because regardless
of whether this can be adjusted in some way or not,
first and foremost we have to find out we've got an
issue at all. Results should be more than accidentally
correct. Verifying the result with another Prolog
seems to be mandatory but is in no way the solution
to the problem. Is there any other way but the dissection
of the Prolog compiler or WAM in question?
Tracing is reasonably easy regarding text book
exercises dealing with simple and straightforward
solutions. But now consider a real world expert system
written in Prolog drawing conclusions from and interacting
with some simulation process running on another machine
or any other sufficiently costly and complex system.
I'm wondering at which point the expert system fails
because of some possible peculiarity of the underlying
Prolog implementation, not noticed beforehand. Or even
worse: Will I recognize this failure at all?
Regards
Michael
I'm interested to know how other Prolog users deal
with the following problem.
As you all know critical software can be made more
reliable if it gets written in different languages
and subsequently compiled and run on different machines.
The results should match, which they normally do.
Otherwise ways and means of debugging are obvious.
While there rarely are serious issues regarding the
well known procedural languages, different Prolog
compilers produce different results on the same machine
even with simple text book code. Just to give an example,
one Prolog says no, while the other one says yes in
reply to the very same query. Tracing quickly reveals
the reason for this: The first one stops its search at
some point, while the second one continues until it
succeeds. However, problems usually are less clear.
This is a very different situation because regardless
of whether this can be adjusted in some way or not,
first and foremost we have to find out we've got an
issue at all. Results should be more than accidentally
correct. Verifying the result with another Prolog
seems to be mandatory but is in no way the solution
to the problem. Is there any other way but the dissection
of the Prolog compiler or WAM in question?
Tracing is reasonably easy regarding text book
exercises dealing with simple and straightforward
solutions. But now consider a real world expert system
written in Prolog drawing conclusions from and interacting
with some simulation process running on another machine
or any other sufficiently costly and complex system.
I'm wondering at which point the expert system fails
because of some possible peculiarity of the underlying
Prolog implementation, not noticed beforehand. Or even
worse: Will I recognize this failure at all?
Regards
Michael
Julio Di Egidio
Jun 16, 2015, 10:04:12 AM6/16/15
to
On Tuesday, June 16, 2015 at 3:29:43 PM UTC+2, mmoel wrote:
> Hi,
>
> I'm interested to know how other Prolog users deal
> with the following problem.
>
> As you all know critical software can be made more
> reliable if it gets written in different languages
> and subsequently compiled and run on different machines.
That is nonsense: we rely on platforms and modularity. Correctness is usually (not guaranteed, but) enforced via testing. For truly critical systems, one uses formal methods (and components themselves certified).
> Hi,
>
> I'm interested to know how other Prolog users deal
> with the following problem.
>
> As you all know critical software can be made more
> reliable if it gets written in different languages
> and subsequently compiled and run on different machines.
> The results should match, which they normally do.
> Otherwise ways and means of debugging are obvious.
>
> While there rarely are serious issues regarding the
> well known procedural languages, different Prolog
> compilers produce different results on the same machine
> even with simple text book code.
> Just to give an example,
> one Prolog says no, while the other one says yes in
> reply to the very same query.
> Tracing quickly reveals
> the reason for this: The first one stops its search at
> some point, while the second one continues until it
> succeeds. However, problems usually are less clear.
>
> This is a very different situation because regardless
> of whether this can be adjusted in some way or not,
> first and foremost we have to find out we've got an
> issue at all. Results should be more than accidentally
> correct. Verifying the result with another Prolog
> seems to be mandatory but is in no way the solution
> to the problem. Is there any other way but the dissection
> of the Prolog compiler or WAM in question?
>
> Tracing is reasonably easy regarding text book
> exercises dealing with simple and straightforward
> solutions. But now consider a real world expert system
> written in Prolog drawing conclusions from and interacting
> with some simulation process running on another machine
> or any other sufficiently costly and complex system.
> I'm wondering at which point the expert system fails
> because of some possible peculiarity of the underlying
> Prolog implementation, not noticed beforehand. Or even
> worse: Will I recognize this failure at all?
Julio
Ulrich Neumerkel
Jun 16, 2015, 10:16:33 AM6/16/15
to
Julio Di Egidio <ju...@diegidio.name> writes:
>On Tuesday, June 16, 2015 at 3:29:43 PM UTC+2, mmoel wrote:
>> While there rarely are serious issues regarding the
>> well known procedural languages, different Prolog
>> compilers produce different results on the same machine
>> even with simple text book code.
>
>Admittedly, the Prolog standard has few serious issues...
>but otherwise Prolog is not different than any other
>programming language: 100% compatibility across any platforms
>times implementation-specific functions just does not
>exist: engineers make informed choices...
>
>> Just to give an example,
>> one Prolog says no, while the other one says yes in
>> reply to the very same query.
>
>That does not sound right, as hinted at above. Otherwise, can you
>actually show some example?
Could you **both** produce the examples/issues were you
>On Tuesday, June 16, 2015 at 3:29:43 PM UTC+2, mmoel wrote:
>> While there rarely are serious issues regarding the
>> well known procedural languages, different Prolog
>> compilers produce different results on the same machine
>> even with simple text book code.
>
>Admittedly, the Prolog standard has few serious issues...
>but otherwise Prolog is not different than any other
>programming language: 100% compatibility across any platforms
>times implementation-specific functions just does not
>exist: engineers make informed choices...
>
>> Just to give an example,
>> one Prolog says no, while the other one says yes in
>> reply to the very same query.
>
>That does not sound right, as hinted at above. Otherwise, can you
>actually show some example?
think the Prolog standard has problems?
Julio Di Egidio
Jun 16, 2015, 10:22:33 AM6/16/15
to
On Tuesday, June 16, 2015 at 4:16:33 PM UTC+2, Ulrich Neumerkel wrote:
Julio
> Julio Di Egidio <j***@diegidio.name> writes:
> >On Tuesday, June 16, 2015 at 3:29:43 PM UTC+2, mmoel wrote:
<snip>
> >On Tuesday, June 16, 2015 at 3:29:43 PM UTC+2, mmoel wrote:
> >> Just to give an example,
> >> one Prolog says no, while the other one says yes in
> >> reply to the very same query.
> >
> >That does not sound right, as hinted at above. Otherwise, can you
> >actually show some example?
>
> Could you **both** produce the examples/issues were you
> think the Prolog standard has problems?
He did not say the Prolog standard has problems, I did. And you and I have already discussed this issue: to no end...
> >> one Prolog says no, while the other one says yes in
> >> reply to the very same query.
> >
> >That does not sound right, as hinted at above. Otherwise, can you
> >actually show some example?
>
> Could you **both** produce the examples/issues were you
> think the Prolog standard has problems?
Julio
Julio Di Egidio
Jun 16, 2015, 10:24:43 AM6/16/15
to
Julio
Ulrich Neumerkel
Jun 16, 2015, 10:52:18 AM6/16/15
to
mmoel <mi...@t-online.de> writes:
>While there rarely are serious issues regarding the
>well known procedural languages, different Prolog
>compilers produce different results on the same machine
>even with simple text book code. Just to give an example,
>one Prolog says no, while the other one says yes in
>reply to the very same query. Tracing quickly reveals
>the reason for this: The first one stops its search at
>some point, while the second one continues until it
>succeeds. However, problems usually are less clear.
Could you please produce a concrete example of what
>While there rarely are serious issues regarding the
>well known procedural languages, different Prolog
>compilers produce different results on the same machine
>even with simple text book code. Just to give an example,
>one Prolog says no, while the other one says yes in
>reply to the very same query. Tracing quickly reveals
>the reason for this: The first one stops its search at
>some point, while the second one continues until it
>succeeds. However, problems usually are less clear.
you actually describe here?
mmoel
Jun 16, 2015, 10:54:43 AM6/16/15
to
>> As you all know critical software can be made more
>> reliable if it gets written in different languages
>> and subsequently compiled and run on different machines.
> That is nonsense: we rely on platforms and modularity.
> Correctness is usually (not guaranteed, but) enforced via testing
>> reliable if it gets written in different languages
>> and subsequently compiled and run on different machines.
> That is nonsense: we rely on platforms and modularity.
> Correctness is usually (not guaranteed, but) enforced via testing
> For truly critical systems, one uses formal methods (and
> components themselves certified).
Go tell NASA. They'll spare lots of money.
> components themselves certified).
>> Just to give an example,
>> one Prolog says no, while the other one says yes in
>> reply to the very same query.
>
> That does not sound right, as hinted at above. Otherwise,
> can you actually show some example?
Regards
Michael
Julio Di Egidio
Jun 16, 2015, 10:19:19 AM6/16/15
to
On Tuesday, June 16, 2015 at 4:04:12 PM UTC+2, Julio Di Egidio wrote:
Julio
mmoel
Jun 16, 2015, 11:09:18 AM6/16/15
to
Different Prolog implementations always did things different.
I'm interrested to know how you deal with this.
For the sake of completeness here is one example
taken from Bratko, Prolog Programming for AI, 4th Ed.
Try it with Gprolog, Bprolog, Yap and XSB and you'll
get different answers (at least on Sun Sparc).
Regards
Michael
:- op(800, fx, if).
:- op(700, xfx, then).
:- op(300, xfy, or).
:- op(200, xfy, and).
is_true(P) :-
fact(P).
is_true(P) :-
if Condition then P,
is_true(Condition).
is_true(P1 and P2) :-
is_true(P1),
is_true(P2).
is_true(P1 or P2) :-
is_true(P1)
;
is_true(P2).
if
hall_wet and kitchen_dry
then
leak_in_bathroom.
if
hall_wet and bathroom_dry
then
problem_in_kitchen.
if
window_closed or no_rain
then
no_water_from_outside.
if
problem_in_kitchen and no_water_from_outside
then
leak_in_kitchen.
fact(hall_wet).
fact(bathroom_dry).
fact(window_closed).
% is_true(leak_in_kitchen).
Julio Di Egidio
Jun 16, 2015, 11:09:59 AM6/16/15
to
On Tuesday, June 16, 2015 at 4:54:43 PM UTC+2, mmoel wrote:
> >> As you all know critical software can be made more
> >> reliable if it gets written in different languages
> >> and subsequently compiled and run on different machines.
> > That is nonsense: we rely on platforms and modularity.
> > Correctness is usually (not guaranteed, but) enforced via testing
> > For truly critical systems, one uses formal methods (and
> > components themselves certified).
>
> Go tell NASA. They'll spare lots of money.
I am telling you instead, as the nonsense is yours.
> >> As you all know critical software can be made more
> >> reliable if it gets written in different languages
> >> and subsequently compiled and run on different machines.
> > That is nonsense: we rely on platforms and modularity.
> > Correctness is usually (not guaranteed, but) enforced via testing
> > For truly critical systems, one uses formal methods (and
> > components themselves certified).
>
> Go tell NASA. They'll spare lots of money.
> >> Just to give an example,
> >> one Prolog says no, while the other one says yes in
> >> reply to the very same query.
> >
> > That does not sound right, as hinted at above. Otherwise,
> > can you actually show some example?
>
> Sure, as many as you like.
> But this wasn't my question.
Julio
Ulrich Neumerkel
Jun 16, 2015, 11:18:58 AM6/16/15
to
k
mmoel
Jun 16, 2015, 11:32:14 AM6/16/15
to
mmoel
Jun 16, 2015, 11:39:56 AM6/16/15
to
Ulrich Neumerkel
Jun 16, 2015, 11:47:48 AM6/16/15
to
mmoel <mi...@t-online.de> writes:
>is_true(leak_in_kitchen).
I cannot see a difference for this query. All of them (GNU, B, YAP, XSB
as well as SICStus, SWI) succeed as expected.
Could it be that the way how the toplevel is realised is what is
confusing? To make this clear: There is no standardized toplevel
loop. In fact, it is even explicitly out of scope of ISO/IEC 13211-1:1995.
Some toplevels will only answer yes or no, provided the query does
not contain variables. These are relatively old toplevels.
XSB, B, YAP, SICStus have such a toplevel. You can fool them, by writing
?- is_true(leak_in_kitchen), X=a.
But that is the only difference I see for this example. Am I missing
something?
>is_true(leak_in_kitchen).
I cannot see a difference for this query. All of them (GNU, B, YAP, XSB
as well as SICStus, SWI) succeed as expected.
Could it be that the way how the toplevel is realised is what is
confusing? To make this clear: There is no standardized toplevel
loop. In fact, it is even explicitly out of scope of ISO/IEC 13211-1:1995.
Some toplevels will only answer yes or no, provided the query does
not contain variables. These are relatively old toplevels.
XSB, B, YAP, SICStus have such a toplevel. You can fool them, by writing
?- is_true(leak_in_kitchen), X=a.
But that is the only difference I see for this example. Am I missing
something?
mmoel
Jun 16, 2015, 5:18:09 PM6/16/15
to
On Tue, 16 Jun 2015, Ulrich Neumerkel wrote:
My results on Sun Sparc are:
Version (yes, not the newest ones)
gprolog true 1.3.1
yap no 5.0.1
bp yes 4.0
xsb yes 3.0.1
Michael
Ulrich Neumerkel
Jun 17, 2015, 7:18:09 AM6/17/15
to
YAP 5.0.1 is about 2005-10. In the meantime a lot happened!
In any case, there is one system (yap), that is different in your
comparison. Hard to guess why, but older versions of yap did report
existence errors as failure (by default).
In any case, with YAP 6.3.4 everything is fine.
Michael Moeller
Jun 17, 2015, 9:50:18 AM6/17/15
to
If I remeber right, there were some installation issues with Yap >6 on
Sun Sparc. I'll see to it if I have time.
Michael
Ulrich Neumerkel
Jun 17, 2015, 12:17:08 PM6/17/15
to
Michael Moeller <mm...@t-online.de> writes:
>If I remeber right, there were some installation issues with Yap >6 on
>Sun Sparc. I'll see to it if I have time.
Try to
>If I remeber right, there were some installation issues with Yap >6 on
>Sun Sparc. I'll see to it if I have time.
?- set_prolog_flag(unknown, error).
And the rerun the goal.
(The standard says this is the default value, but if I remember
correctly, YAP starts with the value fail.)
mmoel
Jun 18, 2015, 5:44:01 AM6/18/15
to
before, the problem is Yap simply stops searching at
some point.
Yap
?- is_true(problem_in_kitchen).
> (1) call:is_true(problem_in_kitchen) ?
> (2) call:fact(problem_in_kitchen) ?
> (2) fail:fact(problem_in_kitchen) ?
> (3) call:if _92 then problem_in_kitchen ?
> (3) fail:if _92 then problem_in_kitchen ?
> (1) fail:is_true(problem_in_kitchen) ?
gprolog
is_true(problem_in_kitchen).
1 1 Call: is_true(problem_in_kitchen) ?
2 2 Call: fact(problem_in_kitchen) ?
2 2 Fail: fact(problem_in_kitchen) ?
2 2 Call: if _41 then problem_in_kitchen ?
2 2 Exit: if hall_wet and bathroom_dry then problem_in_kitchen ?
3 2 Call: is_true(hall_wet and bathroom_dry) ?
4 3 Call: fact(hall_wet and bathroom_dry) ?
4 3 Fail: fact(hall_wet and bathroom_dry) ?
4 3 Call: if _94 then hall_wet and bathroom_dry ?
4 3 Fail: if _94 then hall_wet and bathroom_dry ?
4 3 Call: is_true(hall_wet) ?
5 4 Call: fact(hall_wet) ?
5 4 Exit: fact(hall_wet) ?
4 3 Exit: is_true(hall_wet) ?
6 3 Call: is_true(bathroom_dry) ?
7 4 Call: fact(bathroom_dry) ?
7 4 Exit: fact(bathroom_dry) ?
6 3 Exit: is_true(bathroom_dry) ?
3 2 Exit: is_true(hall_wet and bathroom_dry) ?
1 1 Exit: is_true(problem_in_kitchen) ?
Ulrich Neumerkel
Jun 18, 2015, 10:50:27 AM6/18/15
to
mmoel <mi...@t-online.de> writes:
>
>
>On Wed, 17 Jun 2015, Ulrich Neumerkel wrote:
>
>> Michael Moeller <mm...@t-online.de> writes:
>>> If I remeber right, there were some installation issues with Yap >6 on
>>> Sun Sparc. I'll see to it if I have time.
>>
>> Try to
>>
>> ?- set_prolog_flag(unknown, error).
>>
>> And the rerun the goal.
>>
>> (The standard says this is the default value, but if I remember
>> correctly, YAP starts with the value fail.)
>>
>Thanks for the hint but this doesn't help. As stated
>before, the problem is Yap simply stops searching at
>some point.
>
>Yap
> ?- is_true(problem_in_kitchen).
> > (1) call:is_true(problem_in_kitchen) ?
> > (2) call:fact(problem_in_kitchen) ?
> > (2) fail:fact(problem_in_kitchen) ?
> > (3) call:if _92 then problem_in_kitchen ?
> > (3) fail:if _92 then problem_in_kitchen ?
...
>
>
>On Wed, 17 Jun 2015, Ulrich Neumerkel wrote:
>
>> Michael Moeller <mm...@t-online.de> writes:
>>> If I remeber right, there were some installation issues with Yap >6 on
>>> Sun Sparc. I'll see to it if I have time.
>>
>> Try to
>>
>> ?- set_prolog_flag(unknown, error).
>>
>> And the rerun the goal.
>>
>> (The standard says this is the default value, but if I remember
>> correctly, YAP starts with the value fail.)
>>
>Thanks for the hint but this doesn't help. As stated
>before, the problem is Yap simply stops searching at
>some point.
>
>Yap
> ?- is_true(problem_in_kitchen).
> > (1) call:is_true(problem_in_kitchen) ?
> > (2) call:fact(problem_in_kitchen) ?
> > (2) fail:fact(problem_in_kitchen) ?
> > (3) call:if _92 then problem_in_kitchen ?
> > (3) fail:if _92 then problem_in_kitchen ?
>gprolog
> is_true(problem_in_kitchen).
> 1 1 Call: is_true(problem_in_kitchen) ?
> 2 2 Call: fact(problem_in_kitchen) ?
> 2 2 Fail: fact(problem_in_kitchen) ?
> 2 2 Call: if _41 then problem_in_kitchen ?
> 2 2 Exit: if hall_wet and bathroom_dry then problem_in_kitchen ?
...
> is_true(problem_in_kitchen).
> 1 1 Call: is_true(problem_in_kitchen) ?
> 2 2 Call: fact(problem_in_kitchen) ?
> 2 2 Fail: fact(problem_in_kitchen) ?
> 2 2 Call: if _41 then problem_in_kitchen ?
> 2 2 Exit: if hall_wet and bathroom_dry then problem_in_kitchen ?
So ask:
?- (if X then problem_in_kitchen).
and if that does not work, ask
?- (if THEN).
As you said, that problem seems to be specific to SPARCs.
mmoel
Jun 18, 2015, 11:05:28 AM6/18/15
to
?- (if X then problem_in_kitchen).
?- (if THEN).
THEN = hall_wet and kitchen_dry then leak_in_bathroom ? ;
THEN = hall_wet and bathroom_dry then problem_in_kitchen ? ;
THEN = window_closed or no_rain then no_water_from_outside ? ;
THEN = problem_in_kitchen and no_water_from_outside then leak_in_kitchen ?
;
no
Answers 2 and 4 of the latter would be the solution, so
to say, but Yap doesn't draw this conclusion.
Michael
Ulrich Neumerkel
Jun 18, 2015, 11:32:59 AM6/18/15
to
mmoel <mi...@t-online.de> writes:
>The corresponding output is
>
> ?- (if X then problem_in_kitchen).
>no
> ?- (if THEN).
>THEN = hall_wet and kitchen_dry then leak_in_bathroom ? ;
>THEN = hall_wet and bathroom_dry then problem_in_kitchen ? ;
>THEN = window_closed or no_rain then no_water_from_outside ? ;
>THEN = problem_in_kitchen and no_water_from_outside then leak_in_kitchen ?
>;
>no
>
>Answers 2 and 4 of the latter would be the solution, so
>to say, but Yap doesn't draw this conclusion.
Then look how operators are defined.
>The corresponding output is
>
> ?- (if X then problem_in_kitchen).
>no
> ?- (if THEN).
>THEN = hall_wet and kitchen_dry then leak_in_bathroom ? ;
>THEN = hall_wet and bathroom_dry then problem_in_kitchen ? ;
>THEN = window_closed or no_rain then no_water_from_outside ? ;
>THEN = problem_in_kitchen and no_water_from_outside then leak_in_kitchen ?
>;
>no
>
>Answers 2 and 4 of the latter would be the solution, so
>to say, but Yap doesn't draw this conclusion.
?- op(Pri,Fix, if).
?- op(Pri,Fix, then).
?- op(Pri,Fix, and).
mmoel
Jun 18, 2015, 1:34:23 PM6/18/15
to
On Thu, 18 Jun 2015, Ulrich Neumerkel wrote:
Can we put this another way, or do I something wrong?
INSTANTIATION ERROR- op(_74,_75,if): expected bound value
Ulrich Neumerkel
Jun 19, 2015, 8:16:35 AM6/19/15
to
Also:
?- write_canonical(( hall_wet and bathroom_dry then problem_in_kitchen )).
mmoel
Jun 19, 2015, 10:43:32 AM6/19/15
to
Fix = fx,
Pri = 800 ?
yes
?- current_op(Pri, Fix, then).
Fix = xfx,
Pri = 700 ?
yes
?- current_op(Pri, Fix, or).
Fix = xfy,
Pri = 300 ?
yes
?- current_op(Pri, Fix, and).
Fix = xfy,
Pri = 200 ?
yes
...as it should be.
?- write_canonical(( hall_wet and bathroom_dry then problem_in_kitchen )).
Seems to be ok as well.
Ulrich Neumerkel
Jun 19, 2015, 11:41:38 AM6/19/15
to
I reproduced it with 5.0.1 on Linux. I suspected syntax, but
there was no problem, it's really something very internal,
probably related to indexing:
i(g(f(a,b),k)).
i(g(f(b,c),l)).
?- i(g(X,k)).
no
?- i(g(X,Y)).
X = f(a,b),
Y = k ? ;
X = f(b,c),
Y = l ? ;
no
In any case, current version do not have this problems. So at least
this is an issue of the past.
Actually, I suspected some operator related divergence, like
http://www.complang.tuwien.ac.at/ulrich/iso-prolog/conformity_assessment#147
and following. But fortunately, I was wrong.
mmoel
Jun 19, 2015, 3:00:32 PM6/19/15
to
On Fri, 19 Jun 2015, Ulrich Neumerkel wrote:
>
I worked quite a while with 5.0.1 back then but accidently
never came across this behaviour. However, as you said, it's
an issue of the past.
Btw, I'm using Prolog on an occasional basis only. The changes
in SWI7 and what you say in "SWI7 and ISO Prolog" are new to me.
My opinion regarding canonical syntax is pretty insignificant
but I agree with you. Not least because it is a math based
language.
Michael
Ulrich Neumerkel
Jun 22, 2015, 11:07:54 AM6/22/15
to
mmoel <mi...@t-online.de> writes:
>Btw, I'm using Prolog on an occasional basis only. The changes
>in SWI7 and what you say in "SWI7 and ISO Prolog" are new to me.
>My opinion regarding canonical syntax is pretty insignificant
>but I agree with you. Not least because it is a math based
>language.
Unfortunately, there are a lot of divergences some on
>Btw, I'm using Prolog on an occasional basis only. The changes
>in SWI7 and what you say in "SWI7 and ISO Prolog" are new to me.
>My opinion regarding canonical syntax is pretty insignificant
>but I agree with you. Not least because it is a math based
>language.
purpose some not. But since this departure it is
useless to report them.
0 new messages