[lisp]waarom lisp voor ai/kennissystemen?

Pagina: 1
Acties:
  • 111 views sinds 30-01-2008
  • Reageer

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
Wat zijn de eigenschappen van Lisp die Lisp zo interessant maken voor ai en kennis systemen? Dus wat biedt lisp (afgezien van veel silly haakjes) extra dan bv prolog of een gewone imperatieve taal.

Verwijderd

Ik ben geen expert op expertsysteemgebied (verre van zelfs), maar wel een geinterresseerde leek. Daarom heb ik me ooit bij de Slechte het boek 'Principles of expert systems' (Addison Wesley) aangeschaft. Daarin staat het volgende over Lisp:
'In the early years, expert systems where usually written in a high level programming language. LISP, in particular, was frequently chosen for the implementation language. When using a high level language as an expert system building tool, however, one has to pay a disproportionate amount of attention to the implementational aspects of the system wich have nothing to do with the field to be modelled.
Vervolgens wordt er uitgelegd dat dit soort systemen (in LISP) vaak een slechte scheiding hadden tussen de 'expert knowledge' en de algorithmen die daarmee werken. Om die systemen achteraf aan te passen is dan niet eenvoudig.

Daarom is men volgens dit boek later meer overgegaan op andere talen zoals Prolog, waarin de data en de regels beter te scheiden zouden zijn.

