Вибачте, люди цього разу не шестикутники ...
Кількість байтів передбачає кодування ISO 8859-1.
.+¶
$.'$*_¶$&
^_¶
¶
((^_|\2_)*)_\1{5}_+
$2_
^_*
$.&$*×_$&$&$.&$*×
M!&m`(?<=(?=×*(_)+)\A.*)(?<-1>.)+(?(1)!)|^.*$
O$`(_)|.(?=.*$)
$1
G-2`
T`d`À-É
m`\A(\D*)(?(_)\D*¶.|(.)\D*¶\2)((.)(?<=(?<4>_)\D+)?((?<=(?<1>\1.)\4\D*)|(?<=(?<1>\D*)\4(?<=\1)\D*)|(?<=\1(.(.)*¶\D*))((?<=(?<1>\D*)\4(?>(?<-7>.)*)¶.*\6)|(?<=(?<1>\D*)(?=\4)(?>(?<-7>.)+)¶.*\6))|(?<=(×)*¶.*)((?<=(?<1>\1.(?>(?<-9>¶.*)*))^\4\D*)|(?<=(?<1>\D*)\4(?>(?<-9>¶.*)*)(?<=\1)^\D*)|(?<=(?<1>\1\b.*(?(9)!)(?<-9>¶.*)*)\4×*¶\D*)|(?<=(?<1>\D*\b)\4.*(?(9)!)(?<-9>¶.*)*(?<=\1.)\b\D*))|(?<=(?<1>\1.(?>(?<-11>.)*)¶.*)\4(.)*¶\D*)|(?<=(?<1>\1(?>(?<-12>.)*)¶.*)\4(.)*¶\D*)|(?<=(?<1>\1.(?>(?<-13>.)*¶\D*))\4(\w)*\W+.+)|(?<=(?<1>.*)\4(?>(?<-14>.)*¶\D*)(?<=\1.)(\w)*\W+.+))(?<=\1(\D*).+)(?<!\1\15.*(?<-1>.)+))*\Z
Очікує цільовий рядок у першому рядку та шестикутник у другому рядку введення. Друкує 0або 1відповідно.
Спробуйте в Інтернеті! (Перший рядок включає тестовий набір, де кожен рядок є тестовим випадком, використовуючи¦ для розділення замість передачі рядка.)
Правильний спосіб вирішити цю проблему - це, звичайно, підсумок. ;) І якби не те, що цей виклик також передбачає процедуру розгортання шестикутника , ця відповідь насправді складалася б із нічого, окрім одного 600-байтного довгого виразного вираження.
Це ще не зовсім оптимально для гольфу, але я цілком задоволений результатом (моя перша робоча версія, після видалення названих груп та інших речей, необхідних для розуму, становила близько 1000 байт). Я думаю, що я міг би зберегти близько 10 байтів, змінивши порядок рядка та шестикутник, але це потребує повного переписування регулярного виразу в кінці, чого я зараз не відчуваю. Існує також 2-байт економія, опустивши Gсцену, але це значно сповільнює рішення, тому я зачекаю, коли я внесу ці зміни, поки не переконаюся, що я переграв це так добре, як зможу.
Пояснення
Основна частина цього рішення широко використовує балансуючі групи , тому я рекомендую ознайомитися з ними, якщо ви хочете зрозуміти, як це працює в деталях (я не буду звинувачувати вас, якщо ви цього не зробите ...).
Перша частина рішення (тобто все, крім двох останніх рядків) - це модифікована версія моєї відповіді на Розгортання вихідного коду Гексагонії . Він конструює шестикутник, залишаючи цільовий рядок недоторканим (і він фактично будує шестикутник перед цільовим рядком). Я вніс деякі зміни до попереднього коду, щоб зберегти байти:
- Фоновий символ
×замість пробілу, щоб він не вступав у конфлікт із потенційними пробілами на вході.
_Замість цього використовується символ неоперації / підстановки ., щоб комірки сітки можна було надійно ідентифікувати як символи слова.- Я не вставляю пробілів чи відступів після того, як шестикутник спочатку побудований. Це дає мені похилий шестикутник, але це насправді набагато зручніше працювати, а правила суміжності досить прості.
Ось приклад. Для наступного тестового випадку:
ja
abcdefghij
Ми отримуємо:
××abc
×defg
hij__
____×
___××
ja
Порівняйте це зі звичайною компоновкою шестикутника:
a b c
d e f g
h i j _ _
_ _ _ _
_ _ _
Ми можемо бачити, що сусідами зараз є всі звичні 8 сусідів Мура, за винятком північно-західних та південно-східних сусідів. Тому нам потрібно перевірити горизонтальну, вертикальну і південно-західну / північно-східну прилягання (ну а далі є краї обгортання). Використання цього більш компактного макета також має бонус, що ми зможемо використовувати ті, хто ××знаходиться в кінці, щоб визначити розмір шестикутника на льоту, коли нам це буде потрібно.
Після того, як ця форма була побудована, ми робимо ще одну зміну для всього рядка:
T`d`À-É
Це замінює цифри розширеними літерами ASCII
ÀÁÂÃÄÅÆÇÈÉ
Оскільки вони замінені як в шестикутнику, так і в цільовому рядку, це не вплине на відповідність рядка чи ні. Також, оскільки вони букви \wі \bдосі ідентифікують їх як шестикутні клітини. Перевага цієї заміни полягає в тому, що тепер ми можемо використовувати \Dв майбутньому регулярному виразі відповідність будь-яким символам (зокрема, стрічкам рядків, а також символам, що не входять в рядок). Ми не можемо скористатися цим sваріантом, оскільки нам потрібно .буде відповідати символам, які не передаються без ліній, у кількох місцях.
Тепер останній біт: визначення того, чи відповідає будь-який шлях нашому заданому рядку. Це робиться за допомогою одного жахливого виразного виразу. Ви можете запитати себе, чому?!?! Ну, це в основному проблема зворотного відстеження: ви починаєте десь і пробуєте шлях до тих пір, поки він відповідає рядку, і як тільки він не буде відслідковувати і спробувати іншого сусіда з останнього символу, який працював. Theодна річщо ви отримуєте безкоштовно під час роботи з регулярною вивізкою - це зворотній трек. Це буквально єдине, що робить движок-регекс. Отже, якщо ми просто знайдемо спосіб описати дійсний шлях (який досить складний для подібного роду проблем, але, безумовно, можливий для балансуючих груп), тоді двигун регулярного генерування розібрає пошук цього шляху серед усіх можливих для нас. Звичайно, можна було б здійснити пошук вручну з декількома етапами ( і я це робив раніше ), але я сумніваюся, що в цьому конкретному випадку він буде коротшим.
Одне питання щодо впровадження цього методу за допомогою регулярного вираження полягає в тому, що ми не можемо довільно переплести курсор двигуна регулярних вирівнювань назад і назад через рядок під час зворотного відстеження (що нам знадобиться, оскільки шлях може йти вгору або вниз). Отже, натомість ми відстежуємо власний "курсор" у групі захоплення та оновлюємо це на кожному кроці (ми можемо тимчасово переміщатися до положення курсору за допомогою пробігу). Це також дозволяє нам зберігати всі минулі позиції, які ми використовуватимемо для перевірки того, що раніше не відвідували поточну позицію.
Тож давайте до цього. Ось дещо безпечніша версія регулярного виразу, з названими групами, відступом, менш випадковим порядком сусідів та деякими коментарями:
\A
# Store initial cursor position in <pos>
(?<pos>\D*)
(?(_)
# If we start on a wildcard, just skip to the first character of the target.
\D*¶.
|
# Otherwise, make sure that the target starts with this character.
(?<first>.)\D*¶\k<first>
)
(?:
# Match 0 or more subsequent characters by moving the cursor along the path.
# First, we store the character to be matched in <next>.
(?<next>.)
# Now we optionally push an underscore on top (if one exists in the string).
# Depending on whether this done or not (both of which are attempted by
# the engine's backtracking), either the exact character, or an underscore
# will respond to the match. So when we now use the backreference \k<next>
# further down, it will automatically handle wildcards correctly.
(?<=(?<next>_)\D+)?
# This alternation now simply covers all 6 possible neighbours as well as
# all 6 possible wrapped edges.
# Each option needs to go into a separate lookbehind, because otherwise
# the engine would not backtrack through all possible neighbours once it
# has found a valid one (lookarounds are atomic).
# In any case, if the new character is found in the given direction, <pos>
# will have been updated with the new cursor position.
(?:
# Try moving east.
(?<=(?<pos>\k<pos>.)\k<next>\D*)
|
# Try moving west.
(?<=(?<pos>\D*)\k<next>(?<=\k<pos>)\D*)
|
# Store the horizontal position of the cursor in <x> and remember where
# it is (because we'll need this for the next two options).
(?<=\k<pos>(?<skip>.(?<x>.)*¶\D*))
(?:
# Try moving north.
(?<=(?<pos>\D*)\k<next>(?>(?<-x>.)*)¶.*\k<skip>)
|
# Try moving north-east.
(?<=(?<pos>\D*)(?=\k<next>)(?>(?<-x>.)+)¶.*\k<skip>)
)
|
# Try moving south.
(?<=(?<pos>\k<pos>.(?>(?<-x>.)*)¶.*)\k<next>(?<x>.)*¶\D*)
|
# Try moving south-east.
(?<=(?<pos>\k<pos>(?>(?<-x>.)*)¶.*)\k<next>(?<x>.)*¶\D*)
|
# Store the number of '×' at the end in <w>, which is one less than the
# the side-length of the hexagon. This happens to be the number of lines
# we need to skip when wrapping around certain edges.
(?<=(?<w>×)*¶.*)
(?:
# Try wrapping around the east edge.
(?<=(?<pos>\k<pos>.(?>(?<-w>¶.*)*))^\k<next>\D*)
|
# Try wrapping around the west edge.
(?<=(?<pos>\D*)\k<next>(?>(?<-w>¶.*)*)(?<=\k<pos>)^\D*)
|
# Try wrapping around the south-east edge.
(?<=(?<pos>\k<pos>\b.*(?(w)!)(?<-w>¶.*)*)\k<next>×*¶\D*)
|
# Try wrapping around the north-west edge.
(?<=(?<pos>\D*\b)\k<next>.*(?(w)!)(?<-w>¶.*)*(?<=\k<pos>.)\b\D*)
)
|
# Try wrapping around the south edge.
(?<=(?<pos>\k<pos>.(?>(?<-x>.)*¶\D*))\k<next>(?<x>\w)*\W+.+)
|
# Try wrapping around the north edge.
(?<=(?<pos>.*)\k<next>(?>(?<-x>.)*¶\D*)(?<=\k<pos>.)(?<x>\w)*\W+.+)
)
# Copy the current cursor position into <current>.
(?<=\k<pos>(?<current>\D*).+)
# Make sure that no matter how many strings we pop from our stack of previous
# cursor positions, none are equal to the current one (to ensure that we use
# each cell at most once).
(?<!\k<pos>\k<current>.*(?<-pos>.)+)
)*
# Finally make sure that we've reached the end of the string, so that we've
# successfully matched all characters in the target string.
\Z
Я сподіваюся, що загальна думка з цього приблизно зрозуміла. Як приклад того, як працює один з цих рухів по шляху, давайте розглянемо біт, який переміщує курсор на південь:
(?<=(?<pos>\k<pos>.(?>(?<-x>.)*)¶.*)\k<next>(?<x>.)*¶\D*)
Пам'ятайте, що вигляд ззаду слід читати справа наліво (або знизу вгору), тому що це порядок, у якому вони виконуються:
(?<=
(?<pos>
\k<pos> # Check that this is the old cursor position.
. # Match the character directly on top of the new one.
(?>(?<-x>.)*) # Match the same amount of characters as before.
¶.* # Skip to the next line (the line, the old cursor is on).
) # We will store everything left of here as the new
# cursor position.
\k<next> # ...up to a match of our current target character.
(?<x>.)* # Count how many characters there are...
¶\D* # Skip to the end of some line (this will be the line below
# the current cursor, which the regex engine's backtracking
# will determine for us).
)
Зауважте, що не потрібно ставити якір перед значком, \k<pos>щоб переконатися, що це насправді доходить до початку рядка. <pos>завжди починається з кількості, ×яку не можна знайти більше ніде, тому це вже є неявним якорем.
Я не хочу розкривати цю посаду більше, ніж потрібно, тому я не буду детально описуватись в інших 11 випадках, але в принципі всі вони працюють аналогічно. Ми перевіряємо, що <next>можна знайти в якомусь конкретному (допустимому) напрямку зі старого положення курсору за допомогою балансуючих груп, а потім зберігаємо рядок до цього збігу як нове положення курсору в <pos>.