Problème de boucle Brainf * ck

19

J'ai un problème pour un cyber club qui vous demande d'imprimer:

ZYXWVUTSRQPONMLKJIHGFEDCBA@?>=<;:9876543210/.-,+*)('&%$#"!

Utilisation de Brainf ** k en 29 octets ou moins sans utiliser le caractère «,».

J'ai un code de travail:

++++++++++[>++++++>+++++++++<<-]>-->.<[>-.<-]

Cependant ma boucle est trop longue, m'envoyant 16 octets au-dessus de la limite.

Existe-t-il un moyen plus efficace de définir la deuxième et la troisième cellule sur 58 et 90 pour que je puisse exécuter ma deuxième boucle? Ou existe-t-il une meilleure façon de faire tout cela ensemble que je ne vois tout simplement pas?

code-golf tips brainfuck Nick Rod
la source
1
En ce qui concerne votre question, bien qu'il n'économise que quatre octets, il est en fait préférable de générer 59 et 90 et de modifier le -.en .-supprimant le >.<.
Martin Ender
J'ai obtenu +[--->++<]>++++[.-]pour 19 octets mais il
affiche
@MartinEnder Ouais désolé, j'ai vu votre commentaire sur l'autre post et trouvé ce groupe qui semblait beaucoup plus approprié, je vais supprimer celui sur SO car il n'a pas généré beaucoup de réponses.
Nick Rod
2
Je suis honnêtement curieux de savoir ce qu'est ce "cyber club", car ils doivent avoir de très bons golfeurs!
Sp3000

Réponses:

23

27 24 octets

++[<++[++<]>>>+]<[-<-.>]

J'ai passé une journée entière à écrire un forceur de brut et à regarder les résultats arriver. Maintenant, je peux recommencer à faire du vrai travail ... Un autre jour de forçage brutal plus tard ...

Essayez-le en ligne!

Le composant ++[<++[++<]>>>+]initialise la bande à

[130, 0, 0, 0, 91, 59, 0]
                       ^

qui est tout simplement parfait pour ce dont nous avons besoin!

Sp3000
la source
8
Sorcellerie. (∩｀-´) ⊃━ ☆ ﾟ. * ･｡ ﾟ
primo
@primo Pour être honnête, je n'ai aucune idée de ce qui se passe sur le plan de la structure au cours du premier semestre, et je pense que le fait que vous puissiez trouver vos propres algorithmes / techniques est incroyable :)
Sp3000
Bande à la fin de chaque boucle: codepad.org/ZoJUlQ8M . Ce n'est pas du tout intuitif que cela se termine aux valeurs qu'il fait, ou même pas du tout;)
primo
1
Une alternative 24:+[[>++<<]>->+>+]<[-<-.>]
primo
15

30 octets

-<-[>+>-[---<]>]>++>+[---<.->]

Essayez-le en ligne!

85 et 171 sont assez faciles à générer en brainfuck (inverses modulaires de 3 et -3 ). 85 est assez proche de 90 et 171 est assez proche de 177 ( 59 · 3 ), qui est utilisé ici. Avec un peu de piratage, je peux produire à la place 88 et 176 .

Encore un octet de moins que la cible.

Autres suggestions

En général, il est plus court d'itérer sur une liste, multipliant par une constante, plutôt que dans l'autre sens. Cela est particulièrement vrai pour 3 valeurs ou plus. Par exemple, ceci:

++++++++++[>++++++>+++++++++<<-]

peut s'écrire:

+>++++[+++++[>++++++++++<-]<]>

Il n'y avait que deux valeurs intérieures, donc ce n'est pas vraiment une amélioration dans ce cas. En fait, le simple refactoring est un octet plus court:

+++++[>++++++[>++>+++<<-]<-]>

Multipliant 30 par 2 et 3 , plutôt que 10 par 6 et 9 . Avec la suggestion de Martin Büttner, cela est déjà descendu à 38 octets, sans grand changement par rapport à l'original:

+++++[>++++++[>++>+++<<-]<-]>>-[>.-<-]
primo
la source
Je n'aurais jamais pensé multiplier le 58 et répéter par un plus grand nombre, c'est beaucoup plus efficace.
Nick Rod
4

34 octets

Vous avez enregistré 11 octets, mais encore 5 octets trop longtemps ...

+[--->++<]>++++<+[--------->.-<]>.

J'ai déjà passé des heures, j'espère que quelqu'un pourra s'améliorer.

Timtech
la source