15/05/2018 Aula 2 - SOAR tutorial 1 - Water-Jug | Ricardo Gudwin's Home Page

Login Register

Ricardo Gudwin's Home Page

HOME COURSES PUBLICATIONS NEW STUDENTS VITAE AGENDA

Guilherme de Almeida Home » Guilherme de Almeida

Aula 1 - Introdução Aula 2 - SOAR tutorial 1 - Water-Jug

Aula 2 - SOAR tutorial 1 - Water-
Jug
Aula 3 - SOAR Tutorial 2 - Eaters
Aula 4 - SOAR Tutorial 3 -
TankSoar
Aula 5 - SOAR Tutorial 4 e 5 -
Missionaries and Cannibals
Cursos
published by aluno3 on Tue, 03/19/2013 - 22:36
Aula 2 - SOAR: Tutorial 1
Atividade 1: Instalando o SOAR
Foi realizado download da última versão do SOAR para Mac OS.No pacote baixado estão incluidos os
tutorias, os programas de exemplo, documentação e o SoarJavaDebugger.
Abaixo a janela principal do SoarJavaDebugger:

EA773

EA872

EA975

EA976

IA006

IA889

IA941

Main menu

Home

Courses

Publications

New Students

Vitae

Agenda

Atividade 2: Construindo um Agente SOAR Simples usando Regras

Executando o Hello World do SOAR
O Soar debugger aceita arquivos textos para carregar as regras na memória de regras do SOAR.
Nesse exemplo simples, temos o primeiro contato com a linguagem dos programas SOAR:

Para carregar o código fonte, basta usar o comando "source <file_path>" na barra de comandos.
Após carregado o código fonte, o SOAR mostra ter registrado uma nova regra, para então rodarmos o
programa, executamos o comando "run".

http://faculty.dca.fee.unicamp.br/gudwin/node/171 1/8
15/05/2018 Aula 2 - SOAR tutorial 1 - Water-Jug | Ricardo Gudwin's Home Page

O programa hello world apenas causa que o agente, ao perceber sua existência, escreva o texto na tela e
desligue-se.

Utilizando a Memória de Trabalho

A memória de trabalho contém toda a informação dinâmica de um agente Soar sobre o mundo e suas
resoluções, além de dados de sensores, calculos intermediários, operações correntes e objetivos.

A memória de um agente Soar é organizada em estruturas como grafos. Todo elemento na memória de
trabalho está conectado de alguma maneira a um símbolo de estado, que representa o estado atual do
agente.

Segue uma simples demonstração de um mundo perceptível e sua representação na memória de trabalho:

Analisando a figura, podemos concluir que a percepção do agente do seu mundo é dada pelos nós e links no
grafo. Os nós podem ser de dois tipos, identificadores e constantes. Nós como S1, B1, B2 e T1, são
identificadores, pois podem ter extensões emanando a partir deles. E nós como state, blue e block são
valores constantes.

Os links que partem de um identificador são denominados 'atributos' e recebem o prefixo '^'.

No contexto do Soar, são chamados de objetos conjuntos de elementos de memória que compartilham o
mesmo primeiro identificador. Um objeto de memória de trabalho geralmente representa algo sobre o mundo,
como um bloco, um obstáculo, um pedaço de comida, ou uma célula em um tabuleiro.

http://faculty.dca.fee.unicamp.br/gudwin/node/171 2/8
15/05/2018 Aula 2 - SOAR tutorial 1 - Water-Jug | Ricardo Gudwin's Home Page
Embora não apresentado na figura acima, o Soar cria automaticamente uma estrutura base para todo agente:

O mecanismo de entrada e saída de dados no Soar se dá por meio dos atributos de I/O padrão em todos os
agentes criados pelo Soar. O identificador I1 em seu atributo ^input-link disponibiliza informações sensoriais
do mundo para dentro da memória de trabalho, de maneira similar, no identificador I2 em seu atributo
^output-link é onde são criados comandos de ação para a atuação do agente no mundo em que está
inserido. No nosso caso, como estamos trabalhando apenas no mundo virtual, então nossa entrada e saída
se dará pela deleção e adição de estruturas no estado atual, lembrando que o Soar não permite que os
valores constantes nos atributos dos identificadores sejam modificados, por isso removeremos e
adicionaremos estruturas, ao invés de simplesmente atualizarmos valores.

Atividade 3: Agentes Simples utilizando Operadores

