Mas vamos adicionar ao requisito principal ( comparar objetos) um outro requisito que diz respeito a impossibilidade de alterarmos a implementação atual dos objetos em questão (ex: estes objetos estão ‘trancados’ em um assembly que não temos acesso / não são de nossa responsabilidade) e, existe também a necessidade de obtermos o máximo de performance desta rotina. Um detalhe importante relativo ao lado da performance é que, eventualmente, poderemos trabalhar com objetos muito grandes e complexos (propriedades com lista / dicionários de outros tipos do sistema) que mudam com o tempo sem que todos os envolvidos no projeto sejam notificados. Agora ficou divertido!

Pra que toda a solução proposta aqui no post fique bem clara (e ninguém queira me queimar sob acusação de magia negra), vamos começar bem do começo.

Extension Methods – Parte Zero

Extension Methods apareceram no universo .Net na versão 3.5 do framework como forma de permitir aos desenvolvedores realizar alterações (extensões, pra ser mais preciso e fazer jus ao nome da parada) em objetos existentes (sejam eles nativos ou não), provendo um nível gigantesco de maleabilidade / flexibilidade ao desenvolvedor.

A MSDN diz o seguinte:

“Extension methods enable you to “add” methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type.”

Os exemplos comumente vistos em posts sobre EM mostram um cenário onde você quer por exemplo adicionar um método – digamos - ConcatTo(“bola”) pra todas as strings do seu sistema. Muito simples e sem nenhuma confusão até aí e, sem dúvidas é no que mais se vê EM aplicados. Mas claro, não é o único motivo!

Extension Methods – Parte 101

Dado o snippet abaixo, me diga, o que você acha que aconteceria quando eu apertasse F5 no meu VisualStudio?

public interface IInterface { }
public class MinhaClasse
{
  public MinhaClasse()
  {
    IInterface qualquerCoisa = null;
    qualquerCoisa.Do();
  }
}
public static class IInterfaceExtensions
{
   public static void Do(this IInterface @this) { Console.Write("Opa!"); }
}

Ok. Compilar faz sentido, certo? Um sentido meio estranho, mas faz! Agora, se você rodou o código, provavelmente viu algo como a imagem a seguir:

Opa!

OOOOPA!!

Agora é que vem a pergunta que não quer calar (pode perguntar, não tem problema)! – Como diabos uma interface, com uma referência nula, pode ter comportamento?!

Pois é, na verdade esta característica do Extension Methods já é conhecida de alguns artigos anteriores a este¹ e, é realmente algo interessante de se ver funcionando. Em uma explicação resumida, eis o que está acontecendo por trás das cortinas do framework: Durante o processo de compilação (na verdade, se você está usando o VisualStudio isto deve acontecer durante a escrita do código sem que você tenha que pedir explicitamente), o compilador procura por uma assinatura que faça sentido para a chamada que você está pretendendo realizar e, na geração da IL ele simplesmente substitui a chamada que você está realizando para um dado tipo e a coloca como uma referência direta para o EM passando seu tipo como primeiro parâmetro.

Acho que com exemplos tudo fica mais fácil de entender… Digamos que definindo nossa interface, temos o seguinte código:

public interface IInterface { void Do(); }
public class MinhaClasse
{
  public MinhaClasse()
  {
    IInterface qualquerCoisa = null;
    qualquerCoisa.Do();
  }
}
public static class IInterfaceExtensions
{
   public static void Do(this IInterface @this) { Console.Write("Opa!"); }
}

Repare que ao contrário do código anterior, agora nossa interface realmente tem um método chamado “Do” em sua definição! Se compilarmos este código veremos que a IL da chamada ao “Do” ficou da seguinte forma:

IL_000b:  callvirt   instance void Diffy.IInterface::Do()

Claramente, a chamada está sendo realizada utilizando o que quer que esteja referenciado pela interface, diretamente e sem rodeios. Agora, tente rodar a aplicação e você verá a boa e velha mensagem “Object reference not set to an instance of an object.”. Agora vamos voltar ao primeiro código onde nossa interface era a coisa mais feia do mundo e simplesmente não definia método algum e, após compilar o código veremos que a IL da chamado ao “Do” agora é a seguinte:

IL_000b:  call       void Diffy.IInterfaceExtensions::Do(class Diffy.IInterface)

