Automatos Celulares

[John F]

Esse projeto é dando uma continuidade no tópico que a Tatyana apresentou para a gente no PCD19, em São Paulo. A ideia é criar um software onde o usuário possa editar todos aquele parâmetros em tempo real para explorar com mais facilidade os autômatos celulares.

A principio o editor vai ter três capacidades:

* desenhar a vizinhança

* determinar o número de estados e as cores deles

* criar regras baseadas na contagem de células em estado X dentro da vizinhança Y.

https://github.com/Introscopia/Cellular_Automata_Suite

Qualquer contribuição é bem-vinda! Estou usando um framework de GUI que eu mesmo criei, se alguém tiver coragem-AHEM, interesse, posso dar uma explicada.

[Tatyana Zabanova]

está bem no começo, mas parece promissor.

 

[contact....@gmail.com]

Desculpe intervir sem convite prévio, mas encontrei esta discussão sobre Processing e Autômatos Celulares, que atraiu minha atenção.

Eu não consegui executar seu projeto ainda devido uma fonte não encontrada, verificarei mais tarde.

Em 2016, eu desenvolvi um simulador de autômatos celulares utilizando Processing e Java, caso tenha interesse, este é o link para o projeto.

Os itens que você descreveu como capacidades está entre os muitos planos que imaginei para continuar com o desenvolvimento. Entre eles, o de maior relevância para essa discussão é a substituição da parte Swing da GUI, migrando integralmente para Processing.

Você citou ter criado um framework GUI; se você não se importar, gostaria de esclarecer algumas dúvidas a respeito disso:

1 - poderia descrever brevemente quais recursos e componentes chegou a criar? 

2 - como tem sido a experiência com o Processing para criar GUI tradicionais?

3 - saberia informar se existe um grau de compatibilidade seguro com P5.js?

[John F]

Opa! não tem nada de convide prévio não. Você encontrou o grupo pelo Reddit, certo? É uma boa surpresa ver que adiantou alguma coisa aquele post!

A fonte está no repositório, é só clonar ele inteiro que ela vem junto. Você pode também recriar ela no IDE do Processing, Georgia 16 com todos os caracteres do unicode.

Realmente impressionante o CAS. Gostei especialmente do editor de regra. Exatamente o tipo de controle tátil que eu estou criando.

Sobre os meus GUIs

1 - uma listinha das classes:

• UISet - o container de elementos. facilita a organização e melhora a eficiência das UIs. 
  
• label - texto que não faz nada. a maioria dos elementos possui um label interno.
  
• Toggle - o clássico. tem algumas variações.
  
• NumSet - aplica um valor à sua incumbência.
• CharSet - mesma coisa para caractéres.
• DropDown - lista drop down de CharSets.
• NumAdd - adiciona um valor à sua incumbência.
• PlusMinus - dois NumAdds, um - e um +.
• Slider.
• ColorSelector.
• Yanker - um slider dinâmico que eu inventei.
• TextDisplay - caixa de texto para se ler
  
• Textfield - caixa de texto para digitar
• listSelect - recebe um string[], aplica na sua incumbência o índice do item selecionado.
• filterbar - como o list, mas mostra opções em um drop-down a medida que o usuário digita.
  

2 - Eu acho o Processing excelente para criar UI. Afinal, ele facilita o acesso ao mouse e ao teclado, assim como simplifica enormemente renderização de geometria e de texto.

3 - portar para P5.js não é tão simples. Existem vários pontos onde um 'find and replace' resolve. Mas em vários outros é preciso reestruturar o código. Já pensei bastante em criar um tradutor automático. Acho que o Jonathan Dahlberg fez algo assim. Mas em geral, quando eu faço coisas pra web eu ja programo direto em JS.

--
Você recebeu essa mensagem porque está inscrito no grupo "processing-brasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para processing-bra...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para processi...@googlegroups.com.
Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/processing-brasil/1a4eb5c2-9578-4dd2-a56e-04c918e84cf3%40googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

