Thu Nov 21 23:52:35 2024
EVENTS
 FREE
SOFTWARE
INSTITUTE

POLITICS
JOBS
MEMBERS'
CORNER

MAILING
LIST

NYLXS Mailing Lists and Archives
NYLXS Members have a lot to say and share but we don't keep many secrets. Join the Hangout Mailing List and say your peice.

DATE 2015-12-01

LEARN

2024-11-21 | 2024-10-21 | 2024-09-21 | 2024-08-21 | 2024-07-21 | 2024-06-21 | 2024-05-21 | 2024-04-21 | 2024-03-21 | 2024-02-21 | 2024-01-21 | 2023-12-21 | 2023-11-21 | 2023-10-21 | 2023-09-21 | 2023-08-21 | 2023-07-21 | 2023-06-21 | 2023-05-21 | 2023-04-21 | 2023-03-21 | 2023-02-21 | 2023-01-21 | 2022-12-21 | 2022-11-21 | 2022-10-21 | 2022-09-21 | 2022-08-21 | 2022-07-21 | 2022-06-21 | 2022-05-21 | 2022-04-21 | 2022-03-21 | 2022-02-21 | 2022-01-21 | 2021-12-21 | 2021-11-21 | 2021-10-21 | 2021-09-21 | 2021-08-21 | 2021-07-21 | 2021-06-21 | 2021-05-21 | 2021-04-21 | 2021-03-21 | 2021-02-21 | 2021-01-21 | 2020-12-21 | 2020-11-21 | 2020-10-21 | 2020-09-21 | 2020-08-21 | 2020-07-21 | 2020-06-21 | 2020-05-21 | 2020-04-21 | 2020-03-21 | 2020-02-21 | 2020-01-21 | 2019-12-21 | 2019-11-21 | 2019-10-21 | 2019-09-21 | 2019-08-21 | 2019-07-21 | 2019-06-21 | 2019-05-21 | 2019-04-21 | 2019-03-21 | 2019-02-21 | 2019-01-21 | 2018-12-21 | 2018-11-21 | 2018-10-21 | 2018-09-21 | 2018-08-21 | 2018-07-21 | 2018-06-21 | 2018-05-21 | 2018-04-21 | 2018-03-21 | 2018-02-21 | 2018-01-21 | 2017-12-21 | 2017-11-21 | 2017-10-21 | 2017-09-21 | 2017-08-21 | 2017-07-21 | 2017-06-21 | 2017-05-21 | 2017-04-21 | 2017-03-21 | 2017-02-21 | 2017-01-21 | 2016-12-21 | 2016-11-21 | 2016-10-21 | 2016-09-21 | 2016-08-21 | 2016-07-21 | 2016-06-21 | 2016-05-21 | 2016-04-21 | 2016-03-21 | 2016-02-21 | 2016-01-21 | 2015-12-21 | 2015-11-21 | 2015-10-21 | 2015-09-21 | 2015-08-21 | 2015-07-21 | 2015-06-21 | 2015-05-21 | 2015-04-21 | 2015-03-21 | 2015-02-21 | 2015-01-21 | 2014-12-21 | 2014-11-21 | 2014-10-21

Key: Value:

Key: Value:

MESSAGE
DATE 2015-12-01
FROM Ruben Safir
SUBJECT Subject: [Learn - LIU Comp Sci] CLIPS
From learn-bounces-at-nylxs.com Tue Dec 1 12:55:31 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: from www.mrbrklyn.com (www.mrbrklyn.com [96.57.23.82])
by mrbrklyn.com (Postfix) with ESMTP id E402C16112C;
Tue, 1 Dec 2015 12:55:30 -0500 (EST)
X-Original-To: learn-at-nylxs.com
Delivered-To: learn-at-nylxs.com
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89])
by mrbrklyn.com (Postfix) with ESMTP id 6DB1316112B
for ; Tue, 1 Dec 2015 12:28:45 -0500 (EST)
Received: from [10.0.0.19] (www.mrbrklyn.com [96.57.23.82])
by mailbackend.panix.com (Postfix) with ESMTPSA id D4481168A7;
Tue, 1 Dec 2015 12:28:44 -0500 (EST)
To: Mohammed Ghriga ,
Ping-Tsai Chung , learn-at-nylxs.com
From: Ruben Safir
Message-ID: <565DD8CC.9060403-at-panix.com>
Date: Tue, 1 Dec 2015 12:28:44 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.3.0
MIME-Version: 1.0
Subject: [Learn - LIU Comp Sci] CLIPS
X-BeenThere: learn-at-nylxs.com
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: LIU Computer Science Department Student Lists
List-Unsubscribe: ,