Wow, right?! Sim, caro companheiro, o compilador agora, na falta de uma correspondência adequada (na verdade baseado nas prioridades de execução relacionadas aos EM¹) trocou a referência do método que deve ser executado e está apontando diretamente para o “Do” definido dentro da classe de extensões. De uma forma mais clara, a chamada se tornou isto (equivalente em C#):

   IInterfaceExtensions.Do(qualquerCoisa);

De volta ao problema

Agora que sabemos um pouco mais sobre o que pode ser feito com EM, podemos prosseguir com tranqüilidade em busca de uma solução que além de nos permitir adicionar comportamento a objetos que não nos pertencem de uma forma que certamente não irá afeta-los de forma negativa. Pensando de uma forma simplista podemos dizer que o problema está praticamente resolvido visto que, independentemente do objeto podemos enxertar comportamento no mesmo, permitindo que a feature de comparação seja implementada (seja usando reflection ou com implementações manuais), certo? Bem… Certo até um dado ponto. A questão é que conforme disse no começo do post, não conheço todos os objetos que terei que implementar esta feature e, pior que isto, mesmo que consiga uma lista com todos os tipos, estes tipos estão em constante mudança e novos tipos são criados com uma certa freqüência então preciso de algo que sirva para ambos os casos: tipos conhecidos e “desconhecidos”.

É aí que podemos fazer uso da inteligência do compilador e da força que as extensões de interface nos permitem (mesmo eu ainda tendo muito medo disto).

Imagine que o responsável por manter os objetos que serão comparados tenha muito receito (por uma série de motivos que você concorda e não tem como discutir) em realizar alterações nos mesmos, logo, não existe chances de adicionar qualquer comportamento extra a estes objetos para cumprir sua tarefa. É importante mencionar isto pois, dada esta realidade estamos impossibilitados de, por exemplo, fazer uso de uma interface com métodos de comparação em sua definição e, tão pouco, de uma classe abstrata (base) onde nós mesmo realizamos uma implementação de comparação genérica (por reflection, por exemplo) por conta da limitação do framework frente à herança múltipla (o que poderia criar um conflito com o ecossistema de classes atual). Esta última opção também esbarraria em nosso requisito de performance extrema. Por sorte, no nosso caso, nossa prancheta já tem um projeto pronto para ser colocado em prática.

Imagine você que poderíamos propor então a adição de uma interface vazia em todas suas entidades (leia-se marker interefaces°). Ok, deixando o purismo de lado de que uma interface vazia não representa absolutamente nada, não existe nenhum problema e/ou risco em fazer esta alteração, certo? Sei que você já entendeu aonde quero chegar com esta história toda.

Ao conseguirmos estabelecer uma base para indicar ao compilador quais aos objetos que poderão ser comparados por meio de um EM, já estamos com mais de 50% do caminho andado. Apenas com esta solução já poderíamos fazer implementar uma função genérica de comparação usando reflection porém, neste caso estamos pensando muito em performance, precisariamos de algo um pouco mais assertivo.

Prototipando a solução

Digamos que definimos a seguinte interface como sendo nosso ponto de liga entre os objetos do sistema que serão comparados e nossas EM:

   public interface ICanCompare { }

Baseado neste cara, escrevemos a seguinte EM:

public static class ExtensionsFor_ICanCompare
      {
            public static Dictionary<string, object>CompareTo(this ICanCompare @this, ICanCompare to)
            {
                  /// Implementação de Reflection
                  return null; /// Retorna o dicionário com as diferenças
            }
      }

Ok, mas imagine que sabemos que um dado objeto chamado “ObjetoA” é bem simples e não faria sentido pagar o preço (em termos de tempo de execução) de um reflection para ler seus membros. Neste caso, podemos fazer uso do poder do compilador para escrever um overload para a interface “ICanCompare” permitindo que para chamadas de comparação do objeto “ObjetoA”, outro modo de comparação seja utilizado, como podemos ver no snippet a seguir:

public static Dictionary<string, object> CompareTo(this ICanCompare @this, ObjetoA to)
{
/// Implementação das comparações.. EX:
/// Dictionary<string, object> dic = new Dictionary<string, object>();
/// if(!@this.Propriedade == to.Propriedade){ dic.Add(“Propriedade”, to.Propriedade); }
return null; /// dic;
}

Fácil, certo?! Agora você pode incrementar a brincadeira com coisas mais elegantes como por exemplo utilizar um esquema de mapeamento das propriedades para evitar que uma eventual mudança na nomenclatura dos objetos quebre seu código (o que certamente acontecerá se você fizer uso de strings no seu dicionário). Apenas a título de bônus, segue um esquema bem simples de mapeamento que você poderia utilizar para realizar este processo:

public class ComparableContainerFor<TObject> where TObject : ICanCompare
      {
            public TObject PreviousState { get; private set; }
            public Dictionary<string, object> FinalState { get; private set; }
            private ComparableContainerFor(TObject previousState)
            {
                  this.PreviousState = previousState;
                  this.FinalState = new Dictionary<string, object>();
            }
            public static ComparableContainerFor<TObject> Compare(TObject previousState)
            {
                  return new ComparableContainerFor<TObject>(previousState);
            }
            internal ComparableContainerFor<TReal> CastTo<TReal>() where TReal : TObject
            {
                  return new ComparableContainerFor<TReal>((TReal)this.PreviousState);
            }
            internal ComparableContainerFor<TObject> CompareFieldValue<TProperty>(Expression<Func<TObject, TProperty>> oldValueExpression, TProperty currentValue)
            {
                  if (currentValue != null)
                  {
                        TProperty oldValue = oldValueExpression.Compile()(this.PreviousState);
                        if (!object.Equals(oldValue, currentValue))
                        {
                              this.FinalState.Add(GetMemberExpression(oldValueExpression).Member.Name, currentValue);
                        }
                  }
                  return this;
            }
private MemberExpression GetMemberExpression<TPropertyFrom>(Expression<Func<TObject, TPropertyFrom>> expression)<
            {
                  MemberExpression memberExpression = null;
                  if (expression.Body.NodeType == ExpressionType.Convert)
                  {
                        var body = (UnaryExpression)expression.Body;
                        memberExpression = body.Operand as MemberExpression;
                  }
                  else if (expression.Body.NodeType == ExpressionType.MemberAccess)
                  {
                        memberExpression = expression.Body as MemberExpression;
                  }
                  if (memberExpression == null) { throw new ArgumentException("Not a member access", "expressio"); }
                  return memberExpression;
            }
      }

O uso deste cara mudaria um pouco a cara dos nossos EM para algo parecido com o seguinte:

      public static ComparableContainerFor<ObjetoB> To (this ComparableContainerFor<ICanCompare> @this, ObjetoB currentState)
      {
            return @this
                  .CastTo<ObjetoB>()
                  .CompareFieldValue(old => old.MyProperty, currentState.MyProperty)
                  .CompareFieldValue(old => old.MyProperty1, currentState.MyProperty1);
      }

E o uso do comparador seria algo como:

      ObjetoA objetoABase = new ObjetoA { MyProperty = 1 };
      ObjetoA objetoANew = new ObjetoA { MyProperty = 3 };
      var containerA = ComparableContainerFor<ICanCompare>.Compare(objetoABase).To(objetoANew);

¹ – Alguns bons exemplos de interfaces e EM, além da definição da ordem de priorização de uso de uma EM sobre os membros do objeto em questão – Mais informações

² – Infelizmente sobrescrever o método Equals não serviria para o nosso caso pois precisamos saber exatamente quais foram as diferenças encontradas durante a comparação das entidades. Idealmente a implementação de um override de Equals pode interromper a comparação (com short-circuit) já na primeira divergência e não precisa anotar nada que eventualmente tenha sido discrepante entre as instâncias (que inclusive, segundo a definição do método, podem ser de objetos com tipos distintos).

° – Mais sobre marker interfaces aqui e aqui.

Se sim, sim. Se não… Talvez?

Não é de hoje que tenho uma extrema aversão pelo uso de IF’s. Diria até que um dos primeiros pontos que indicariam a necessidade de refactoring em um código é quando existe uma classe ou método gigante. Normalmente, boa parte de seu corpo está tomado por blocos condicionais que escondem comportamentos que não o que a classe / método deveria se ater.

Vamos ao primeiro exemplo de “não faça isto em casa”:

  public static class ParentalControl
    {
        public static void Enter(User user)
        {
            if (user.Age < 18)
            {
                throw new Exception(string.Concat("Dear user ", user.Name, ", you must be over 18 to view this site"));
            }
            else
            {
                /// Redirects to next page...
            }
        }
    }
    public class User
    {
        public string Name { get; set; }
        public int Age { get; set; }
    }

A primeira vista, você pode não achar que temos um problema com o código acima. O código é relativamente simples e não apresenta dificuldade de entendimento, certo?

Ok. Mas todos sabemos que código algum tem garantia de ser o mesmo pra sempre e, fatalmente este modelo de código ditará a forma com que as próximas implementações serão realizadas nesta classe, concorda? Imaginemos que por uma mudança de escopo, o código seja alterado para o seguinte:

public static class ParentalControl
    {
        public static void Enter(User user)
        {
            if (user.Age < 18)
            {
                throw new Exception(string.Concat("Dear user ", user.Name, ", you must be over 18 to view this site"));
            }
            else if (user.LastPayment < DateTime.Now.AddMonths(-1))
            {
                throw new Exception(string.Concat("Dear user ", user.Name, ", you have to pay to continue."));
            }
            else if (!string.IsNullOrEmpty(user.NickName))
            {
                throw new Exception(string.Concat("Dear user ", user.Name, ", please choose a nickname to continue."));
            }
            else
            {
                /// Redirects to next page...
            }
        }
    }

É, acredito que este não é o tipo de código que você diria pra sua mãe que foi você que escreveu. Agora que demonstrei o problema, vamos tentar arrumar a casa.

Talvez a forma mais simples de higienizar o código que temos em mãos seria separar a porção de validação dos dados do usuário do método responsável por levar o usuário à próxima página. Uma forma simples de fazer isto seria com o seguinte código:

public static class ParentalControl
    {
        private static bool UserCanProceed(User user)
        {
            if (user.Age < 18)
            {
                throw new Exception(string.Concat("Dear user ", user.Name, ", you must be over 18 to view this site"));
            }
            else if (user.LastPayment < DateTime.Now.AddMonths(-1))
            {
                throw new Exception(string.Concat("Dear user ", user.Name, ", you have to pay to continue."));
            }
            else if (!string.IsNullOrEmpty(user.NickName))
            {
                throw new Exception(string.Concat("Dear user ", user.Name, ", please choose a nickname to continue."));
            }
            return true;
        }

        public static void Enter(User user)
        {
            if (ParentalControl.UserCanProceed(user))
            {
                /// Redirects to next page...
            }
        }
    }

Gosto da idéia de usar um retorno boleano para encapsular a ação de redirecionamento pois, desta forma, só de olhar o código você tem a visão de que para aquele bloco de código ser executado ele depende do resultado do método que o precede.

Uma pessoa normal talvez se dê por satisfeita com esta separação, mas este blog não faria jus ao nome se não tentasse algo “louco”.

PS: Idealmente, você migraria o método “UserCanProceed” para uma classe que contenha os métodos de validação necessários para se executar quando interagindo com a classe “ParentalControl” (algo como uma “ParentalControlRules”), mas para simplificar o artigo e os exemplos, vamos com esta solução mais simples.

Go IGINC

E se pudéssemos fazer algo do tipo:

private static bool UserCanProceed(User user)
        {
            return GenericRules
           .ForParameter(user)

           /// Verifica idade mínima
           .WithContext(new { MinAge = 18 })
           .ThrowingExceptionAs((context) => { return string.Concat("Dear user ", user.Name, ", you must be over 18 to view this site"); })
           .Check((parameter, context) => { return user.Age > context.MinAge; })

           /// Verifica data último pagamento
           .WithContext(new { BasePaymentDate = DateTime.Now.AddMonths(-1) })
           .ThrowingExceptionAs((context) => { return string.Concat("Dear user ", user.Name, ", you have to pay to continue."); })
           .Check((parameter, context) => { return user.LastPayment > context.BasePaymentDate; })

           /// Verifica se o nickname foi escolhido
           .ThrowingExceptionAs((context) => { return string.Concat("Dear user ", context.Name, ", you have to pay to continue."); })
           .Check((parameter, context) => { return !string.IsNullOrEmpty(user.NickName); })

            /// Executa todas as validações
           .ValidateRules();
        }

Com este código nós seriamos capazes de não só mapear as validações que precisamos executar como também de transformar estas regras em uma historinha para as gerações futuras de programadores que passarem por ali, fazendo com que você seja lembrado por toda a eternidade como alguém que tem muito amor ao próximo. :)