[contact....@gmail.com]

Obrigado pela receptividade! Isso, encontrei um post no /r/processing. É de fato um recurso excelente: 3º site mais visitado nos EUA e 6º no mundo, logo, a sua surpresa tem um porquê bastante sólido.

Obrigado pela dica, o meu problema era com a versão do Processing. Depois de atualizar para a versão mais recente, o projeto abriu e compilou normalmente. Gostei de ver os componentes! Parabéns pela iniciativa! Espero que consiga implementar tudo que tiver em mente. :)

Obrigado pelo CAS. Há muito espaço para melhoria e criação. O desenvolvimento seguiu uma abordagem bastante abstrata e dinâmica. Em tese, o núcleo deve ser capaz de simular qualquer tipo de autômato celular, indiferente da geometria celular, número de dimensões, estados, transições, etc…

Mas voltando a GUI:

1 - Interessante, uma boa estrutura já, e o tamanho da classe UI confirma. Você esta baseando sua implementação em diretivas de frameworks existentes ou criando de forma livre e independente?

2 - Ótimo, muito bom saber disso. Concordo, pelo pouco que sei. Houveram muitos momentos de dificuldade para traduzir suas ideias em implementação? Encontrou muitas limitações da linguagem? Chegou a notar depreciação de performance com a evolução da implementação?

3 - Imaginei que fosse mesmo. Gostei das ideias do Dahlberg, mas como ele mesmo descreveu, é algo bem limitado. Escrever uma vez e ter resultados consistentes em plataformas diferentes talvez nunca saia da fantasia. Por favor me deixe saber caso opte em criar o tradutor e tenha êxito.

Em terça-feira, 29 de janeiro de 2019 10:13:23 UTC-2, John F escreveu:

Opa! não tem nada de convide prévio não. Você encontrou o grupo pelo Reddit, certo? É uma boa surpresa ver que adiantou alguma coisa aquele post!

A fonte está no repositório, é só clonar ele inteiro que ela vem junto. Você pode também recriar ela no IDE do Processing, Georgia 16 com todos os caracteres do unicode.

Realmente impressionante o CAS. Gostei especialmente do editor de regra. Exatamente o tipo de controle tátil que eu estou criando.

Sobre os meus GUIs

1 - uma listinha das classes:

• UISet - o container de elementos. facilita a organização e melhora a eficiência das UIs. 
  
• label - texto que não faz nada. a maioria dos elementos possui um label interno.
  
• Toggle - o clássico. tem algumas variações.
  
• NumSet - aplica um valor à sua incumbência.
• CharSet - mesma coisa para caractéres.
• DropDown - lista drop down de CharSets.
• NumAdd - adiciona um valor à sua incumbência.
• PlusMinus - dois NumAdds, um - e um +.
• Slider.
• ColorSelector.
• Yanker - um slider dinâmico que eu inventei.
• TextDisplay - caixa de texto para se ler
  
• Textfield - caixa de texto para digitar
• listSelect - recebe um string[], aplica na sua incumbência o índice do item selecionado.
• filterbar - como o list, mas mostra opções em um drop-down a medida que o usuário digita.
  

2 - Eu acho o Processing excelente para criar UI. Afinal, ele facilita o acesso ao mouse e ao teclado, assim como simplifica enormemente renderização de geometria e de texto.

3 - portar para P5.js não é tão simples. Existem vários pontos onde um 'find and replace' resolve. Mas em vários outros é preciso reestruturar o código. Já pensei bastante em criar um tradutor automático. Acho que o Jonathan Dahlberg fez algo assim. Mas em geral, quando eu faço coisas pra web eu ja programo direto em JS.

On Mon, Jan 28, 2019 at 11:06 PM <> wrote:

Desculpe intervir sem convite prévio, mas encontrei esta discussão sobre Processing e Autômatos Celulares, que atraiu minha atenção.

