From: ELB
Subject: Student in need of prolog help!!!
Date: 
Message-ID: <a0d59a$2kt$1@helle.btinternet.com>
hi all,
I'm a student (not wanting to cheat)  currently taking a module in further
prolog, but am stuck as to how to complete an exercise giving to me.  I'm
not a cheat, but just require some pointing in the right direction.  the
task involves using Bayes theorem to find the probability of a disease from
a list of symptoms being asked in the form of questions.  I have found how
to use bayes theorem, but am stuck how to get the best disease from the
symptoms asked.  really I am looking to developing an expert system shell
(like EMYCIN) that can be used with an data and list of symptoms and
diseases so that it can be scaleable (it only needs to be use breath-first
searching really - due to time constraint .. has to be submitted in 3 weeks
time).

If anyone is out there who can give me some pointers I will be very
thankfully.

Cheers

ELB (a student in need a Christmas time)

From: Kaz Kylheku
Subject: Re: Student in need of prolog help!!!
Date: 
Message-ID: <2VHW7.54815$OY3.2041472@news3.calgary.shaw.ca>
In article <············@helle.btinternet.com>, ELB wrote:
>hi all,
>I'm a student (not wanting to cheat)  currently taking a module in further
>prolog, but am stuck as to how to complete an exercise giving to me.

Indeed, it is quite obvious you don't want to cheat. Because then you'd
be cunning enough to go to comp.lang.prolog, right?
From: ELB
Subject: Re: Student in need of prolog help!!!
Date: 
Message-ID: <a0flhl$q01$1@helle.btinternet.com>
Tried there already .. but now i'm getting desperate!!!
:(

ELB

"Kaz Kylheku" <···@ashi.footprints.net> wrote in message
····························@news3.calgary.shaw.ca...
> In article <············@helle.btinternet.com>, ELB wrote:
> >hi all,
> >I'm a student (not wanting to cheat)  currently taking a module in
further
> >prolog, but am stuck as to how to complete an exercise giving to me.
>
> Indeed, it is quite obvious you don't want to cheat. Because then you'd
> be cunning enough to go to comp.lang.prolog, right?
From: Kaz Kylheku
Subject: Re: Student in need of prolog help!!!
Date: 
Message-ID: <THJW7.55406$OY3.2070026@news3.calgary.shaw.ca>
In article <············@helle.btinternet.com>, ELB wrote:
>hi all,
>I'm a student (not wanting to cheat)  currently taking a module in further
>prolog, but am stuck as to how to complete an exercise giving to me.  I'm
>not a cheat, but just require some pointing in the right direction.  the
>task involves using Bayes theorem to find the probability of a disease from
>a list of symptoms being asked in the form of questions.  I have found how
>to use bayes theorem, but am stuck how to get the best disease from the
>symptoms asked.

Pardon my possible stupidity, but wouldn't the best disease be the
one that has the highest probability? If, for each diseases known to
your program, you can compute a probability with respect to the set of
symptoms, which you said you know how to do, the highest probability
one must be the best match, according to the probabilistic reasoning
implied by this model. A disease that is a 75% match for the symptoms
is more likely to be the correct diagnosis than one which is a 40% match,
right? So there is an obvious, albeit exhaustive way to find the answer.

> really I am looking to developing an expert system shell
>(like EMYCIN) that can be used with an data and list of symptoms and
>diseases so that it can be scaleable (it only needs to be use breath-first
>searching really - due to time constraint .. has to be submitted in 3 weeks
>time).

That is now a question about optimizing the search. Some diseases are
obvious bad matches for the symptoms, and can likely be pruned from the
search without affecting the reliability of the results. This may be a
good question for comp.ai or comp.theory, which deal with algorithms.

I'd just implement an unoptimized solution, and then optimize it later.
It may be better to have a slow something that works at the end of the
three weeks, then to have a half-optimized something that doesn't work.

Any program that doesn't work can be optimized down to one really fast
line, which just terminates with an unsuccessful indication to the
operating system. ;)

Suppose you really had a patient by your side and you wanted to use the
computer to make a diagnosis, having only the raw data but no program. You
could spend three weeks writing and optimizing your program, so that
it runs in five minutes. Meanwhile, the patient gets progressively
worse. Or you could hack it up in a few hours, then have it compute for
a few more hours to give you the likely diagnosis.

Speed becomes important as the program matures and becomes more and more
widely deployed, and users learn to trust it and increasingly rely on it
in more critical situations, where a fast diagnosis is crucial.