Wataru, если буду писать я - это скорее будет тупо массив размером с этажи, заполненный нулями, 1 на 12 этаже и цикл по этому массиву, проверяющий наличие 1, добавляющий вычисленные от этого места 1, если они еще 0, и заменяющий эту 1 на 2.
Не факт, что это будет более эффективно, чем BFS. Зато не требует вообще никакой теории графов ;)
Wataru, да, это не развернутая рекурсия, потому что здесь она и не нужна.
Достаточно списка этажей, на которые можно попасть, и списка тех, на которых уже оба варианта посчитаны.
И перебор первого списка с его дополнением и переносом во второй, пока первый не закончится.
Причин громоздить графы вокруг столь тривиальных данных не вижу совершенно. Особенно если
mayton2019, данные могут быть подобраны так, что этажей - миллионы, а достижимых из них - пять.
Второй этап, соответственно, только впустую нагреет процессор.
Xiran, значит, с рекурсией лучше не рисковать и развернуть ее в цикл.
А для того, чтобы не держать состояние, достаточно помечать этажи как посещенные, но не пройденные.
Когда задача проанализирована - варианты алгоритма довольно очевидны.
Xiran, какие, на хрен, варианты? Готовые алгоритмы используются, когда задача после всестороннего анализа сведена к типовой. Хватаясь за них вместо анализа - просто обделаешься на олимпиаде, поскольку там любят задачи, которые только выглядят как типовые, но на самом деле таковыми не являются.
vaut, для работы в основном в браузере DE почти некритично. Аппетиты браузеров давно уже на порядок превышают расходы на DE.
Кстати, для работы только в браузере можно DE вообще не ставить - запускать сразу Хромиум в xinit, и все...
Но на двух гигах он будет медленным и печальным, а на древнем HDD - чудовищно лагающим.
Вы занимаетесь ерундой в квадрате.
И пытаясь насобачить одни технологии поверх других, склеивая их соплями, и оптимизируя рабство на галерах.
Ни то, ни другое работать не будет.
Надо искать возможность оценить результаты работы, а не мерить ее усталостью.
И никаких костылей для этого, внезапно, не понадобится.
Вам не кажется, что вы решаете проблему XY?
Вместо автоматической очистки очереди и перезапуска CUPS в такой ситуации - маетесь каким-то шаманством с ТГ.
Например, можно покурить мануалы: https://wiki.archlinux.org/title/CUPS_(%D0%A0%D1%8...
Михаил, когда все правильно, но что-то идет не так - стоит убедиться, что возвращается именно то, что ожидается. И если forCount нигде не используется - под нее тоже не нужен массив.
Михаил, в коде, кстати, не нужны два массива, достаточно одного (который сейчас oldWb).
Другой можно заменить локальной переменной внутри цикла.
Или совершенно отдельным буфером - я что-то не вижу, чтобы вы проверяли, что именно возвращается в forCount...
Михаил, в функцию передаются аргументы по ссылке. Возможно, она ожидает long вместо short и опять-таки пишет мимо. Сделайте вывод всего состояния, оно небольшое - увидите, что куда записалось.
Не факт, что это будет более эффективно, чем BFS. Зато не требует вообще никакой теории графов ;)