Tá, mas como faremos isto?

Segundo a MSDN, Anonymous Type são definidos da seguinte forma:

An anonymous type has method scope. To pass an anonymous type, or a collection that contains anonymous types, outside a method boundary, you must first cast the type to object. However, this defeats the strong typing of the anonymous type. If you must store your query results or pass them outside the method boundary, consider using an ordinary named struct or class instead of an anonymous type.

Ou seja, AT tem uma vida chata, limitada ao método onde é criada. Pelo que lemos ali, pra passar o AT adiante você precisaria fazer um cast dele para Object (sic), aniquilando assim com a beleza da tipagem. Não queremos isto, queremos?

Bom, para resolver 0 problema de passar o AT como parâmetro, existe uma série de posts na web sobre o assunto “anonymous type as parameters“, dentre eles, um em Português com uma solução “diferente” mas que parece funcionar. Entretanto, nenhum deles me deixou muito satisfeito.

No final das contas, as soluções mundo afora se resumem a de uma forma ou de outra realizarem o cast para Object e extrair por inferência o tipo real do objeto anônimo. Bom, o que fazer para evitar o Cast então?

Antes de continuar: Não estou dizendo aqui que ninguém pensou nesta solução antes, estou sim dizendo que não encontrei uma fonte que estivesse fazendo uso do mesmo formato que vou demonstrar abaixo. Sem mais delongas, vamos voltar ao código:

public GenericRuleContext WithContext<contextType>(contextType context)
{
...
}

Acredite ou não, a solução é basicamente esta. O segredo todo está em trabalhar com um método genérico que recebe um parâmetro tipado para este tipo dinâmico. O que acontecerá é que teremos uma inferência do tipo fornecido pelo tipo anônimo gerado e, conseqüentemente, poderemos trabalhar com ele, dali por diante, como qualquer outro tipo do sistema, sem diferenciação ou limitações (seja de escopo de método, classe, ou dll).

E, o mais legal disto tudo ainda está por vir (pelo menos eu achei)! Ver o Intellisense do VS reconhecendo este objeto que a documentação disse que não conseguiria é poesia para meus olhos!

Visual Studio - AT Intellisense

