2 puntos por GN⁺ 2024-04-30 | 1 comentarios | Compartir por WhatsApp
  • Un paper de SIGBOVIK 2019 comprobó mediante un experimento con OCR si puede ocurrir que al frotar pintura en una pared no se genere un programa Perl, y 93 de 100 manchas fueron parseadas como Perl
  • El experimento consistió en convertir imágenes de manchas de pintura en cadenas OCR y luego verificar si el resultado era un programa Perl válido
  • Aunque el 93% fue válido, las otras 7 manchas no pudieron parsearse como Perl, por lo que siguen existiendo excepciones al chiste de que “siempre termina siendo Perl”
  • El material publicado incluye todas las imágenes de manchas y su código fuente Perl correspondiente; las imágenes no válidas se distinguen con la marca roja “Not valid
  • Algunos resultados de OCR revisados después del envío se evalúan en Perl como el número 0 o como las cadenas c, E__, mostrando lo extrañamente curioso del código generado por casualidad

Posibilidad de parsear Perl verificada con manchas de pintura

  • Este paper toma como objeto de experimento una pregunta presentada como si fuera un antiguo problema abierto de la comunidad de lenguajes de programación: ¿puede ocurrir que al frotar pintura en una pared no se genere Perl válido?
  • La conclusión se acerca a “sí, es posible”
    • En el experimento con software OCR, solo el 93% de las manchas de pintura se parseó como Perl válido
    • Por lo tanto, algunas manchas de pintura no son programas Perl válidos
  • El paper analiza las propiedades de los programas Perl hechos con manchas de pintura y presenta además 7 ejemplos de manchas que no son programas Perl válidos

Paper de SIGBOVIK 2019 y materiales publicados

  • El paper fue aceptado en SIGBOVIK 2019, realizado el 1 de abril de 2019 en Pittsburgh
  • También recibió el “Unwitting Participation Ribbon”
    • Este listón se presenta como uno que se otorga a papers que incluyen “resultados reales”
  • El paper y las actas están publicados en varios formatos

Galería de manchas y dataset de 100 imágenes

  • all the paint splatters reúne todas las manchas de pintura en una sola página y también ofrece el código fuente Perl válido correspondiente a cada imagen
  • Las imágenes que no se parsearon como programas Perl válidos se distinguen con la marca roja “Not valid
  • Cuando se reconocieron varios programas Perl válidos con distintas configuraciones de OCR, se eligió el resultado considerado más “interesante”
  • tarball of 100 paint-splatter images contiene las 100 imágenes de manchas de pintura usadas como dataset principal del paper

Casos adicionales identificados después del envío

  • Incluso después de la fecha límite de envío a SIGBOVIK, se identificaron más programas Perl interesantes a partir de manchas de pintura
  • Una mancha que el OCR reconoció como lerzfijglpFiji-j se evalúa en Perl como el número 0
  • Una mancha reconocida como -*? también se evalúa en Perl como el número 0
  • Una imagen reconocida como ;i;c;;#\\?z{;?;;fn':.; se convierte en Perl en la cadena c
  • Una imagen reconocida como ;E,'__' se evalúa en Perl como la cadena E__