Eu não consegui executar seu projeto ainda devido uma fonte não encontrada, verificarei mais tarde.

Em 2016, eu desenvolvi um simulador de autômatos celulares utilizando Processing e Java, caso tenha interesse, este é o link para o projeto.

Os itens que você descreveu como capacidades está entre os muitos planos que imaginei para continuar com o desenvolvimento. Entre eles, o de maior relevância para essa discussão é a substituição da parte Swing da GUI, migrando integralmente para Processing.

Você citou ter criado um framework GUI; se você não se importar, gostaria de esclarecer algumas dúvidas a respeito disso:

1 - poderia descrever brevemente quais recursos e componentes chegou a criar? 

2 - como tem sido a experiência com o Processing para criar GUI tradicionais?

3 - saberia informar se existe um grau de compatibilidade seguro com P5.js?

Em quinta-feira, 24 de janeiro de 2019 15:29:25 UTC-2, John F escreveu:

Esse projeto é dando uma continuidade no tópico que a Tatyana apresentou para a gente no PCD19, em São Paulo. A ideia é criar um software onde o usuário possa editar todos aquele parâmetros em tempo real para explorar com mais facilidade os autômatos celulares.

A principio o editor vai ter três capacidades:

* desenhar a vizinhança

* determinar o número de estados e as cores deles

* criar regras baseadas na contagem de células em estado X dentro da vizinhança Y.

https://github.com/Introscopia/Cellular_Automata_Suite

Qualquer contribuição é bem-vinda! Estou usando um framework de GUI que eu mesmo criei, se alguém tiver coragem-AHEM, interesse, posso dar uma explicada.

--
Você recebeu essa mensagem porque está inscrito no grupo "processing-brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para processing-brasil+unsubscribe@googlegroups.com.
Para postar nesse grupo, envie um e-mail para processing-brasil@googlegroups.com.

[John F]

1 - Não me baseei em nenhum framework. Foi pura experimentação. Queria alguma coisa que fosse rápida e simples na hora de montar o GUI, e que funcionasse sem ter que receber parâmetros depois. To bem satisfeito nesses quesitos atualmente!

2 - Dificuldades são só as encrencas de alinhar o que se vê com o que se clica, tende? Você tem que fazer a geometria duas vezes, uma vez pra tela e uma pro mouse. As vezes me confundi um pouco, mas nada disso é culpa do Processing, e problemas de performance nunca houve também.

3 - Pode deixar! Não me imagino fazendo isso num futuro próximo, mas está na lista...

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para processing-bra...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para processi...@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/processing-brasil/1a4eb5c2-9578-4dd2-a56e-04c918e84cf3%40googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Você recebeu essa mensagem porque está inscrito no grupo "processing-brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para processing-bra...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para processi...@googlegroups.com.
Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/processing-brasil/f1f8acce-1ced-447e-b623-d9fa7e80f744%40googlegroups.com.

[contact....@gmail.com]

Muito bom! Estou considerando me aventurar pela mesma experiência para formar uma noção melhor da tecnologia. As suas impressões quanto a sua experiência ajudam a calibrar assertivamente as expectativas.

Eu imaginei que esta questão sobre os eventos do mouse demandaria um pouco. Ja estava me adiantando e pesquisando um pouco sobre https://en.wikipedia.org/wiki/Point_in_polygon mas não tenho certeza ainda se é aplicável.

Muito obrigado por compartilhar sobre a sua experiência! Vou monitorar este grupo e procurar interagir sempre que possível.

Boa sorte nas aventuras com o Processing! :)

Em quarta-feira, 30 de janeiro de 2019 12:42:28 UTC-2, John F escreveu:

1 - Não me baseei em nenhum framework. Foi pura experimentação. Queria alguma coisa que fosse rápida e simples na hora de montar o GUI, e que funcionasse sem ter que receber parâmetros depois. To bem satisfeito nesses quesitos atualmente!

