Шаблон алгоритму, який видає пояснення того, як він потрапляє до рішення, коли це необхідно

Такий сценарій траплявся зі мною кілька разів.

Я запрограмував алгоритм, який вирішує певну проблему. Це прекрасно працює і знаходить правильні рішення. Тепер я хочу мати можливість сказати алгоритму "написати повне пояснення того, як ти потрапив до рішення". Моя мета - мати можливість використовувати алгоритм в онлайн-демонстраціях, підручниках тощо. Я все ще хочу мати можливість запускати алгоритм в режимі реального часу, без пояснень. Яку хорошу модель дизайну використовувати?

ПРИКЛАД: Припустимо, я реалізую цей метод для пошуку найбільшого спільного дільника . Поточний реалізований метод повертає правильну відповідь, але без пояснень. Я хочу мати метод для пояснення своїх дій, наприклад:

Initially, a=6 and b=4. The number of 2-factors, d, is initialized to 0.
a and b are both even, so we divide them by 2 and increment d by 1.
Now, a=3 and b=2.
a is odd but b is even, so we divide b by 2.
Now, a=3 and b=1.
a and b are both odd, so we replace a by (a-b)/2 = 1.
Now, a=1 and b=1.
a=b, so the GCD is a*2^d = 2.

Вихід повинен бути повернутий таким чином, щоб його можна було легко відображати як в консолі, так і в веб-додатках.

Яка хороша схема надання пояснень при необхідності, не заважаючи виконувати алгоритм в реальному часі, коли пояснення не потрібні?

"Шаблон", який ви шукаєте, називається "ведення журналів", просто зробіть заяви журналу настільки багатослівними, як вам потрібно. Використовуючи гідну рамку ведення журналу, ви повинні мати можливість увімкнути та вимкнути її під час виконання, забезпечити різні рівні багатослів’я або налаштувати вихід для різних цілей (наприклад, веб-консоль).

Якщо це має помітний вплив на продуктивність (навіть якщо журнал вимкнено), ймовірно, буде залежати від мови, рамки та кількості заяв журналу, які вам потрібні в конкретному випадку. Якщо в компільованих мовах, якщо це справді стає проблемою, ви можете надати компілятор для перетворення "варіанту журналу" та "варіанту без реєстрації" вашого коду. Однак я настійно рекомендую не оптимізувати "про всяк випадок", не вимірюючи спочатку.

Хороший зразок - спостерігач. https://en.wikipedia.org/wiki/Observer_pattern

У вашому алгоритмі в кожній точці, де ви хочете щось вивести, ви повідомляєте деяких спостерігачів. Потім вони вирішують, що робити, чи виводити ваш текст на консоль, або надсилати його до двигуна HTML / Apache тощо.

Залежно від вашої мови програмування можуть бути різні способи зробити це швидко. Наприклад, у Java (трактуйте це як псевдокод, для стислості; зробивши його "правильним", за допомогою геттерів, сеттерів, залишається читачеві):

interface AlgoLogObserver {
   public void observe(String message);
}

class AlgorithmXyz {   
   AlgoLogObserver observer = null;
   void runCalculation() {   
       if (observer!=null) { oberserver.observe("Hello"); }
       ...
   }   
}

...
algo = new AlgorithmXyz();
algo.observer = new ConsoleLoggingObserver();  // yes, yes make a 
                                               // setter instead, or use Ruby :-)
algo.runCalculation();

Це злегка багатослівно, але перевірка на це ==nullповинна бути якомога швидшою.

(Зверніть увагу, що в загальному випадку, observerмабуть, Vector observersзамість цього може бути призначено більше одного спостерігача; це, звичайно, також можливо і не призведе до більше накладних витрат; ви все одно можете вкласти оптимізацію, яку ви встановили, observers=nullзамість того, щоб мати порожній Vector.)

Звичайно, ви б реалізували різні види спостерігачів залежно від того, чого ви хочете досягти. Ви також можете вводити там статистику часу та ін., Або робити інші химерні речі.

Як невелике вдосконалення прямого ведення журналу, створіть якийсь об'єкт, який моделює одне виконання алгоритму. Додайте "крок" до цього об'єкта контейнера щоразу, коли ваш код робить щось цікаве. В кінці алгоритму записуйте накопичені кроки з контейнера.

У цього є кілька переваг:

1. Ви можете зафіксувати повне виконання як один запис журналу, що часто корисно, коли є можливість реєструвати інші теми між вашими кроками algo.
2. У моїй версії Java цього класу (називається просто "Налагодження") я не додаю рядки як записи журналу, а лямбда, що створюють рядки. Ці лямбдахи оцінюються лише в тому випадку, якщо відбудеться фактична реєстрація, тобто якщо об'єкт налагодження виявить, що його рівень журналу в даний час активований. Таким чином, немає необхідності накладних витрат на побудову рядків журналів без необхідності.

EDIT: Як зауважують інші, лямбдахи мають накладні витрати, тому вам доведеться орієнтуватися, щоб переконатися, що ця накладка менше, ніж зайва оцінка коду, необхідного для побудови рядка журналу (записи журналу часто не є простими літералами, але передбачають отримання контекстної інформації з об’єкти, що беруть участь).

Я зазвичай шукаю розгалуження, тобто я шукаю if-заяви. Оскільки вони вказують на те, що я оцінюю значення, це контролюватиме потік алгоритму. У кожному такому випадку (у кожній умові) я можу записати вибраний шлях і чому він був обраний.

Отже, я б записував вхідні значення (початковий стан), кожну обрану гілку (умовні умови) та значення при введенні обраної гілки (темп-стан).