Executando o Hello World com Operadores
Operadores realizam ações, tanto no mundo quanto internamente na mente do agente. Por conta disso, são
através dos operadores que acontecem as tomadas de decisão. Eles são onde o conhecimento é usado para
decidir o que fazer ou não. Portanto, a operaçào básica do Soar é um ciclo no qual operadores
continuamente propõem, selecionam e aplicam ações. Regras disparam proposições e aplicam operadores,
enquanto o processo de decisão seleciona operadores correntes. Isso pode parecer restritivo, no entanto, te
força a separar o lugar onde as decisões estão sendo tomadas do lugar onde estão sendo aplicadas.

No modelo onde usamos apenas regras convencionais, estariamos transitando de um estado para outro
deterministicamente, enquanto com o uso de operadores, podemos criar regras para propor ações para o
agente, que, observando seu estado atual aplica seu conhecimento corrente para tomar decisões e

http://faculty.dca.fee.unicamp.br/gudwin/node/171 3/8
15/05/2018 Aula 2 - SOAR tutorial 1 - Water-Jug | Ricardo Gudwin's Home Page
selecionar o operador que mais julgar adequado. Isso permite que o sistema aprenda e tome decisões mais
otimizadas, e não apenas siga deterministicamente as consequências de ações de regras anteriores.

Examinando a Memória de Trabalho

Para que o Soar use operadores, eles primeiro precisam ser criados na memória de trabalho por regras
proponentes. Regras proponentes testam características do estado para certificar que o operador é
apropriado, e então criam uma representação do operador na memória de trabalho, junto a um parâmetro de
preferência 'aceitável'. A preferencia é um modo de dizer à arquitetura que esse operador é um candidato
para seleção. Uma vez que o operador é selecionado, as regras que aplicam o operador irão conferir com o
estado atual e realizarão quaisquer ações apropriadas, através da criação ou remoção de elementos da
memória de trabalho. Através do debugger é possivel analisar as informações em um estado através do
comando 'print <s>', onde <s> é o identificador do estado. No nosso programa, o comando print s1 nos
devolve o seguinte:

(S1 ^epmem E1 ^io I1 ^operator O1 + ^operator O1 ^reward-link R1 ^smem S2 ^superstate nil ^type state)

Essa é a representação em primeiro nível do nosso objeto (uma vez que não estamos imprimindo os
conteúdos de E1, O1, S2, etc). Em análise, o atributo "^operador" é criado quando o operador hello-world é
selecionado. Apenas o operador selecionado tem um elemento na memória de trabalho sem o "+". Em
complemento ao operador selecionado, temos operadores concorrentes, que são os operadores marcados
com o simbolo "+", nesse caso temos apenas um, que é também o selecionado. Se tivessemos mais, todos
estariam marcados com "+", pois só podemos ter um operador selecionado por estado.

Atividade 4: Criando um Agente para o Water Jug Problem

O problema Water Jug é um problema clássico da IA, para o qual é necessário fazer uma busca em um
espaço de estado finito e limitado.

A proposta é a seguinte:
É lhe dado duas jarras vazias. Uma tem a capacidade de 5 gal de água e a outra 3 gal
Há uma fonte de água ilimitada que você pode usar para encher completamente as jarras.
Você pode também esvaziar uma jarra ou jogar água de uma jarra pra a outra.
Não há marca de nível intermediário nas jarras.
O objetivo é preencher a jarra de 3 gal com 1 gal.

Para representar os estados no problema Water-Jug teremos dois valores: a quantidade de água na jarra de
5 gal, e a quantidade de água na jarra de 3 gal. Por exemplo: 5:0,3:0 representando que a jarra de 5 gal tem
0 gal de água e a jarra de 3 tem 0 gal de água.

Abaixo segue o fluxo ótimo para a solução do problema mostrando os estados e as operações que são
aplicadas a cada estado.

(5:0,3:0) Complete a jara de 3 gal

(5:0,3:3) Despeje tudo da jarra de 3 gal para a de 5 gal jug
(5:3,3:0) Complete a jara de 3 gal
(5:3,3:3) Despeje a jara de 3 gal na jarra de 5 gal
(5:5,3:1) -> estado desejado

Persistência de WMEs
Quando a regra para inicializar o water-jug dispara, todas as estruturas em sua ação são adicionadas à
memória de trabalho. Nesse ponto, é desejável que o operador inicializador seja removido da memória de
trabalho para que outros operadores possam ser selecionados. E isso é exatamente o que o Soar faz, pois as
condições da regra proponente não se aplicam mais (pois ao checar a ausência da tarefa e das estruturas da
jarra, o programa verifica que elas já existem). Uma vez que a regra retrai, a regra de aplicação do operador
também não confere mais porque o operador não está mais na memória de trabalho. Portanto, não queremos
que a regra de aplicação remova as estruturas que ela mesmo criou quando não for mais válida. Se assim
fosse, o sistema nunca faria nenhum progresso - ele entraria em um loop infinito propondo e aplicando um
operador, retraindo seus resultados, e então propondo e aplicando o operador novamente.