2 - Dificuldades são só as encrencas de alinhar o que se vê com o que se clica, tende? Você tem que fazer a geometria duas vezes, uma vez pra tela e uma pro mouse. As vezes me confundi um pouco, mas nada disso é culpa do Processing, e problemas de performance nunca houve também.

3 - Pode deixar! Não me imagino fazendo isso num futuro próximo, mas está na lista...

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para processing-brasil+unsubscribe@googlegroups.com.
Para postar nesse grupo, envie um e-mail para processing-brasil@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/processing-brasil/1a4eb5c2-9578-4dd2-a56e-04c918e84cf3%40googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

--
Você recebeu essa mensagem porque está inscrito no grupo "processing-brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para processing-brasil+unsubscribe@googlegroups.com.
Para postar nesse grupo, envie um e-mail para processing-brasil@googlegroups.com.

[John F]

Alô gente, mandando aqui pra avisar que a "Suíte" chegou a um estágio básico de funcionalidade, então convido todo mundo a dar uma olhada, já dá pra criar umas coisas bem interessantes! Qualquer pergunta é só mandar!

[Tatyana Zabanova]

Feedback, curto e grosso =)

1. É dificil trabalhar com vizinhanças grandes

2. É dificil lidar com regras grandes, especialmente sem referência numérica, e sem possibilidade de estabelecer intervalos (porque varrer um intervalo com mouse sem falhas é meio dificil)

3. Pelo que entendi, as regras são condicionadas ao input inicial. Isso é muito ruim quando você trabalha com múltiplos estados, pois precisa de 100500 regras.

4. Não está claro como as regras funcionam para multiplos estados. Seria soma ou contagem de elementos de um certo tipo? Seria possível escolher?

5. Falta possibilidade de regras encadeadas, do tipo "se regra 1, então regra 2, caso contrário regra 3"

6. Eu preferiria que o resultado fosse mostrado na mesma página que as regras, pois permitiria mudar as regras mais facilmente.

7. Finalmente, o negócio é muito lento, mesmo para vizinhanças não muito grandes. Agora, se eu tocar uma 100 lá....

pronto, critiquei =D

[Tatyana Zabanova]

Se quiser, copie os meus shaders (eu copiei eles de alguém de qq jeito), fica MUITO mais rápido para vizinhanças grandes.

Um esquema bobo seria fazer um código que monta o arquivo .glsl, que vai ser executado depois. Isso fica bem mais rápido não só por conta de GPU, mas também porque você, por exemplo, pode não iterar sobre a vizinhança, mas exportar ela como uma soma, por exemplo, de A(-1, -1)+A(-1,0)+... e assim por diante

[John F]

Ah, valeu! O teu feedback vale ouro nesse projeto.

1. sim, isso eu vou resolver com aquele "editor" que ainda não existe.
2. vou implementar algo para que o varrimento com o mouse preencha todas as células na regra.
   
   Eu experimentei por números dentro de cada célula mas achei que deixava confuso. Fora que não funcionaria com vizinhanças grandes.
   Você realmente acha importante saber os números nesse caso? Na minha experimentação senti que indo meio a olho, "mais vizinhos, menos vizinhos" já era suficiente.
3. não entendi o que significa "as regras são condicionadas ao input inicial."
   
4. Certo, não achei uma maneira 100% intuitiva de mostrar isso na tela. A caixinha de cor ANTES do range de valores é o seletor do estado que será contado naquela regra.
5. Sim, já tenho no código uma regra tipo "else". Não implementei ainda por que percebi que na verdade isso não é necessário. Você viu que eu implementei Life e Wireworld, certo? Acho que é possível implementar qualquer coisa fazendo ranges 'reversos' (usando o botão direito do mouse no range você inverte o range todo).
6. Eu não imagino bem como encaixar tudo aquilo em uma tela só... Me manda um esboço?
7. Sim... bem lento. Vou dar uma olhada em shaders sim. Tenho na lista também multithreading, mas não sei se vale a pena, seria uma melhora de performance bem linear né. O que acha?
   