Maar ik zal hier niet een beetje de expert uit gan hangen, terwijl ik nog nooit iets in Prolog of Lisp heb gedaan :). Ik hoopte hiermee meer een intewressante discussie op gang te helpen. (Zelf ben ik weleens hobbiematig aan het stoeien met programma's die natuurlijke taal moeten begrijpen, en simpele logica moeten kunnen toepassen, maar ik gebruik voornamelijk 'gewone' proceduregerichte talen...)

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 22-08 01:56
Ik snap sowieso het nut van Lisp niet echt; het is nogal onleesbaar en eigenlijk daardoor ook onschrijfbaar, en qua mogelijkheden valt er weinig te winnen ten op zichte van een functionele taal (die doorgaans veel betere typesystemen kennen).

Het idee van Prolog/Lisp als expert systemen is waarschijnlijk dat je dingen als 'feiten' en 'regels' al in je code representeert en dat de mechanismen om die gegevens te manipuleren al bestaande taalconstructies zijn. Als je zoiets in C zou schrijven, ben je eigenlijk een soort Prolog-interpreter aan het schrijven. Ik kan me het punt wat AtariJunkie maakte dan ook goed voorstellen: je scheiding tussen Prolog/Lisp code en de gegevens waar ze op werken, wordt al snel met elkaar verweven (al snap ik niet echt waarom Prolog op dit vlak beter zou zijn dan Lisp).

Ik mis sowieso het nut van Prolog voor echte AI toepassingen. Alleen inductiealgoritmen zijn redelijk eenvoudig te implementeren (omdat die al onderdeel uitmaken van de taal), maar daar draait een beetje C-programmeur ook z'n hand niet voor om (meer dan backtracken en pattern matchen is het niet).

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
Soultaker schreef op 06 juni 2003 @ 12:47:
Ik mis sowieso het nut van Prolog voor echte AI toepassingen. Alleen inductiealgoritmen zijn redelijk eenvoudig te implementeren (omdat die al onderdeel uitmaken van de taal), maar daar draait een beetje C-programmeur ook z'n hand niet voor om (meer dan backtracken en pattern matchen is het niet).
Prolog heeft ook rules en dat is eigelijk een extreem krachtig mechanisme. Een prolog kan je vergelijken met een functie als je alle waarden invult, maar je kan een argument ook als uitvoer argument gebruiken als je niet alle waarden invult. En verder heeft Prolog afgezien van patterns en backtracking (en daardoor overzichtelijkere algoritmes) niet veel extra te bieden.

In het systeem waar ik nu mee bezig ben kan je imperatief (zoals je dat ook kent bij pascal ed) maar ook declaratief (prolog rules, backtracking) door elkaar heen programmeren.

code:
1
2
3
4
5
6
7
8
9
10
function foo():Void
     begin
           var oplossing:=somGroterDan10(5, var j);
           printLn("oplossingen gevonden: "+oplossingen);
           printLn("oplossingen zijn: "+j);
     end;

rule somGroterDan10(x: Int, y: Int)
    =  x+y>10
    ;


Je krijgt dan keurig 6,7,8.... etc op je scherm. Ik moet er nog wel even bij vermelden dat voor de headervariablen x en y op dit moment voor de -50..50 wordt gekozen als er geen invoerwaarde beschikbaar is. Er komt nog een beter mechanisme in hiervoor, maar dit was alleen proof of concept.

[ Voor 8% gewijzigd door Alarmnummer op 06-06-2003 13:33 ]


  • Soultaker
  • Registratie: September 2000
  • Laatst online: 22-08 01:56
Alarmnummer schreef op 06 June 2003 @ 13:26:
Prolog heeft ook rules en dat is eigelijk een extreem krachtig mechanisme. Een prolog kan je vergelijken met een functie als je alle waarden invult, maar je kan een argument ook als uitvoer argument gebruiken als je niet alle waarden invult.
Jammer dat dit mechanisme in de Prolog-implementaties die ik ken ofwel om zeep geholpen worden door een typesysteem dat een bepaalde richting vereist (zoals in VisualProlog) ofwel niet efficient te implementeren valt (wat ik weer gek vind, aangezien me lijkt dat je alle mogelijke verschijningsvormen apart zou kunnen coderen). Verder vind ik het nou ook weer niet zo'n wonderbaarlijk mechanisme, aangezien het 'omkeren' maar voor een beperkte verzameling van mogelijke predicates efficient werkt.
In het systeem waar ik nu mee bezig ben kan je imperatief (zoals je dat ook kent bij pascal ed) maar ook declaratief (prolog rules, backtracking) door elkaar heen programmeren.
code:
1
2
3
4
5
6
7
8
9
10
function foo():Void
     begin
           var oplossing:=somGroterDan10(5, var j);
           printLn("oplossingen gevonden: "+oplossingen);
           printLn("oplossingen zijn: "+j);
     end;

rule somGroterDan10(x: Int, y: Int)
    =  x+y>10
    ;
In Prolog is dit al onmogelijk (hoe eenvoudig het ook lijkt), omdat op die "x + y" niet te backtracken valt. Alleen met lijsten en symbols valt fatsoenlijk te werken, maar dat zijn geen waarden (alleen structuren van symbolen), terwijl waarden in een programmeertaal ook erg belangrijk zijn.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
Soultaker schreef op 06 June 2003 @ 13:51:
In Prolog is dit al onmogelijk (hoe eenvoudig het ook lijkt), omdat op die "x + y" niet te backtracken valt.
Wel als je zelf een lijst aanbied met de items waarover hij kan backtracken.

rule somGroterDan10(x,y: Int from -10 to 10)
bv

Maar idd, prolog vind dit niet zo leuk :)
Alleen met lijsten en symbols valt fatsoenlijk te werken, maar dat zijn geen waarden (alleen structuren van symbolen), terwijl waarden in een programmeertaal ook erg belangrijk zijn.
Ik wil het zelf gaan koppelen aan records die dmv een ejb server vanuit de database worden geleverd. Prolog doet het gewoon door domweg in zijn geheugen te kijken en ieder geschikt fact te proberen. Ik wil er zelf iets meer controle over hebben, dus je zult uiteindelijk zoiets moeten doen:

code:
1
2
3
4
5
6
7
8
9
rule parent(x,y: Persoon from foo)
    = x.sofinr = y.vaderNr
     | x.sofinr = y.moederNr
     ;

rule ancestor(x,y: Persoon from foo)
    = parent(x,y)
    | parent(x, var z) & ancestor(z,y)
    ;

Mbv die foo (een lijst van personen) kan je een selectie aanbrengen over welke records het backtracken plaats vind. Ik moet dit gedeelte nog helemaal uitwerken.

[ Voor 15% gewijzigd door Alarmnummer op 06-06-2003 14:03 ]


  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
Ik kick hem nog een keer omhoog in de hoop dat topic niet doodbloed.
Pagina: 1