Para suportar diferentes necessidades de resoluções diferentes de problemas diferentes (neste caso o de
propor e aplicar um operador), o Soar faz distinção entre a persistência de elementos da memória de trabalho
criados por ações de um operador e a persistência dos elementos da memória de trabalho criados por outros
tipos de regras. As ações de um operador precisam criar resultados persistentes, pois operadores são
decisões que o sistema tomou para mover-se para um estado novo no espaço do problema. Todas as outras
regras em Soar analisam e elaboram o estado corrente sem efetivamente mudá-lo e são retraídas quando
não se aplicam mais ao estado corrente. Essa é uma caracteristica muito importante do Soar - ele difere
entre conhecimento que modifica o estado atual (conhecimento que está nas ações dos operadores), e
conhecimento que calcula as consequências da situação atual (propondo quais operadores devem ser
considerados para o estado atual).

Elaboração de Estado
Regras que propõem operadores podem ser simplificadas adicionando atributos à objetos residindo na
memória de trabalho. Com o uso de regras de elaboração podemos calcular, por exemplo, baseado na
capacidade e no volume de água em um jarra, o tanto de água que falta para enxermos a jarra, e então
armazenar esse valor como um novo atributo, que no nosso caso o chamaremos de "^empty".

O uso dessas regras de elaboração é o que chamamos de elaboração do estado, pois estamos abstraindo
partes do nosso objeto em novos atributos na memória de trabalho.

http://faculty.dca.fee.unicamp.br/gudwin/node/171 4/8
15/05/2018 Aula 2 - SOAR tutorial 1 - Water-Jug | Ricardo Gudwin's Home Page
Regras de elaboração de estado são fortemente utilizadas em grandes projetos Soar, pois podem criar
abstrações úteis de outros elementos da memória de trabalho e representá-los diretamente no estado como
um novo atributo.

Proposição de Operadores
Em Soar, não há como dizer que uma instanciação é mais importante que outra, então devemos evitar
decisões quando realmente não precisamos decidir nada. Assim, em Soar, todas as regras que conferem
disparam ao mesmo tempo, em paralelo. É claro que o Soar está rodando em um computador serial, então
não está realmente em paralelo, mas para todos os efeitos, as regras disparam em paralelo. Esse paradigma
é bastante diferente da maioria das linguagens de programação e pode ser confuso quando percebermos
que as regras disparam assim que conferem.

Abaixo está uma analise mais completa do ciclo básico do Soar. Para esse problema não há entrada e saída,
então podemos ignora-los no diagrama. Começando da esquerda para a direita, as regras disparam (ou
retraem) para elaborar o estado ou propor operadores. Pode haver multiplas regras disparando (ou
retraindo), e o Soar continua a disparar ondas de regras até que nenhuma mais dispare (ou retraia). Uma vez
que não há mais regras para disparar (ou retrair), chegamos ao estado de quietude e então entramos com o
procedimento de decisão para selecionar o operador. Essa abordagem garante que quando uma decisão é
tomada, todo o conhecimento disponível nas regras está disponível nesse momento.

Aplicação de Operadores
No problema water-jug, há 3 operadores: fill, empty e pour. O Soar nos permite computar separadamente
quando operadores que podem ser aplicados (regras proponentes que criam preferências aceitáveis por
operadores) e operadores que poderiam ser aplicados (regras de controle de busca que criam outros tipos de
preferencias).

Abaixo temos a lista com cada operador e as condições sob as quais eles são válidos. Essas condições
serão a base para as propormos esses operadores.

Fill - preencha uma jarra com água da fonte, caso a jarra não estiver vazia.
Empty - esvazie uma jarra, caso haja água na jarra
Pour - despeje água de uma jarra para outra, caso haja água na jarra original e a jarra de destino não
esteja cheia.

Embora possamos tentar preenhcer uma jarra que já está cheia, em Soar, os operadores devem modificar o
estado de forma que outro operador possa ser selecionado. Para isso, na nossa implementação, preencher
uma jarra cheia deve ser proibido.

As regras que propõe nossos operadores descritos podem ser escritas como segue:

*proponha*fill
Se a tarefa for water-jug e há uma jarra que não está cheia,
então proponha preencher (fill) aquela jarra.