--

Você recebeu essa mensagem porque está inscrito no grupo "processing-brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para processing-bra...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para processi...@googlegroups.com.
Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/processing-brasil/7be97d17-0ee7-4a21-8f06-5c3e1c6b9ef4%40googlegroups.com.

[Tatyana Zabanova]

2. Acho relevante ter referência do tipo "100 é aqui, 200 é ali". Não numeração exata, mas alguma orientação justamente a olho.

3. ignore, eu entendi errado. Mas de modo geral, seria legal ter 2 tipos de regras - regras que dependem do estado atual da célula (por exemplo, veja brian's brain que tem 3 estados. Se a célula estava morta, ela fica viva de acordo com alguma regra. Já se a célula estava viva, ela morre com 100% de chance independentemente da vizinhança, e passa para o 3 estado, "morrendo". E se a célula estava "morrendo", ela fica morta, independentemente da vizinhança". Enfim, suporte para esse tipo de regra

4. para multi-estados, é bem mais fácil trabalhar com soma mesmo. Porque imagina que você tem uns 60 estados. Se você for contar por tipo, você morre fazendo regra. Talvez um "type" na regra, que permita escolher entre contagem e soma direta (e, neste caso, atribuir números sequenciais aos estados, 0 a n-1). Outro tipo de regra legal de se ter embutido é: se estado for x, no próximo passo vai ser x-1 (dê uma olhada em brian's brain) independentemente da vizinhança, isso é bastante usado e seria legal já ter pronto.

5. tenho um desafio para você, então: tente implementar algo deste tipo aqui https://github.com/tatasz/PCD-SP-19/tree/master/sketch_12_double. Neste exemplo, eu uso regras similares, e estou com preguiça de dar upload em um que tem regras inteiramente diversas, mas enfim, algo nesse estilo.

6. Aqui tem bastante espaço no modo dela cheia: https://sta.sh/02aqaexcqh65. Talvez deixar os estados menores ou coisa que o valha, e fazer um preview pequeno, tipo 200x200 ou 400x400 (usando pixels mesmo, não 2x2 ou 3x3 para cada célula). Para poder facilmente testar se está razoável

7. Eu partiria para shaders mesmo, acho mais simples e mais rápido, porque a única coisa que precisa é compilar o "código" do shader a partir das vizinhanças e regras

[contact....@gmail.com]

Parabéns! Estou curioso pra ver. Pela imagem que você mandou parace a reação belousov-zhabotinsky. Muito bom!

Infelizmente, não consegui testar pelo fato de que ao executar o projeto a CPU e o cooler disparam, e como o gerenciamento térmico atual aqui não é dos melhores, optei por não comprometer a integridade do hardware.

De qualquer forma, perfilei rapidamente o projeto na esperança de encontrar a(s) origem(s) dessa questão, conforme as imagens em anexo. Uma imagem mostra a lista de métodos com o tempo de CPU em ordem decrescente, e a outra imagem mostra a árvore de processos com as threads mais críticas (pictograma de chama vermelha). Uma hipótese preliminar é de que o monitor de eventos do mouse encontre um gargalo, que pode acontecer quando as operações executadas a cada evento do mouse sejam de uma complexidade elevada. Mas com certeza demanda investigação, afinal estou falando sobre resultados que obtive apenas em meu computador.

[Alexandre Villares]

Retomando o assunto dos autômatos celulares:

Olha que divertido este material do Kjetil Midtgarden Golid (https://generated.space):

Cellular Automata in the Browser

https://javascript.christmas/2019/22

https://generated.space/sketch/hatch-automata-full/#53:156:110

abraços,

Alexandre

---

https://abav.lugaralgum.com