Modello per algoritmo che fornisce una spiegazione di come si arriva a una soluzione quando necessario

Lo scenario seguente mi è successo più volte.

Ho programmato un algoritmo che risolve un certo problema. Funziona bene e trova le soluzioni giuste. Ora, voglio avere un'opzione per dire all'algoritmo "scrivi una spiegazione completa di come sei arrivato alla soluzione". Il mio obiettivo è essere in grado di utilizzare l'algoritmo in dimostrazioni online, lezioni di esercitazione, ecc. Voglio ancora avere un'opzione per eseguire l'algoritmo in tempo reale, senza le spiegazioni. Qual è un buon modello di design da usare?

ESEMPIO: Supponiamo che io attui questo metodo per trovare il massimo comun divisore . L'attuale metodo implementato restituisce la risposta corretta, ma senza spiegazioni. Voglio avere un'opzione per il metodo per spiegare le sue azioni, come:

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.

L'output deve essere restituito in modo tale da poter essere facilmente visualizzato sia in console che in applicazioni basate sul Web.

Qual è un buon modello per fornire spiegazioni quando necessario, senza danneggiare le prestazioni in tempo reale dell'algoritmo quando non sono necessarie spiegazioni?

Lo "schema" che stai cercando si chiama "logging", rendi le dichiarazioni di logging così dettagliate come ti servono. Utilizzando un framework di registrazione decente dovresti essere in grado di accenderlo e spegnerlo in fase di esecuzione, fornire livelli di verbosità diversi o personalizzare l'output per scopi diversi (come web vs. console).

Se ciò ha un notevole impatto sulle prestazioni (anche se la registrazione è disattivata) probabilmente dipenderà dalla lingua, dal framework e dal numero di istruzioni di registrazione necessarie nel caso specifico. Nei linguaggi compilati, se questo diventa davvero un problema, è possibile fornire uno switch del compilatore per creare una "variante di registrazione" e una "variante non di registrazione" del codice. Tuttavia, consiglio vivamente di non ottimizzare "per ogni evenienza", senza prima misurare.

Un buon modello è Observer. https://en.wikipedia.org/wiki/Observer_pattern

Nel tuo algoritmo, in ogni punto in cui desideri produrre qualcosa, avvisi alcuni osservatori. Decidono quindi cosa fare, sia per l'output del testo sulla console, sia per inviarlo al motore HTML / Apache ecc.

A seconda del linguaggio di programmazione, potrebbero esserci diversi modi per renderlo veloce. Ad esempio, in Java (trattalo come pseudocodice, per brevità; rendendolo "corretto", con getter, setter, è lasciato al lettore):

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();

Questo è leggermente dettagliato, ma il controllo ==nulldovrebbe essere il più veloce possibile.

(Si noti che nel caso generale, observersarebbe probabilmente un Vector observersinvece consentire più di un osservatore; anche questo è ovviamente possibile e non porterà a maggiori costi generali; è comunque possibile inserire l'ottimizzazione impostata observers=nullinvece di avere un vuoto Vector.)

Ovviamente, implementeresti diversi tipi di osservatori a seconda di ciò che vuoi ottenere. Puoi anche inserire statistiche sui tempi ecc. Lì, o fare altre cose fantasiose.

Come un leggero miglioramento della registrazione diretta, creare una sorta di oggetto che modella un'esecuzione dell'algoritmo. Aggiungi un "passaggio" a questo oggetto contenitore ogni volta che il tuo codice fa qualcosa di interessante. Alla fine dell'algoritmo, registra i passaggi accumulati dal contenitore.

Questo ha alcuni vantaggi:

1. È possibile registrare l'intera esecuzione come una sola voce di registro, spesso utile quando c'è la possibilità che altri thread registrino cose tra i tuoi passi algo
2. Nella mia versione Java di questa classe (chiamata semplicemente "Debug"), non aggiungo stringhe come voci di registro, ma lambdas che producono stringhe. Questi lambda vengono valutati solo se avrà luogo la registrazione effettiva, ovvero se l'oggetto Debug rileva che il suo livello di registro è attualmente attivato. In questo modo, non vi è alcun sovraccarico prestazionale nel costruire inutilmente stringhe di registro.

EDIT: come commentato da altri, i lambda hanno un overhead, quindi dovresti fare un benchmark per assicurarti che questo overhead sia inferiore alla valutazione non necessaria del codice richiesta per costruire la stringa di registro (le voci di registro spesso non sono semplici letterali, ma implicano ottenere informazioni contestuali da oggetti partecipanti).

Di solito cerco la ramificazione, nel senso che cerco dichiarazioni if. Perché questi indicano che valuto un valore, che controllerà il flusso dell'algoritmo. In ciascuna di tali occasioni (ogni condizione) posso quindi registrare il percorso scelto e perché è stato scelto.

Quindi fondamentalmente registrerei i valori di entrata (stato iniziale), ogni ramo scelto (condizionali) e i valori quando inserisco il ramo scelto (stato temporaneo).