List-Archive:
List-Post:
List-Help:
List-Subscribe: ,

Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Errors-To: learn-bounces-at-nylxs.com
Sender: "learn"

I stumbled on this today and it is worth reading

https://groups.google.com/forum/#!topic/CLIPSESG/wKKxsFSv4lc


CLIPSESG =E2=80=BA
Expert system / CLIPS vs traditional programming
8 posts by 5 authors
Gene =

10/7/08
Other recipients: CLIP...-at-googlegroups.com
I'd like to create a tool to help diagnose problems with a complex
computer based system that I work with. I know little about expert
systems, but have done some reading, and read through most of the
CLIPS tutorial.

In looking at CLIPS, I was anticipating an "aha!" moment where I would
see how a rule based system would make development of my application
simpler, more maintainable, etc. But that never really happened.

I think my application is complex enough to justify something like an
expert system (my gut feel). But even though it is complex, it seems
like I could create a decision graph of how you'd diagnose the system.
The graph will be very big and complicated, and not all the decision
points will be black/white. But once that is done, it I think it would
be much easier (for me) to implement it in perl, rather than learn a
rule based system.

Anyone else struggle with this question? Compared to to conventional
programming in perl, a rule based system might be more interesting,
and certainly more cool. But I'd like to justify it in my mind, as
well as my colleagues.

Johan Lindberg =

10/8/08
Other recipients: CLIP...-at-googlegroups.com
Hi Gene,

> Anyone else struggle with this question?

Yes. I struggle with this question *all* the time.

> I think my application is complex enough to justify something like an
> expert system (my gut feel). But even though it is complex, it seems
> like I could create a decision graph of how you'd diagnose the system.
> The graph will be very big and complicated, and not all the decision
> points will be black/white. But once that is done, it I think it would
> be much easier (for me) to implement it in perl, rather than learn a
> rule based system.

The textbook answer to questions like this is that you should use a
rule engine (such as CLIPS) when the problem is "ill-structured and
difficult or impractical to formulate as an algorithm" or when "the
problem requires a growing or changing knowledge-base" and in all
other situations you're better off with another type of solution.

The only trouble is that most problems (such as yours) is somewhere in
the middle and whether it's leaning towards a rule engine solution, or
an OO-solution, or a functional solution, or whatever else you might
think of depends on how familiar you and your team are with the
various concepts.

Here are a few things to think about:

How many of the decision points are black/white? Will they stay that
way? What does it take to reach a decision when they are not? How many
of the non black/white depend on the state of the traversal and how
many can never be solved without human interaction? Will your decision
tree grow? Will decision points change? How much? How often? Is it
*really* a tree (rooted, directed, acyclic graph) or can it be
traversed in many different ways? If it really is a tree, will it stay
that way always?

Say you develop your application in Perl. You've got it all down,
you're on time *and* on budget. Everyone's happy. But now, a year
later, you have to modify it. What happens? What would it take to make
either of (or all of) those changes in your Perl code?

If you design the application with these types of changes in mind you
might end up with a too complex application that won't ever fully be
used (and you'll probably find striking similarities between your code
and a rule engine ;-). But on the other hand, if you don't do that,
you'll end up with an application that is difficult to modify once the
requirements change.

I would personally go with a rule engine approach because it will let
you focus on the actual decision tree instead of the boiler plate code
that you're going to have to get working first.

However, if you can't get anyone else in your company to "buy-in" on
the rule engine approach. I don't think you should do it. Regardless
of whether you think a rule engine is the best tool or not. It's
difficult enough (even when you're not straying from the expected
path) to defend your design decisions.

HTH
Johan Lindberg
jo...-at-pulp.se

Billy Patton =

10/8/08
Other recipients: CLIP...-at-googlegroups.com
Over the years I have tried to come up with a use for using CLIPS.
I have a belief it is my think pattern for designing.
I have been writing in perl since 3.0 was new. Everytime I try and
create something in CLIPS.
I'm still thinking perl and serial flow.
I'm guilty of :
1. doing clips and thinking perl.
2. looking at clips as a rapid prototype tool only. which keeps me
thinking perl/c/c++ (how can I convert it)
3. my projects that I have tried to apply it to all occur in a chain,
not int a tree

