Про задачу четвертого дня сказать особенно нечего. По условию – проще третей. По парсингу ввода – проще второй. Решается быстро.
Сразу прикинул, что с использованием примитивов или оборачиванием в типы из стандартной библиотеки – будет портяночно. Поэтому – отдельный класс с логикой:
И короткое решение с его помощью:
В начале была лень… Стойкое нежелание возиться с границами массивов. Оно, и только оно толкнуло меня на скользкую дорожку замены матрицы примитивов на List<List<>>.
Следующим шагом на пути окунания в пучины многословия – стало создание контейнеров для упаковки данных со “схемы двигателя”:
У меня было три штуки рекордов, несколько методов с регулярно вычисляющей одно и то же логикой внутри них и россыпь операций по упаковке простого содержимого в сложные формы. Не то, чтобы всё это было нужно в решении задачи, но раз начал коллекционировать объекты, то иди в своём увлечении до конца.
Это очень опасное предприятие закончилось благополучно! Длинная подготовка вылилась в достаточно короткие решения. Пришло удивительное, вселенское ощущение правильности всего того, что я делал.
Страшный, длинный, мучительный парсинг ввода…
Хотелось бы, конечно, иметь возможность сделать по-перловому, что-то типа:
echo -e "Game 1: 3 blue, 4 red; 1 red, 2 green, 6 blue; 2 green\nGame 2: 1 blue, 2 green; 3 green, 4 blue, 1 red; 1 green, 1 blue" | perl -wlne '@Matches = $_ =~ /(?:\G(?!\A)|^Game) (\S+)/g; print join("=",@Matches)'
Немного почистить после, или сразу докрутить регулярку, чтобы не захватывала разделители. Сложить в хэш. И закончить кучей циклов в итоге 🙁
С другой стороны – и возня с java Matcher не вдохновляла, и описывать структуру в виде POJO – для чисто скриптового решения – зачем.
split – дёшево и сердито, fastpath бонусом. К счастью – ввод был одинаков для обеих частей загадки.
Вид этой портянки мне не особо мил, особенно for внутри (mapMulti взамен?). Но и как-то значимо “облагородить” её не удалось с ходу – получалась куча менее понятных map, происходящее в которых сложно осознать уже через пару десятков минут.
А часики тикают, задачи требуют решений – и пора двигаться дальше!
Снова AoC – и снова начат с опозданием. Дуплет! Основная идея прежняя – решать в jshell, пока это не станет слишком многословным. Экономия на буковках, в общем.
Обвязка для загрузки условий задачи – та же, что для AoC-2022.
Достаточно простое и короткое получилось решение, отлично сработало для первой части пазла – и практически никак не подошло для второй.
Но совсем бесполезным решение для первой части назвать нельзя – оно легло в основу универсального решения.
Жаль, что (для экономии буковок) – не удалось отыскать где-нибудь в недрах стандартной библиотеки готовых привязок цифр к числительным. Хотя и ожидаемо.
Загадка первого дня была не слишком сложной, но поначалу пошла туговато на фоне повседневного “перекладывания жысонов“.
Тем полезней переключаться! Участвуй!