Agora que passei pela parte mais estranha, segue o link para download do código da biblioteca que permite a sintaxe fluente de validação de dados.

PS: O código da infraestrutura fluente que expliquei neste artigo acabou ficando muito complexo para ser utilizado em produção. O ponto do código vinculado ao artigo é demonstrar algumas técnicas de desenvolvimento de interfaces fluentes e claro, a utilização de anonymous types como parâmetros.

Leia também: Why are anonymous types generic?

• Kodu (parece bem divertido!)
• RADAR (tem que abrir no IE)
• Rex (pra quem não acha que expressão regular é coisa do diabo)
• Ripley (bem interessante pra quem usa AJAX to the core)
• RobusHeap (tipica coisa que você olha e imagina: PQ nunca pensei nisto?)
• Spectator (tem alguns sites grandes precisando conhecer esta ferramenta! lol)
• Automated Annotation of Human Faces in Family Albums (paper)

e, meu predileto: Infer.Net

O problema

Imagine que você tem o seguinte código:

var MeuObjeto = function () {
            var _intervalo = 1000;
            this.Rodar = function () {
                alert("rodou!");
                window.setTimeout(function () { this.Rodar() }, _intervalo);
            }
        }

Ao que parece, tudo certo, certo? Errado!

Quando chamarmos

new MeuObjeto().Rodar();

você perceberá que após a primeira execução, as demais chamadas que deveriam ocorrer a cada 1 segundo não acontecerão e, dependendo do navegador, você verá uma mensagem de erro.

Causa

Durante a utilização do window.setTimeout, o escopo interno do método em questão é o do objeto window e não MeuObjeto como você (e o intellisense do Visual Studio 2010) poderia imaginar.

Solução

Ponteiro. (oh yeah!)

var MeuObjeto = function () {
            var _intervalo = 1000;
            var _eu = this;
            this.Rodar = function () {
                alert("rodou!");
                window.setTimeout(function () { _eu.Rodar() }, _intervalo);
            }
        }

Note que adicionamos uma variável nova no escopo do objeto MeuObjeto a qual contém uma referência para o objeto em si. Esta variável se torna visivel para o método que será chamado no window.setTimeout permitindo o acesso direto ao escopo desejado.

Sempre fui defensor de uma popularização do conhecimento como um todo. Sou entusiasta das discussões e poderia passar dias em um mesmo assunto se achar que me fará mais adaptativo ou me fará evoluir de alguma forma.

Fato é que a comunidade em geral, não só a comunidade de desenvolvedores / técnica, poderia ter mais disto. Conheço muita gente que já faz sua parte mas acho que duas horas por semana não mata ninguém! É uma questão de civilidade.

É claro que não estou aqui defendendo que um médico junte um grupo de donas de casa para ensiná-las como remover tumores ou coisa do tipo, porém, estes médicos poderiam por exemplo dedicar algumas horas do dia / semana / mês / ano a alguma entidade beneficente em que confie. É aquela história de que quando tivermos cada um fazendo um pouco, todos terão mais exemplos para se basear e seguir, fontes para construir uma rede de conhecimento descentralizada e desburocratizada e/ou,  ao menos esta sensação ótima de que você está ajudando.

Estou muito contente de, por meio do instituto 7COMm, poder colocar em prática esta minha visão. Ontem ministrei a primeira aula de programação (HTML e JavaScript) para uma turma de 8 alunos que me brindaram com duas horas e meia de perguntas interessantes e belas demonstrações de interesse e gana por conhecimento.

Ainda na pegada de compartilhar, abaixo os slides que usei na primeira aula:

Agora é torcer pra que a turma aguente e mantenha a pegada até o final e, se tudo der certo, continue procurando por algo a mais.

PS: Faça sua parte e seja feliz!

public static double Testa_d()
{
double a = double.MinValue;
double b = (double)a + 3000.0;
return b + 1.0;
}
public static Double Testa_D()
{
Double a = Double.MinValue;
Double b = (Double)a + 3000.0;
return b + 1.0;
}
public static double Testa_dDMix()
{
double a = Double.MinValue;
Double b = (double)a + 3000.0;
return b + 1.0;
}

Neste código temos três métodos onde, em dois deles (Testa_d e Testa_D) trabalhamos com uma declaração unica dos tipos das variáveis a e b. Já no método Testa_dDMix, trabalhamos de forma “mista”.

Finalizando, para poder provar minha declaração recorri a um simples recurso prático:  ildasm.

Uma vez de posse do código IL gerado pelo compilador, foi só abrir e mostrar que todos os três métodos geraram uma representação idêntica e, não possuem qualquer instrução de boxing e/ou unboxing. Segue:

{
  // Code size       35 (0x23)
  .maxstack  2
  .locals init ([0] float64 a,
           [1] float64 b)
  IL_0000:  ldc.r8     -1.7976931348623157e+308
  IL_0009:  stloc.0
  IL_000a:  ldloc.0
  IL_000b:  conv.r8
  IL_000c:  ldc.r8     3000.
  IL_0015:  add
  IL_0016:  stloc.1
  IL_0017:  ldloc.1
  IL_0018:  ldc.r8     1.
  IL_0021:  add
  IL_0022:  ret
}

Note que ambas as variáveis são declaradas exatamente da mesma forma (linhas 4 e 5) e, apenas para sair um pouco do feijão com arroz e a título de curiosidade, note que na linha 9 existe uma chamada para conv.r8.

Em poucas palavras, isto ocorre pois no código C# nós escrevemos este fragmento utilizando conversão explicita e, mesmo sendo uma conversão para o mesmo tipo (o que em outro momento seria um óbvio erro de programação), o compilador parece não se importar em colocar esta diretiva extra. Pessoalmente tenho um apresso muito grande para com o compilador .Net, acho ele realmente phoda, mas neste caso ele meio que faz gordisse… Se alguém tiver uma boa explicação ou motivo que justifique esta diretiva neste caso, ficarei feliz em receber um feedback.

Abraço e até a próxima!

Update: Algumas pessoas me responderam falando pra tentar usar o sufixo D no valor da variável, porém, isto não muda em nada quanto a adição ou não da diretiva conv.r8 ao código.

Update 1 / Complemento: Uma referência legal pra quem quer saber um pouco mais sobre boxing e unboxing: IL 101–Parte 9 (Boxing e Unboxing)

Conceitualmente, a linguagem M se baseia em quatro pilares: Linguagem, dados, constraints e transformação. Vamos a eles.

Linguagem M