In the late 80 early 90's I tried to use a tool, from Infrence Engine,
too many facts for CLIPS, to design a silicon compiler for BiPolar IC
cell layouts. I kept it in a strait line, where each step depended on a
previous step. I didn't get very far with this project. Couldn't get
my head strait.

What does this have to do with your question?
I've forgotten.
just my $0.02

I still keep a copy of the most recent version of CLIPS in my tool box,
waiting for that right project. I rebuild the makefile every release so
that I can put clips into libclips.a . I maintain the command line
interface version and I have a command line version thah I can pass
rules file, fact file and watch switches. Allows me to run in batch mode..


----- Original Message ----
From: Gene
To: CLIPSESG
Sent: Tuesday, October 7, 2008 4:54:33 PM
Subject: Expert system / CLIPS vs traditional programming


I'd like to create a tool to help diagnose problems with a complex
computer based system that I work with. I know little about expert
systems, but have done some reading, and read through most of the
CLIPS tutorial.

In looking at CLIPS, I was anticipating an "aha!" moment where I would
see how a rule based system would make development of my application
simpler, more maintainable, etc. But that never really happened.

I think my application is complex enough to justify something like an
expert system (my gut feel). But even though it is complex, it seems
like I could create a decision graph of how you'd diagnose the system.
The graph will be very big and complicated, and not all the decision
points will be black/white. But once that is done, it I think it would
be much easier (for me) to implement it in perl, rather than learn a
rule based system.

Anyone else struggle with this question? Compared to to conventional
programming in perl, a rule based system might be more interesting,
and certainly more cool. But I'd like to justify it in my mind, as
well as my colleagues.




ciapistess =

10/8/08
Other recipients: CLIP...-at-googlegroups.com
This discussion fires my bigger concern about CLIPS and expert-systems
in general.
I (as everybody, I believe) learned more about programming reading
existent projects than from reference manuals and guides. They teached
me tricks, smart solutions, libraries, etc, and they gave me a clear
idea of the pertinence of each specific language to a problem.
With CLIPS I find instead very difficult to discover real projects to
learn from.
It would be great to find in this forum an up to date list of open
source projects written for CLIPS.

Andrea.

Johan Lindberg ha scritto:
- show quoted text -

Gene =

10/8/08
Other recipients: CLIP...-at-googlegroups.com
Thanks for all the great feedback. I guess I feel good that it's not
an issue of me being so thick that I just don't "get it." On the other
hand, I'd rather have been clued into the obvious fact that would give
a clear answer to my question. ;-)

Anyhow, I think I'm going to give CLIPS a go. Fortunately I won't be
questioned on the decision. I'm hoping that as I go along, it will be
more clear that I made the right decision, and then I can explain why
it was the right choice ;-) If successful, thie application will
continuously evolve over time as new problems are found and new
stategies are learned. As I think it true for many critical systems,
the operations people running them are faced with a constant stream of
new failure modes to be aware of, new troubleshooting techniques, etc.

I agree that if I did this in perl, it would be a data-driven
approach, as I've done in the past. I would essentially create some
kind of decision graph engine that would have to be enhanced as new
needs were discovered. I would probably work myself in a corner a few
times, and have to redesign it.

Finally, I agree that good examples always help. It is tricky
sometimes to find a small example that demonstrates a concept well. As
was mentioned, when I look at some of the simple CLIPS examples I
immediately think how it could be done easier in a procedural
language. I assume they don't do justice to the CLIPS approach

One more "newbie" question - I do a lot of work in C++ and use OO for
any non-trivial app. On the other hand, I never have used OO in perl
and never thought I was missing anything. Maybe this is because my C++
work is more formal and complex applications, and my perl work tends
to be "simple" tools that occasionally grow to be big.

In the case of CLIPS, what do people think about using OO? Do you
think it helps a lot, or was OO added to CLIPS simply to make it
"modern" (the tutorial devotes a lot of space on the basics of OO and
its advantages).

On Oct 8, 8:00 am, "ciapist...-at-gmail.com"
wrote:
- show quoted text -
> > jo...-at-pulp.se- Hide quoted text -
>
> - Show quoted text -
RIC_CLIPS =