1 comentarios

 
GN⁺ 2024-04-30
Comentarios de Hacker News
  • Los lenguajes concatenativos tienen la propiedad de que toda secuencia de tokens es un programa válido.
    Si un lenguaje usa bits individuales como tokens, entonces toda cadena de bits se vuelve un programa válido. zot, de Chris Barker, es uno de esos lenguajes.
    Inspirado en zot, definí una versión concatenativa del Binary Lambda Calculus que comparte esa misma propiedad.
    [1] https://en.wikipedia.org/wiki/Concatenative_programming_lang...
    [2] https://en.wikipedia.org/wiki/Iota_and_Jot#Zot
    [3] https://cstheory.stackexchange.com/questions/32309/concatena...

    • No me parece correcto decir que “los lenguajes concatenativos tienen la propiedad de que toda secuencia de tokens es un programa válido”.
      La propiedad de un lenguaje concatenativo es que si a y b son programas válidos, entonces a || b también es un programa válido. Aquí || significa “concatenar”.
      Pero esa propiedad no implica que toda secuencia de tokens sea válida. Por ejemplo, en Cat, [1 2 no es sintácticamente válido.
    • La frase “hace de Jot una numeración de Gödel natural de todos los algoritmos” suena genial.
      Ojalá pudiera entender tanto Jot como esa frase.
  • Me pareció divertida la nota al pie 5.
    ⁵ Esta funcionalidad permite hacer un quine elegante. Si se guarda el programa Perl “Illegal division by zero at /tmp/quine.pl line 1.” en la ubicación adecuada, imprime “Illegal division by zero at /tmp/quine.pl line 1.”. El motivo de este comportamiento queda como ejercicio para el lector.

    • Escribí una entrada de blog que lo explica: https://dotat.at/@/2019-04-04-a-curious-perl-quine.html
      Y también hay un quine en Python que a primera vista parece relacionado, pero en realidad es bastante distinto:
      File "quine.py", line 1
      File "quine.py", line 1
      ^
      IndentationError: unexpected indent
    • ¿Alguien puede ayudar a los lectores que no saben Perl?
      Probándolo en el REPL, "Illegal division" no encuentra el método "illegal" en el paquete "division", y probablemente esa parte se ignora. El método "by" del paquete "zero" parece similar, y "at /tmp" parece ser la cadena más simple que genera ese mensaje de error. Parece que este error es más grave que la advertencia por paquete faltante, así que termina el programa.
      Pensé que / era el operador de división y que "tmp" se inicializaba como variable y luego se forzaba a entero, pero "/tmp" por sí solo no funciona, y "/tmp/" activa un comportamiento relacionado con expresiones regulares, así que no entiendo por qué el parser interpreta una división ahí.
    • En Python también se puede hacer algo parecido con un error de indentación.
  • Artículos relacionados:
    93% of Paint Splatters Are Valid Perl Programs (2019) - https://news.ycombinator.com/item?id=27929730 - julio de 2021, 163 comentarios
    Otro enlace:
    93% of Paint Splatters Are Valid Perl Programs (2019) - https://news.ycombinator.com/item?id=38754686 - diciembre de 2023, 1 comentario

  • Bromas aparte, ¿no está mal que el software de OCR todavía siempre produzca texto incluso a partir de imágenes que no son texto?
    Hace más de 10 años hice OCR de un libro viejo, y recuerdo que fue muy frustrante lidiar con texto basura generado a partir de dibujitos, manchas y polvo. Esta área no parece haber avanzado mucho desde entonces.

    • Esa pregunta me parece del mismo tipo que la del artículo original.
      Si garabatos aleatorios se convierten en una ejecución válida en Perl, ¿no hay algo mal?
    • En esta parte, los LLM ayudan.
      Por experimentos propios, ChatGPT resultó ser un agente de OCR “inteligente y consciente del contexto” bastante decente.
    • Sí hubo avances. Solo que el artículo presentado es para divertirse.
  • Entendí que este artículo trata sobre el problema de que cierto programa de reconocimiento óptico de caracteres reconoce salpicaduras de pintura como caracteres.
    Ese programa parece tener la tendencia de intentar reconocer casi siempre la pintura como alguna combinación de caracteres, y entre las muchas formas posibles de implementarlo, esta es bastante aceptable y acorde con la intención.
    Pero al principio también se me ocurrió otro enfoque: ver los fragmentos de color y los espacios vacíos como 0 y 1, e interpretar todo como un programa. En ese caso, la mayor parte probablemente sería ruido sin sentido.
    Al final hay dos extremos: uno es casi puro ruido, y el otro tiene significado en su mayor parte. El juego dentro del juego aquí parece ser encontrar una interpretación que atribuya la mayor cantidad posible de significado a las salpicaduras de pintura, pero procurando que ese significado surja de la estructura misma y no de reglas que fuerzan la búsqueda de sentido.

    • Eso de que “reconoce casi siempre pain como alguna combinación de caracteres”... entonces habrá que sacar el electroencefalógrafo y ver si pain también es un programa Perl válido.
  • Con IA generativa, se pueden crear salpicaduras de pintura nuevas e innovadoras que se evalúan como software ejecutable más rápido que nunca.
    La IA generativa permite que una nueva clase de creadores use flujos de trabajo de texto a imagen para generar valor para empresas de todos los tamaños. Los nuevos modelos de IA pueden insertar software funcional y código legible por máquina en contenidos de alta resolución de todo tipo, captando la atención de los espectadores y ofreciendo nuevas y emocionantes formas para que los creadores hagan crecer su audiencia.

  • La investigación computacional más de punta está aquí: https://sigbovik.org/

  • Es una variante inteligente del viejo chiste de que “no se distingue del ruido de línea”.
    Para quienes no hayan estado expuestos a mucho ruido de línea, imaginen una terminal de video con caracteres ASCII que interpreta un flujo de bytes y muestra texto significativo. Ahora supongamos que el canal de comunicación se corrompe por algún motivo. Por ejemplo, alguien levanta el auricular mientras el módem está conectado, o hay interferencia en el cable.
    Sin corrección de errores ni checksums, los bytes interpretados se vuelven prácticamente aleatorios. Así que se interpretan y muestran en pantalla letras, números, signos de puntuación y caracteres de control al azar, y quien está familiarizado entiende que es aleatorio y por qué. Pero el chiste es que en realidad sigue siendo un programa Perl válido.

    • Acabo de darme cuenta de que el ruido de línea ya entra en la categoría de cosas que son imposibles de explicarles a los chicos de hoy, como la programación televisiva.
      Ya que estamos, mejor me ato una cebolla al cinturón.
  • Como dijo “Todavía no hay código fuente. No sé usar GitHub”, parece que desapareció para siempre.
    Al menos no está en https://git.mcmillen.dev/explore/repos.

  • Como programador de Perl, considero que el 7% que no funciona es un bug.