Por definição, escrever nesta linguagem consiste em unir uma ou mais regra sintática tokenizada, cada qual contendo fragmentos ou o todo (no caso do padrão Main) da forma possível de escrita do texto (código). Abaixo o que poderia ser a definição para uma linguagem chamada HelloWorld:

mudule Simples
{
   language HelloLanguage {
     syntax Main = "Hello, World";
   }
}

Basicamente, na grande maioria dos casos, a construção de uma estrutura de linguagem utilizando M considera a necessidade de Tokens (equivalente as palavras conhecidas)  e syntaxes (equivalente a estrutura fraseal).

Na realidade, ao contrário do que eu escrevi poucas linhas acima, o nome real (full name) da linguagem que criamos a pouco seria Simples.HelloLanguage, uma estrutura que remete ao sistema de Namespaces que estamos acostumados nas linguagens formais da plataforma .Net.

Nas linhas escritas acima existe uma declaração de sintaxe bem simples onde permitimos (e reconhecemos) a utilização da forma “Hello, World” como sendo uma declaração válida e coesa. As informações definidas em forma de sintaxe podem ser entendidas como sendo as regras da linguagem, logo, com a regra que definimos até o momento apenas um texto exatamente igual a “Hello, World” seria interpretada como uma sintaxe válida. Qualquer outro texto/padrão será definido pelo processador como inválido.

Como você pode imaginar, uma linguagem que contém apenas uma regra é tão útil quanto um saco de areia no deserto. Geralmente teremos formas sintáticas contendo múltiplos padrões, como pode exemplo:

mudule Simples
{
   language CoresPrimarias {
      syntax Main = "Vermelho" | "Amarelo" | "Azul";
   }
}

Facilmente identificamos que em termos de cores primárias, de acordo com nossa definição acima, tanto “Vermelho”, quanto “Amarelo” ou “Azul” são informações que fazem sentido neste contexto, porém, “Roxo” não se aplica.

Intellipad

Este foi talvez um dos artigos mais difíceis de escrever dada a enorme falta de informação e diria até de suporte da Microsoft para a comunidade que quer começar a fazer alguma coisa com a ferramenta. Dentre outras dificuldades, não conseguia de forma alguma entender como fazer a compilação da gramática por meio do release mais recente do pacote SQL Server Modeling CTP Nov R3, mas depois de abrir um tópico (aparentemente no lugar errado) perguntando sobre o assunto, pude dar continuidade ao artigo.

Como sairemos da parte conceitual, é interessante que você tenha instalado em sua máquina as ferramentas para escrever e testar suas sintaxes localmente. Segue o link para o pacote necessário para o resto do artigo:

SQL Server Modeling CTP – Nov 2009 Release 3 (formerly “Oslo”)

Após a instalação você verá no menu iniciar, dentro da opção “Microsoft Oslo“, um atalho para o Intellipad.

A título de exemplo, vamos trabalhar com a necessidade de definir uma linguagem para especificar formas de pagamento de maneira inteligível. Digamos que:

• Existem diversas formas de pagamento, cada qual com suas características e peculiaridades; Para cada forma de pagamento:
  • Poderão ocorrer  ações (Pagar, Agendar, etc);
  • Poderemos definir a fonte dos recursos;

Com estes dois casos simples, trabalharemos a seguir de forma a normatizar uma DSL usando M e permitir a escrita de instruções simples e diretas porém, que englobem o todo do negócio em questão. Para começar, vamos definir uma história simples:

Pagamento “Boleto”

Banco “Itau”

Moeda “Real”

Valor “R$300,00″

Pagar!

Fim Pagamento

Como todo bom inicio de desenvolvimento, teremos um código visivelmente estranho e “melhorável”, porém, até o momento ele atende nossas necessidades e cria abertura para aprendermos mais algumas coisas. Veja o código a seguir:

module Felipe
{
    language Financas
    {
       /// Sintaxe base
        syntax Main ="Pagamento"
            valorLiteral
            Banco
            Moeda
            Valor
            Pagar
            "Fim Pagamento";

        /// Declaração das variáveis globais conhecidas
        syntax Banco = "Banco" valorLiteral;
        syntax Moeda = "Moeda" valorLiteral;
        syntax Valor = "Valor" valorLiteral;

        /// Declaração das ações possíveis
        syntax Pagar = "Pagar!";

        /// Interleaves permitidos
        interleave whitespace = (" " | "\r" | "\n" | "\t")+;

        /// Tokens
        token valorLiteral = '"' !('\r' | '\n' | '"')+ '"';
   }
}

Para acompanhar os próximos passos e se familiarizar com a interface do Intellipad, faça o seguinte:

1. Abra o Intellipad e cole o código acima (e os demais que serão disponibilizados ao longo do artigo) salvando o arquivo com extensão .mg (recomendo salvar como “MinhaLinguagem.mg” para facilitar o acompanhamento do artigo). Isto dirá ao Intellipad que ele deve tratar esta janela em modo “DSL Grammar Mode”, ajudando e facilitando o desenvolvimento;
2. No caso da história, salve-a em um arquivo separado (preferencialmente com a extensão .dsl, melhor ainda se com o nome “Historia.dsl”, também para facilitar o acompanhamento)e carregue este arquivo por meio do caminho: “DSL” > “Open File as Input and Show Output…”. Desta forma você terá a visão completa em tempo real da aderência de sua DSL frente a história.

Nota-se no código acima a adição de mais dois padrões sendo: interleave e token. Abaixo, a explicação para cada um:

• Interleave: Quando criamos um padrão deste tipo estamos dizendo ao processador M que estes fragmentos de texto não devem ser considerados como parte do fluxo primário, ou seja, devem ser desconsiderados; Durante o processamento do texto (input), o processador automaticamente injeta estes padrões entre os termos de padrões do tipo syntax.
• Token: Por meio deste padrão, dizemos ao processador quais são as formas de acessar informações literais em nossa linguagem criando uma espécie de filtro. No caso acima, estamos considerando qualquer coisa que comece e termine com aspas duplas, exceto por novas linhas, saltos de linha e aspas duplas entrelaçadas no escopo principal;

O código acima juntamente com a história que definimos inicialmente permite  que o Intellipad consiga identificar alguns padrões:

M Graph Mode

Legal, certo?! Que tal melhorar um pouco este código?

Primeiro, vamos tentar diminuir um pouco a redundância existente nas declarações de algumas estruturas; Para tanto, vamos realizar as seguintes alterações:

• Utilizar uma forma de declaração de syntax que permite um comportamento similar ao das funções (em linguagens de programação tradicional) para maximizar a reutilização dos formatos;
  • Chamarei esta “função” de variavel, uma vez que para o negócio, ela representa as variáveis com as quais trabalharemos. O funcionamento dela é bem auto-explicativo, você ao definir uma estrutura sintática composta só precisa seguir a sintaxe definida para a linguagem M e, consumir esta sintaxe não é mais difícil do que realizar uma chamada a um método qualquer.
• Melhorar a sintaxe principal para permitir o uso opcional de algumas variáveis, de acordo com a necessidade;

module Felipe
{
    language Financas
    {
        /// Regra para variáveis globais
        syntax variavel(nomeToken) = nomeToken valorLiteral;

        /// Sintaxe base
        syntax Main ="Pagamento"
            valorLiteral
            Banco
            "Fim Pagamento";

        /// Declaração das variáveis globais conhecidas
        syntax Banco = "Banco" valorLiteral (Moeda | Valor)* Executar;
        syntax Moeda = variavel("Moeda");
        syntax Valor = variavel("Valor");
        token Pagar = "Pagar!";
        token Agendar = "Agendar!";

        /// Declaração das ações possíveis
        syntax Executar = (Pagar | Agendar);

        /// Interleaves permitidos
        interleave whitespace = (" " | "\r" | "\n" | "\t")+;

        /// Tokens
        token valorLiteral = '"' !('\r' | '\n' | '"')+ '"';
    }
}

Bom, neste ponto, nossa sintaxe está poderosa o suficiente para validar diversas formas diferentes de se contar a história inicial porém, sem perder a aderência ao escopo desejado.

Syntax + Token = OK:
Um detalhe muito importante de se ressaltar sobre o código acima é o uso de padrões syntax consumindo padrões de token, neste caso o interpretador permite a utilização, porém, no caso oposto (token consumindo syntax) um erro ocorre e (pelo menos na minha máquina) o Intellipad trava e fecha com a mensagem abaixo!

Intellipad error - BUM!!

Uma outra funcionalidade interessante é a possibilidade de decorar nossos padrões do tipo token com atributos para permitir uma espécie de syntax highlight. Veja o código abaixo:

module Felipe
{
    language Financas
    {
        /// Regra para variáveis globais
        syntax variavel(nomeToken) = nomeToken tValorLiteral;

        /// Sintaxe base
        syntax Main =tPagamento
            tValorLiteral
            sBanco
            tFimPagamento;

        /// Tokens conhecidos
        @{Classification["Literal"]}
        token tValorLiteral = '"' !('\r' | '\n' | '"')+ '"';

        @{Classification["Keyword"]}
        token tPagar = "Pagar!";

        @{Classification["Keyword"]}
        token tAgendar = "Agendar!";

        @{Classification["Keyword"]}
        token tPagamento = "Pagamento";

        @{Classification["Keyword"]}
        token tFimPagamento = "Fim Pagamento";

        @{Classification["Keyword"]}
        token tBanco = "Banco";

        @{Classification["Keyword"]}
        token tMoeda = "Moeda";

        @{Classification["Keyword"]}
        token tValor = "Valor";

        /// Declaração das ações possíveis
        /// Sintaxes permitidas
        syntax sExecutar = (tPagar | tAgendar);
        syntax sBanco = tBanco tValorLiteral (sMoeda | sValor)* sExecutar;
        syntax sMoeda = variavel(tMoeda);
        syntax sValor = variavel(tValor);

        /// Interleaves permitidos
        interleave whitespace = (" " | "\r" | "\n" | "\t")+;
    }
}

O resultado é interessante:

Borat said: Nice!

Productions

Por fim, vamos ao conceito de Productions que, a grosso modo, podemos definir como a forma em que o resultado da interpretação de um dado texto frente à linguagem deverá ser apresentado. Para facilitar, vamos alterar um pouco o nosso código para deixá-lo mais amigável:

Pagamento “Boleto”

Moeda: Dólar

Banco: Itau

Fim Pagamento

Esta alteração não tem influência direta no resultado quando utilizando Productions, alterei apenas para deixar a explicação mais simples.

Obviamente que neste ponto a janela “M Graph Mode” já não exibe nada pois o interpretador já não consegue fazer o match entre a história e a definição da linguagem. Para resolver isto, vamos alterar a definição da seguinte maneira:

module Felipe
{
    language Financas
    {
        /// Sintaxe base
        syntax Main = tPagamento
            tValorLiteral
            (sMoeda | sBanco)*
            tFimPagamento;

        /// Tokens conhecidos
        @{Classification["Literal"]}
        token tValorLiteral = '"' !('\r' | '\n' | '"')+ '"';

        @{Classification["Keyword"]}
        token tPagamento = "Pagamento";

        @{Classification["Keyword"]}
        token tFimPagamento = "Fim Pagamento";

        @{Classification["Identifier"]}
        token tTipoMoeda = "Real" | "Dólar";

        @{Classification["Keyword"]}
        token tMoeda = "Moeda";

        @{Classification["Keyword"]}
        token tBanco = "Banco";

        @{Classification["Identifier"]}
        token tTipoBanco = "Itau" | "Real";

        /// Sintaxes auxiliares
        syntax sMoeda = tMoeda ':' tTipoMoeda;
        /// Production
        syntax sBanco = bk:tBanco ':' nome:tTipoBanco => id("O banco de destino é:"){nome};

        /// Interleaves permitidos
        interleave whitespace = (" " | "\r" | "\n" | "\t")+;
    }
}

Em suma, a idéia por traz dos padrões Production é o de você ser capaz de manipular a forma com que o resultado da análise do código é produzido.

No código acima pode-se observar que no momento da definição da sintaxe sBanco, existe um identificador para o token tTipoBanco que permite a utilização desta informação em uma customização do resultado exibido na janela “M Graph Mode”. Complementando a análise da linha, é possível notar que existe uma chamada à expressão id( ), esta expressão é responsável por definir o nome do nó pai em que aquele resultado será exibido.

Podemos adicionar mais alguma perfumaria ao código anterior, permitindo coisas como comentários in-line e em bloco, porém não vou me ater muito a estes detalhes visto que o conhecimento necessário para tanto já foi exposto. Vamos então para o próximo e derradeiro tópico: Output.

CommandLine.exe

Junto com o pacote Oslo PDC e SDK você encontra algumas outras ferramentas para dar suporte ao desenvolvimento em M, das quais duas se destacam:

• m.exe: Ferramenta para compilar sua gramática de forma a permitir a validação da DSL; Você deve fornecer a ela o arquivo em que você descreveu sua gramática (nosso arquivo .mg) e esperar que um arquivo compilado seja gerado (arquivo .mx);
  m.exe MinhaLinguagem.mg
• mx.exe: Por meio do seu arquivo gramatical compilado (.mx), juntamente com a história (a DSL) ele consegue gerar uma saída em formato “M” ou XAML. A sintaxe de execução é a seguinte:
  mx.exe Historia.dsl /r:MinhaLinguagem.mx
• mg.exe: Apenas a título de menção honrosa, esta era a ferramenta para realizar a compilação da gramática até o CTP Nov R3.

Após a geração do nosso arquivo .M, teremos algo muito parecido com isto:

module Historia {
    Main {
        @[0] => "Pagamento",
        @[1] => "\"Boleto\"",
        @[2] =>  {
            @[0] {
                 {
                    @[0] {
                        sMoeda {
                            @[0] => "Moeda",
                            @[1] => ":",
                            @[2] => "Real"
                        }
                    }
                }
            },
            @[1] {
                 {
                    @[0] {
                        @[O banco de destino é:] => "Itau"
                    }
                }
            }
        },
        @[3] => "Fim Pagamento"
    }
}

Agora, finalmente podemos chegar a um modelo mais prático de como ler e parsear nossa DSL de dentro de um código C#, por exemplo:

public static void Compilar()
        {
            /// Compilamos a gramática em tempo de execução de modo a permitir que eventuais alterações
            /// em sua estrutura sejam imediatamente replicadas por aqui. Isto também pode ser feito manualmente
            /// por meio da ferramenta "m.exe" que acompanha o Oslo
            CompilationResults results = Compiler.Compile(
              new CompilerOptions
              {
                  Sources =
                  {
                        new TextItem
                        {
                            /// Endereço para o arquivo contendo as definições da linguagem
                            Reader = new StreamReader(@"C:\Financas.mg"),
                            Name="MeuItem",
                            ContentType = TextItemType.MGrammar
                        }
                    }
            });

            /// Na linha abaixo temos efetivamente o resultado do parse de nossa DSL contra as regras
            /// que definimos em nossa linguagem. Daqui em diante você pode iterar entre os nodes oriundos
            /// da operação e realizar qualquer que seja a tarefa em mente para o processo, seja: criar e
            /// popular um DTO, instruir o código em algum Path específico, etc...
            var resultados = results.ParserFactories["Felipe.Financas"].Create().Parse(@"c:\Historia.dsl", null);
        }

Conforme explicado no snippet acima, a manipulação do resultado do parse é bem intuitiva e, varia de acordo com a necessidade para qual sua DSL foi desenhada. Você pode também utilizar seu aquivo .mx compilado manualmente seguindo os passos descritos aqui.

Flow

Importante: Se quando estiver compilando seu projeto você receber a mensagem “The type or namespace name ‘M’ does not exist in the namespace ‘Microsoft’ (are you missing an assembly reference?)“, a solução no meu caso foi ir até as propriedades do projeto e alterar o Target Framework de “.NET Framework 4-Client Profile” para “.NET Framework 4” (Mais info aqui).

Outras leituras:

• Mx.exe
• SQL Server Modeling
• DSL – Domain-Specific languages
• Domain-Specific Languages no dia-a-dia

Para maiores detalhes, segue o link para o blog do Sr. Jason Zanders (em inglês):
http://blogs.msdn.com/b/jasonz/archive/2010/02/18/favorite-vs2010-features-layer-validation.aspx

Faz mais de um ano eu escrevi um post em meu outro blog (agora migrado pra cá) sobre minhas primeiras impressões quanto a ferramenta de dados lançada junto ao .Net framework 3.5 (SP1),  conhecida popularmente como Entity Framework e, para minha surpresa, o motivo que me fez não usar a solução em NADA no passado deve ser a mesma que me prevenirá de usá-la na versão atual.

Resumindo, este post serve para duas coisas:

1. Mostrar que, apesar de estar sumido, estou vivo! Yey!
2. Demonstrar minha indignação frente ao fato de que mesmo as referências mais recentes do EF2 (ref: Dynamic Data) relatam a solução (na minha opinião) porca de Metadata decoration como sendo a solução “oficial”…

É, parece que ainda não tá na hora de trocar meu NHibernate.

PS> Estou mudando de emprego o que indica que meu próximo post (continuação do último sobre Hopfield) pode demorar um pouco mais do que o imaginado, mas não se engane: ELE VIRÁ!

Oh Yeah, bring it on!

Diminuindo o ritmo no blá-blá-blá, que tal um exemplo funcional de com o que a tal da rede neural se parece? Para facilitar o entendimento eu vou simplificar o exemplo ao máximo, logo não me culpe se você em seguida sentir que é o novo gênio da AI e resolver criar seu próprio andróid-escravo-lavador de carros.

Abaixo, um diagrama simples dos relacionamentos de uma rede contendo quatro neurônios:

Imagem 1 - Rede Neural básica

Na rede neural representada pela Imagem 1, vê-se claramente que todos os neurônios estão interligados uns aos outros. Para facilitar o entendimento, podemos representar esta visão na matriz abaixo. Note que os pontos de intersecção ocorrem em todos os pontos exceto de forma recursiva¹. Isto será explicado com maiores detalhes mais a frente.

Weight Matrix

Antes de ser crucificado pelo que estou prestes a fazer, para fins de entendimento mais claro do conteúdo, vou deliberadamente traduzir este termo técnico para algo mais fácil de assimilar. De agora em diante, eu declaro que em meus tópicos, weight matrix se chamará matriz de pesagem. Pronto!

Ok, mas você pode (e deveria) se perguntar: WTF matriz de pesagem?!

Imagine por um instante o que estamos tentando realizar aqui: Através da criação de redes neurais artificiais, estamos a grosso modo tentando de alguma forma replicar o que acontece naturalmente em um animal com capacidade de aprendizado, logo, como acontece na natureza nossas redes neurais artificiais nascem burras e precisam passar por um processo para que organizem um dado conjnto de dados e informações de forma coesa, formando então uma estrutura que contém conhecimento.

Existem algumas formas de se ministrar este aprendizado das quais posso citar três (geralmente consideradas como apenas duas) e, desta vez não me atreverei a traduzir nomes:

• Supervised learning:  Por este método, o processo de aprendizagem e calibragem do algoritmo é acompanhado por um processo externo, seja um sistema ou um humano;
• Unsupervised learning:  O sistema descobre a melhor solução por meio de estatísticas, sem intervenção externa;
• Reinforcement Learning: Um processo que mistura ambos os modelos acima e, por este motivo, não é considerado como um processo independente em algumas literaturas.

A matriz de pesagem é o mecanismo pelo qual as redes neurais que trabalharemos serão ajustadas. Abaixo o exemplo mais comum de uma matriz de pesagem para uma rede Hopfield de quatro neurônios que identifica o padrão 0101 e 1010, note porém que estou passando a solução do problema antes de descrever o problema em si. Mais adiante veremos como esta matriz foi formada:

Você só está tendo contato com estes dados agora pois acredito ser mais fácil de explicar os próximos passos com uma representação visual do que buscamos com toda a parafernália que será explicada / montada.

Matematica.Apply();

Um dos principais pontos que utilizaremos em Hopfield é a manipulação de vetores, como a idéia aqui é passar a parte prática, não vou me ater à explicações da parte matemática da operação, porém, é muito fácil encontrar referências on-line sobre o assunto².

Para explicar a montagem da matriz de pesagem, vamos iniciar com uma matriz vazia, como a seguinte:

Para começar, vamos fornecer o valor 0101 para a matriz acima de forma a respeitar as já mencionadas regras básicas da estrutura¹. Esta matriz derivada é chamada de matriz de contribuição.

No calculo desta matriz, existem algumas necessidades que devem ser supridas, sendo:

• Cálculo dos valores bipolares do input (no caso, baseado em 0101). Calcular os valores bipolares significa que representaremos os valores binários por meio de -1 e 1 e não por 0 e 1; A função que representa este requisito é:
  A função que realiza a conversão dos valores para bipolar é a seguinte:Podemos representá-la em C# da seguinte forma:

  (2 * valor) - 1;

  Já para conversão inversa, de bipolar para binário:E em C#:

  (valor + 1) / 2.0;

• Como segundo passo, nós vamos transpor e multiplicar os valores bipolares de 0101 por eles mesmos;
• Como terceiro e último passo nós precisamos zerar todas as ocorrências onde os neurônios eventualmente poderia se comunicar consigo mesmo¹;

Para realizarmos o processamento utilizando os valores bipolares utilizamos a função Signum:

Onde:

b são os limites inferiores e superiores;
v é o valor de ativação da unidade.

0101, põe na conta do Papa!

Ok, agora com as devidas explicações e notações em mãos, vamos para a execução dos três passos descritos acima:

1. Converter para bipolar: A conversão de cada um dos dígitos de nosso input 0,1,0 e 1 para um valor bipolar, resulta em -1,1, -1 e 1. Esta nova sequência numérica é a nossa base para construção da matriz de contribuição, logo, neste ponto possuímos uma matriz com quatro linhas e uma coluna, que pode ser representada em C# da seguinte forma:
   

   ///
    /// Matriz com quatro linhas e uma coluna
    /// </summary>
    double[] matrizLinha = new double[] { -1, 1, -1, 1 };

2. Multiplicação das matrizes:
   
   1. Agora que possuímos uma matriz com os valores de entrada já convertidos para bipolar, podemos dar o segundo passo que é onde invertemos a matriz existente, neste ponto a matriz se tornará algo equivalente à:
      

      ///
       /// Matriz com uma linha e quatro colunas
       /// </summary>
       double[,] matrizColuna = new double[1, 4] { { -1, 1, -1, 1} };

      Note que basicamente o que fizemos foi reorganizar a estrutura da matriz de forma a transformar colunas em linhas (o oposto também é valido);

   2. O passo anterior nos forneceu uma nova matriz, a qual, utilizaremos para realizar uma multiplicação entre a matriz descrita no Item 1 e a nova, descrita no Item 2.1. Se você, apesar de ter sido direcionado, ainda não como realizar multiplicação de matrizes, ainda há tempo, clique aqui.O Resultado desta multiplicação será a estrutura abaixo:

      /// <summary>
       /// Matriz correspondente a multiplicação das matrizes anteriores
       /// </summary>
       double[,] matriz = {
       { 1, -1, 1, -1 }, /// Primeira coluna
       {-1,1,-1,1},     /// Segunda coluna
       {1,-1,1,-1},     /// Terceira coluna
       {-1,1,-1,1}      /// Quarta coluna
       };

3. Limpar as referências recursivas: Agora que possuímos o produto da multiplicação das matrizes de contribuição, devemos remover os valores que denotem recursividade. Para isto, o procedimento não poderia ser mais simples, bastando definir o valor 0 a todas as posições da matriz onde o valor do índice da coluna é igual ao da linha ou seja [x,x] = 0.
   

   /// Para uma matriz de 4 posições
   for (int i = 0; i < 4; i++) {
   matriz[i, i] = 0;
   }

Neste ponto possuímos uma matriz com a seguinte representação em memória:

/// <summary>
 /// Matriz correspondente a multiplicação das matrizes anteriores
 /// </summary>
 double[,] matriz = {
 { 0, -1, 1, -1 }, /// Primeira coluna
 {-1,0,-1,1},     /// Segunda coluna
 {1,-1,0,-1},     /// Terceira coluna
 {-1,1,-1,0}      /// Quarta coluna
 };

Esta matriz sim tem uma utilidade para o algoritmo como um todo. Ela agora poderá ser adicionada à matriz de pesagem. Se nós esperamos que esta rede neural reconheça o padrão 0101 então esta será a matriz de pesagem. Na verdade, por meio desta exata mesma matriz de pesagem também é possível reconhecer o padrão 1010, que é considerado o oposto do padrão inicial. Quando trabalhando com padrões binários, uma mesma matriz de pesagem é compartilhada para padrões inversos.

Porém, se esperamos ser capazes de reconhecer outros padrões de input (como, por exemplo 0110 ou 1001), então precisamos calcular a matriz de contribuição para ambos os inputs e compilar seus resultados em uma matriz de pesagem.

No próximo post, uma aplicação de reconhecimento de padrões utilizando o que vimos hoje.

Mais info

¹As premissas básicas das redes Hopfield são as seguintes: e , onde somos impedidos de recorrência e guiados a uma simetria de pesos.

²Operações matemáticas com vetores.

Referências

• Categorização no modelo de Hopfield : efeitos de ruído sináptico e de diluição simétrica
• Dot Product
• Tutorial RN