10/8/08
Other recipients: CLIP...-at-googlegroups.com
Dear Gene, I recommend to you that for the project that your you want to
realize in CLIPS, you look for the way of contact you by mail with PH.
D. Giarratano and Gari Riley in the NASA, since they were those that
developed the CLIPS and can give you a even greater knowledge exceeds
what it is possible to be done in CLIPS. I make a thesis in CLIPS in the
2003, was to me very complicated, but what your you want to do with
CLIPS very she is elevated.

In a 2003 group of Developers of Spain, they were working in a visual
version of CLIPS, I do not know in that finished this development,
although I know that they finished its visual prototype. Perhaps for the
graphical interphases if the visual CLIPS created by the Spanish can
help you.

Greetings!

-- =

_______________________________________________
correl electr=C3=B3nico gratuito con 250 MB de capacidad y en 100 dominios
distintos a elegir s=C3=B3lo en http://mail.mailmonstruo.com


RIC_CLIPS =

10/8/08
Other recipients: CLIP...-at-googlegroups.com
This development what want develop in CLIPS is very difficult and dont
know if CLIPS supports and graphical interface, but is a great project..
Regards!
-- =


_______________________________________________
http://mail.mexico.com
=C2=A1Disponible Ya! Utiliza el Outlook y Outlook Express para bajar tus
correos por solo US$24.95 al a=C3=B1o

Now available! Download your mail into your computer with Outlook and
Outlook Express US$24.95/yr

Johan Lindberg =

10/17/08
Other recipients: CLIP...-at-googlegroups.com
Hi again,

> Thanks for all the great feedback. I guess I feel good that it's not
> an issue of me being so thick that I just don't "get it." On the other
> hand, I'd rather have been clued into the obvious fact that would give
> a clear answer to my question. ;-)

Yeah, I know what you mean. If you find the bald, black guy with the
funny shades and colored pills: have him call me as well ;-)

> Finally, I agree that good examples always help. It is tricky
> sometimes to find a small example that demonstrates a concept well. As
> was mentioned, when I look at some of the simple CLIPS examples I
> immediately think how it could be done easier in a procedural
> language. I assume they don't do justice to the CLIPS approach
>
> ...
>
> In the case of CLIPS, what do people think about using OO? Do you
> think it helps a lot, or was OO added to CLIPS simply to make it
> "modern" (the tutorial devotes a lot of space on the basics of OO and
> its advantages).

True. It's very difficult to find a small and simple example that
isn't "easier" to solve with a procedural implementation. When I asked
around about this, it was suggested to me that the Wine demo is
probably quite difficult to do in another language and shows the
strengths of rules-based programming quite well.

But, anyway. That is exactly why CLIPS support both the procedural
(using deffunction) and OO (using defclass+ defmethod) approaches. I
guess it all comes down to whether you think of CLIPS as a tool for
building Expert Systems or as a full blown programming language and
runtime environment. Not as fully packed with bright shiny features as
maybe, but still.

Good luck with your project.

BR
Johan Lindberg
jo...-at-pulp.se


-- =

So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
_______________________________________________
learn mailing list
learn-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/learn

  1. 2015-12-01 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [Learn - LIU Comp Sci] All the Clips discussions with the writer of
  2. 2015-12-01 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn - LIU Comp Sci] CLIPS
  3. 2015-12-06 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [Learn - LIU Comp Sci] Fwd: Artificial Intelligence
  4. 2015-12-07 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn - LIU Comp Sci] remembering Aaron Schwartz
  5. 2015-12-07 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn - LIU Comp Sci] remembering Aaron Schwartz
  6. 2015-12-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn - LIU Comp Sci] Big Data and Track Abuses
  7. 2015-12-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn - LIU Comp Sci] Happy Chanukah!
  8. 2015-12-09 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn - LIU Comp Sci] studying
  9. 2015-12-10 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn - LIU Comp Sci] Fwd: Why are my triggers not predictable?
  10. 2015-12-10 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [Learn - LIU Comp Sci] Fwd: Artificial Intelligence
  11. 2015-12-10 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [Learn - LIU Comp Sci] Fwd: CLIPS Fwd: Why are my triggers not
  12. 2015-12-15 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn - LIU Comp Sci] Free Software for Education
  13. 2015-12-22 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn - LIU Comp Sci] Fwd: Re: the position
  14. 2015-12-23 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn - LIU Comp Sci] Fwd: [Frum Jewish Jobs] Telecommunications

NYLXS are Do'ers and the first step of Doing is Joining! Join NYLXS and make a difference in your community today!