*proponha*empty
Se a tarefa for water-jug e há uma jarra que não está vazia,
então proponha esvaziar (empty) aquela jarra.

*proponha*pour
Se a tarefa for water-jug e há uma jarra que não está cheia e a outra não está vazia,
então proponha despejar (pour) água da segunda jarra para dentro da primeira jarra.

Dessa forma, os operadores então são escolhidos a partir da anaálise do estado atual contra as regras que
propõe operadores.

Monitoramento de Estados e Operadores

O monitoramento de regras é bastante útil para imprimir detalhes da aplicação dos operadores e no conteúdo
de cada estado. Uma das características boas do Soar é que todas as regras de monitoramento disparam em
paralelo com outras regras e não interferem na resolução de problemas.

Para criar um desses monitoramentos, basta criar uma regra que checa o estado atual, e como ação
simplesmente imprime informações relevantes ao processo de resolução do problema.

http://faculty.dca.fee.unicamp.br/gudwin/node/171 5/8
15/05/2018 Aula 2 - SOAR tutorial 1 - Water-Jug | Ricardo Gudwin's Home Page

Reconhecimento do Estado Desejado

O último passo para criar um programa que não só resolve o Water-Jug, mas sabe que o problema foi
resolvido, é criar uma regra que reconheça que o estado desejado foi atingido. É preciso escrever uma regra
que reconhece o estado quando a jarra de 3 gal tem 1 gal de água. A ação dessa regra deve ser imprimir a
mensagem de que o problema foi resolvido e desligar.

Tal regra poderia ser escrita da seguinte forma:

Se a tarefa é water-jug e há uma jarra com volume igual a 3 e conteúdo igual a 1, escreva que o problema foi
resolvido e desligue.

Outra abordagem para esse problema que é comumente usada é criar uma representação do estado
desejado na memória de trabalho, e escrever uma regra que compara o estado desejado com o estado atual.
Há duas vantagens para essa solução. Primeiro, se você quer tentar resolver mais de um Water-Jug, um
novo estado desejado pode ser definido modificando a memória de trabalho, ao invés de modificar a regra
que checa pelo estado desejado.

Na regra abaixo criamos o estado desejado como um atributo do nosso estado (essa regra será disparada
em paralelo com a inicialização do problema):

Abaixo a regra que reconhece o estado desejado comparando o que criamos na memória de trabalho:

E finalmente o debugger exibe que o programa resolveu o problema:

http://faculty.dca.fee.unicamp.br/gudwin/node/171 6/8
15/05/2018 Aula 2 - SOAR tutorial 1 - Water-Jug | Ricardo Gudwin's Home Page

Controle de Busca
Para evitar que o Soar aplique o mesmo operador duas vezes seguidas, é necessário que o programa tenha
registro do último operador aplicado, e no Soar isso não é automatico. Teremos que criar regras para gravar o
último operador aplicado.

O registro de um operador tem duas partes, a primeira é criar a estrutura no estado que representará o
operador mais recente. O segundo é remover qualquer registro de um operador antigo.

Tal regra pode ser traduzida da seguinte forma:

Se a tarefa é 'water-jug' e a operação 'pour' está selecionada, então crie um atributo (ultimo-operador) no
estado atual com o nome do operador e uma cópia de seus atributos.

http://faculty.dca.fee.unicamp.br/gudwin/node/171 7/8
15/05/2018 Aula 2 - SOAR tutorial 1 - Water-Jug | Ricardo Gudwin's Home Page

Conclusão
O Soar é uma poderosa ferramenta que possibilita a criação de mentes artificiais, através de uma linguagem
de programação é possível definir regras que modificam o estado do agente virtual, que propõem e aplicam
ações, que monitoram o estado do agente, etc. E deixamos a cargo do próprio agente escolher quais ações e
caminhos tomar, baseado no conhecimento adquirido nas decisões passadas. Através de regras de
elaboração de estado é possível abstrair partes da memória de trabalho do agente e fazê-lo perceber
diferentes aspectos do mundo no qual está inserido. A capacidade de criar abstrações e tomar decisões
sobre quais ações tomar é o que difere o Soar de sistemas especialistas convencionais, no qual temos
apenas redes de proposições e regras que serão testadas e nos levarão à conclusões de forma cega.

As semelhanças com sistemas especialistas está apenas no fato de que ambos trabalham com regras e
proposições.

‹ Aula 1 - Introdução up Aula 3 - SOAR Tutorial 2 - Eaters ›

Powered by Drupal

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer

http://faculty.dca.fee.unicamp.br/gudwin/node/171 8/8