L'image ci-dessus est appelée hexa-glyphe. Les hexa-glyphes sont des modèles sympas que j'ai créés en griffonnant pendant ma classe DiffEq. Voici comment vous en créez un:
- Considérez l'ensemble de points suivant, en forme d'hexagramme régulier. L'hexagone intérieur est ce qui contiendra le glyphe final, tandis que les 6 points extérieurs forment une étoile et c'est là que nous commencerons à dessiner nos lignes.
- À partir des six points extérieurs, sélectionnez au hasard une paire. Pour plus d'efficacité, il devrait y avoir au moins un autre point entre les deux points sélectionnés (sinon, cela n'aurait aucun effet sur le chiffre final). Ensuite, à partir de chacun des deux points, lancez un rayon vers l'autre. Ce rayon est bloqué par les lignes précédentes.
- Répétez ce processus jusqu'à ce que les 9 bords aient été formés, comme le montrent les images suivantes.
- Voici un exemple de rayons bloqués. Les extrémités du segment de rayon sont toujours visibles, mais la partie médiane est occluse par les deux premiers segments que nous avons dessinés.
- Ces deux rayons sont également "bloqués", mais cela ne cause aucune différence visible car ils sont bloqués par la même autre ligne.
- Avance rapide jusqu'à ce que les 9 lignes soient dessinées. Si vous souhaitez une explication plus détaillée de ces étapes ignorées, je peux l'exposer.
- Enfin, supprimez les pointes de l'étoile. Pour le rendre plus joli, les points épais sont également supprimés.
Le défi
Votre défi consiste à produire une représentation visuelle d'un hexaglyphe aléatoire. C'est le code-golf, le moins d'octets gagne.
Tous les hexa-glyphes possibles devraient apparaître avec une certaine probabilité positive. Différents hexaglyphes sont générés en modifiant l'ordre dans lequel les 9 bords sont dessinés.
De plus, toutes les images produites par votre programme doivent être des hexa-glyphes valides. Certains modèles (comme un contour complet de l'hexagone intérieur) ne peuvent pas apparaître comme un hexaglyphe, et vous ne devez donc pas les afficher.
La sortie doit être une image graphique (imprimée à l'écran ou dans un fichier).
L'hexagone doit être régulier, mais peut apparaître dans n'importe quelle orientation.
Les réflexions / rotations ne sont pas considérées comme uniques. (Cela pourrait rendre l'exigence 1 plus facile à suivre).
la source
I made up while doodling during my DiffEq class
.'01'
avec de l'espace entrelacé au lieu de' *'
.Réponses:
Mathematica,
273268264242 octetsle
rendu est un exposantT
dans Mathematica et est un opérateur de transposition de suffixe.Il a fallu une éternité pour trier les bogues dans ce dossier ... vers la fin, j'ai piraté quelques éléments ensemble pour le faire fonctionner, donc c'est définitivement sous-optimal. Je me demande également s'il serait mieux dans l'ensemble d'implémenter la spécification plus littéralement via les lignes à travers l'hexagone externe et de laisser les fonctions de géométrie de Mathematica gérer les intersections.
Notez qu'il s'agit d'un programme complet et si vous souhaitez exécuter le code plusieurs fois au cours d'une même session REPL, vous devrez le préfixer avec
Clear[b]
.Voici les résultats de 20 runs:
Explication
Cette solution n'utilise pas du tout les points étoiles externes. Au lieu de cela, il fonctionne directement avec les points qui font partie de l'hexaglyphe et les lignes qui couvrent trois d'entre eux à la fois.
Étiquetons les points:
1
commence dans un coin légèrement bizarre, mais cela est dû au comportement par défaut (également quelque peu bizarre) deCirclePoints
. Le démarrage de l'hexagone à partir de là s'est avéré le moins cher.Maintenant, nous voulons trouver les lignes pertinentes à travers trois de ces points qui correspondent aux points connectés de l'étoile extérieure. Ceux autour de l'hexagone ne sont bien sûr que 3 points adjacents (modulo 12), à partir d'un nombre impair. Celles du centre se composent d'un nombre pair
n
,13
etn+6
.Les représentations de ces lignes (sous forme de listes de trois points sont générées par le code suivant):
Le
Partition
génère les lignes autour de l'hexagone etArray
les lignes passant par le centre. Pour traiter les deux faisceaux, nous mappons cette fonction sur la liste des lignes:Maintenant, nous les mélangeons avec
RandomSample
pour les traiter dans un ordre aléatoire.Join @@
aplatit la liste des paires pour que nous ayons une liste de faisceaux.Interruption courte: pour garder une trace des points qui sont déjà bloqués, nous utilisons une fonction de recherche
b
, qui est initialisée àTrue
pour toutes les valeurs parb@_=k=1>0;
. Lors du traitement d'une poutre, nous gardons tous les points jusqu'au premier point qui ab[n] == False
( y compris celui-ci):J'ai l'impression que c'est la partie la plus jouable en ce moment ... l'utilisation de deux variables temporaires pour jouer à Mastermind semble vraiment chère. Quoi qu'il en soit, le résultat de cela nous donne les points dans une ligne que nous sommes autorisés à dessiner. Maintenant, cette fonction est mappée sur chacun de ces points:
La première partie génère la liste des 13 points en utilisant les résultats entrelacés de deux appels à
CirclePoints
(avec des rayons différents pour les centres des bords et les coins de l'hexagone). Notez leb@#=!k
qui définit désormais la valeur de la table de recherche pour le point actuelFalse
afin qu'aucun faisceau supplémentaire ne puisse le traverser. Enfin, la valeur est utilisée comme index dans la liste des coordonnées pour obtenir le point 2D correct.Cela supprime toutes les listes à élément unique, car elles s'afficheraient sous forme de points individuels (et visibles). Enfin, nous rendons le résultat:
la source
b@_=1>0
=b=1>0&
Chaussures (Ruby) Rev C 184 octets
12 octets économisés en transférant la responsabilité de vérifier si une demi-ligne particulière doit être tirée du programme principal vers la méthode de dessin. Cependant, le programme principal doit encore vérifier si toute la ligne est complètement bloquée.
Chaussures (Ruby)
205... Rev B 196 bytesShoes est un outil à base de rubis pour créer des interfaces graphiques, etc. C'est la première fois que je l'utilise. mothereff.in/byte-counter compte ma soumission comme 196 octets, mais pour une raison quelconque, Shoes la compte comme 202.
De plus, Ruby vous permet de faire des choses comme,
t[a=i.ord]
mais étrangement, il ne semble pas fonctionner comme prévu avec des chaussures.Explication
Je ne considère pas les parties de la ligne en dehors de l'hexagone. Je ne dessine que la partie à dessiner. L'important est de savoir si les lignes traversent les intersections (si nous ne dessinons que les parties qui doivent être dessinées, cela signifie qu'elles commencent / se terminent aux intersections.)
La règle de base est que si les deux extrémités d'une ligne ont été visitées, la ligne est bloquée et ne doit pas être dessinée. Comme les lignes sont tracées en deux moitiés, nous devons également vérifier si le point médian a été visité pour voir si chaque moitié doit être tracée ou non.
Je garde une trace des points qui ont été visités dans le tableau
t[]
. Cela finit par contenir une entrée pour chaque coordonnée physique sur la grille ci-dessous. Il n'y a pas de tableau logique séparé à 13 éléments. À la fin,t[]
peut avoir 87 éléments, mais seulement 13 contiendront des données utiles.En interne, les coordonnées des extrémités des lignes sont données par un seul nombre z, où z% 6 est la coordonnée y et z / 6 est la coordonnée x. Dans ce système, l'hexagone est aplati. Lorsque les lignes sont tracées, l'échelle x est multipliée par 8 et l'échelle y est multipliée par 14, ce qui est une approximation rationnelle très proche du rapport correct: 14/8 = 1,75 vs sqrt (3) = 1,732.
Le système de coordonnées interne est illustré ci-dessous, avec quelques exemples de sorties.
Non golfé
Plus d'exemples de sorties
Cela a été fait avec une ancienne version du programme. La seule différence est que le positionnement de l'hexaglyphe dans la fenêtre est désormais légèrement différent.
la source
mothereff.in/byte-counter counts my submission as 196 bytes, but for some reason Shoes counts it as 202.
Je ne sais pas à 100% si c'est vrai, mais je pense que la raison pour laquelle Shoes a compté votre code comme 202 octets au lieu de 196 est parce que vos nouvelles lignes sont en fait une séquence de deux caractères "\ r \ n". Cela fait que chaque nouvelle ligne est comptée deux fois. Voici une réponse de débordement de pile concernant \ r et \ n.Python,
604591574561538531536534528493483452431420419415388385384 octetsJ'ai adapté l'idée de Level River St de vérifier si une ligne sera bloquée en vérifiant si les deux extrémités de la ligne ont déjà été visitées auparavant. Cela économise 27 octets. Suggestions de golf bienvenues.
Edit: correction de bugs et golf
g(p,q)
pour 3 octets. GolféL
pour un octet.Ungolfing:
Les hexa-glyphes eux-mêmes sont assez petits car nous utilisons un hexagone de 12 pixels comme base (pour des raisons de golf). Voici quelques exemples d'hexa-glyphes (excuses pour les mauvaises récoltes):
la source
R=range;G=goto