Subcarga, 196 bytes
()()(<svg width="99" height="147">)S(<g transform="translate):S((33,33)">)S((3,0)rotate)*a(*a(~*)*~("><path d="M0h3" stroke="#"/>)~*a(*)**:(-90)a~^~(90)a~^)*::*:**:*^S(</g>)(:*)::*:**:*^S(</svg>)S
Eu pensei que poderia ser interessante tentar esse desafio em um esolang de baixa potência; O Underload se sai bem em um idioma com um número tão baixo de comandos.
A saída é um arquivo SVG com tags muito aninhadas e alguns atalhos de golfe. Até agora, não encontrei um navegador que possa exibi-lo (o Firefox trava por vários minutos tentando carregá-lo, e o Firefox e o Chromium exibem uma tela em branco). A maioria dos programas de processamento de imagens também não pode carregá-lo (dificultando a conversão para outro formato), mas consegui carregá-lo no visualizador de imagens Eye of Gnome (que faz parte da instalação padrão no Ubuntu). Então, tirei uma captura de tela da imagem para que você possa vê-la (a imagem real tem um plano de fundo transparente, mas você não pode capturar uma tela transparente):
Precisamos especificar o tamanho da imagem explicitamente. Escolher uma orientação apropriada para a imagem, desenhar tudo no tamanho mínimo legal e fazer o número mínimo de iterações especificadas pelo desafio, nos dá uma imagem que cabe apenas em 99 pixels de largura, economizando um byte. É bom quando as coisas funcionam assim.
O algoritmo geral usado para desenhar a imagem é manter duas variáveis (não subcarga não nomear variáveis, mas eu pensei neles como x e y ), ambos inicialmente vazio. Em seguida, substituímos repetidamente ( x , y ) por ( x , vire à esquerda e avance, y ) e ( x , vire à direita e avance, y ). Após dez iterações, x e y mantêm uma curva de dragão de nove iterações.
Também existem algumas micro-otimizações e truques específicos para o Underload. A fim de evitar o excesso de brincar com o topo da pilha, cada iteração do loop, começamos combinando x e y para a função "retornar a string criado pela concatenação: x , uma instrução por sua vez, o argumento da função, um movi- instrução para a frente e y ". Essa função ocupa apenas um espaço na pilha, para que possamos duplicá-la, chamá-la -90
como argumento, trocar o valor de retorno pela duplicata e chamá-la 90
como argumento para obter novos valores para x e ysem precisar tocar mais do que os dois principais elementos da pilha (que são de longe os mais acessíveis). Esta função é gerada por código em tempo de execução. O gerador em si também é gerado por código em tempo de execução, para permitir a reutilização da string <g transform="translate
que também é usada para definir a origem da imagem. Primeiro, geramos todas as tags abertas e, em seguida, porque todas as tags de fechamento são justas </g>
, podemos produzir 1024 tags de fechamento simplesmente repetindo a string, sem nos preocupar em correspondê-las às tags abertas. (Escrever números eficientemente em Underload é um problema interessante por si só; (:*)::*:**:*
provavelmente é a maneira mais eficiente de escrever 1024, traduzindo "2 para a potência de (1 + 2 × 2) × 2").
O Underload não possui bibliotecas gráficas, por isso produzo SVG usando uma combinação de linhas de desenho em uma posição fixa e girando a imagem em torno de um determinado ponto; em vez de girar a caneta, giramos o papel. A idéia é que, desenhando uma linha, girando a imagem inteira, desenhando outra linha, girando a imagem novamente etc., podemos simular efetivamente gráficos de tartarugas sem ter que fazer nenhuma aritmética ou usar bibliotecas de gráficos, pois todas as linhas são desenhadas no mesmo local. Obviamente, isso significa que temos algumas tags de rotação da imagem muito aninhadas, o que confunde muitos visualizadores SVG.
O estilo da imagem contaria contra a contagem de bytes, portanto, eu precisava fornecer o estilo mínimo necessário para exibir a imagem. Isso acaba sendo stroke="#"
, que mais ou menos se traduz como "a linha precisa ter alguma cor"; isso parece ser expandido para desenhá-lo em preto. (Normalmente, você especificaria a cor como, por exemplo, "# 000".) O plano de fundo é transparente por padrão. Não especificamos uma largura de traçado, mas a escolha escolhida pelo Olho do Gnomo deixa tudo visível.
Muitos intérpretes do Underload lutam com esse programa, por exemplo, o do Try It Online falha, porque gera algumas seqüências muito grandes internamente. O intérprete online Underload original funciona, no entanto. (Interessante, o primeiro intérprete estava on-line, portanto o idioma era utilizável on-line antes de ser usado off-line.)
Algo que me incomoda um pouco é que parece haver apenas 1023 segmentos de linha aqui, e esperamos 1024. Pode ser que um dos segmentos no final não esteja sendo desenhado com esse algoritmo (seria desenhada na próxima iteração). Se isso é desqualificante, pode ser possível adaptar o programa, mas pode acabar bem mais longo. (Não é como se esse desafio vencesse a competição de qualquer maneira; já existem várias inscrições mais curtas.)