Sarebbe disonesto farlo senza menzionare che l'algoritmo è stato regolato in modo diverso. Dovresti specificare cosa è cambiato il tuning e come questo influisce sui risultati dell'algoritmo.

Dovresti anche elencare i risultati di accuratezza per l'algoritmo veloce e i risultati di velocità per l'algoritmo accurato. (Probabilmente vuoi anche dei numeri per la messa a punto a metà strada). Non elencare i risultati "cattivi" non è disonesto, ma è una cattiva scienza. Se non includessi questi numeri, mi aspetto che i tuoi revisori ne parlino e li chiedano.

Parafrasando la tua domanda: "È onesto suggerire che il mio algoritmo è sia veloce che preciso quando, in realtà, può essere solo veloce e non così preciso o accurato e non così veloce?"

NO !!!

Ovviamente non lo è. Seriamente, perché hai anche bisogno di chiedere?

Sono solo uno studente Master, quindi non conosco molto le dinamiche del "gioco". Quindi posso solo dare qualche opinione da spettatore.

A uno dei miei supervisori piace avere trame brutalmente oneste nei suoi giornali. Il suo lavoro si concentra sul ridimensionamento di algoritmi paralleli. Per cominciare, sceglie una scala forte invece di una scala debole. Il primo prende una dimensione del problema fissa e utilizza più processori $ P $ per l'esecuzione. Idealmente, si otterrebbe un calo di $ 1 / P $ nel tempo. Prendendo un grafico a doppio registro del tempo rispetto al conteggio del processo e anche tracciando la curva $ 1 / P $ perfetta, puoi vedere rapidamente quando va a male.

Il ridimensionamento debole è il ridimensionamento della dimensione del problema con le risorse. Quindi il tempo necessario dovrebbe rimanere costante. Per i problemi che diventano difficili da parallelizzare a un livello preciso, non vedrai mai nulla di interessante in un ridimensionamento debole. Con un forte ridimensionamento puoi arrivare a estremi come "un pixel per core" o "un atomo per thread".

Ha detto che le parti interessanti (nella scienza) sono quelle che non funzionano ancora. Sicuramente può inventare una trama che renda l'algoritmo fantastico. Ma non è quello che gli interessa. Vuole sapere fino a che punto si può spingere.

Ammiro davvero questa brutale onestà. Se si ottengono risultati solo così così, questo metodo mostrerà chiaramente che non sono così eccezionali. D'altra parte, se rimuovi tu stesso tutta la superficie di attacco, nessuno può farti a pezzi in seguito per aver nascosto qualcosa.

Pertanto creerei grafici che mostrano quanto sia scarsa la precisione quando si ottimizza per la velocità. Includerei una trama onesta di accuratezza contro velocità (o viceversa). Quindi si può vedere se c'è un punto debole nel mezzo e quanto bene sia effettivamente.

Se il tuo algoritmo va agli estremi ma ha una bella via di mezzo, vale la pena menzionarlo, immagino . E se gli estremi sono solo di pochi punti percentuali più lenti o meno accurati, anche questo è un risultato.

Confronta le mele con le mele

Le prestazioni degli algoritmi vengono raramente valutate isolatamente: di solito, diversi algoritmi vengono confrontati tra loro o con qualche algoritmo di riferimento. Quando si esegue tale confronto, è necessario determinare le condizioni in cui sono stati valutati gli algoritmi di riferimento e valutare il proprio algoritmo nelle stesse condizioni:

• se gli algoritmi di riferimento hanno un'accuratezza comparabile, ottimizzare l'algoritmo per avere stessa precisione e confronta le prestazioni
• se gli algoritmi di riferimento hanno prestazioni simili, sintonizza il tuo sulla stessa prestazione e confronta la precisione

Al contrario, se hai un confronto dati in condizioni diverse, è possibile selezionare le condizioni più favorevoli al proprio algoritmo. Questo non è un inganno, ma un'analisi legittima delle condizioni in cui il tuo algoritmo è il più pratico.

Fino ad ora mi sono astenuto dall'unirmi a questo sito perché non mi sentivo qualificato per commentare. Ho lasciato il mondo accademico due giorni prima che avrei dovuto laurearmi con un BS. (Lascio la mia sordida storia come commento). Alla fine mi sono iscritto a questo sito proprio per questa domanda. La risposta è NO . Gli algoritmi "sintonizzati" dei ricercatori accademici tormentano i professionisti.

Un esempio specifico: ho trascorso due anni assolutamente meravigliosi per determinare come rilevare i guasti ai propulsori su un veicolo spaziale. Un algoritmo "messo a punto" sviluppato in precedenza suggeriva che si potesse fare a meno dei sensori molto costosi e soggetti a guasti tradizionalmente utilizzati per rilevare i guasti del propulsore utilizzando invece letture dell'accelerometro e del giroscopio. Quel lavoro "sintonizzato" presupponeva implicitamente propulsori perfettamente allineati e perfettamente posizionati con un sacco di grinta . Io, invece, ho dovuto fare i conti con l'equivalente di un camion Mack sul ghiaccio con motori VW disallineati e senza interruzioni. Non avevo un semplice problema di segnale-rumore con cui confrontarmi. Ho dovuto fare i conti con un problema di rumore per segnalare.

Ho utilizzato un approccio bayesiano. Quasi nessuno ha capito la mia matematica. Un altro gruppo (molto costoso) è stato consultato per assicurarsi che quello che ho fatto fosse corretto. Hanno riscontrato lo stesso problema dal rumore al segnale, ma hanno utilizzato un approccio frequentista per risolvere il problema. (Quasi nessuno capiva nemmeno la loro matematica.) Anche se loro erano frequentisti e io ero un bayesiano, concordarono che il mio approccio era valido. Alla fine, è costato due anni del mio tempo e un anno del tempo dell'altro gruppo. Confrontalo con $ 200K per i sensori più alcuni mesi del tempo necessario a un programmatore di basso livello, il cui codice potrebbe essere facilmente compreso da tutti. Anche se mi divertivo tantissimo, investire in me e in quell'altro gruppo è stato stupido sia dal punto di vista economico che da quello della manutenibilità.

L'ho visto più e più volte nel corso della mia carriera.

Nel contesto dello sviluppo di algoritmi per scopi accademici, il tempo di esecuzione "orologio da parete" reale del programma non è importante. Ciò che è importante è la complessità temporale (vedere la notazione Big-Oh). Di solito alcune modifiche alle prestazioni o ottimizzazioni di un algoritmo non cambiano la complessità temporale effettiva e sono quindi di scarso interesse.

Se un algoritmo cambia la complessità temporale, ma cambia anche l'accuratezza che l'algoritmo ha risolto a problema diverso e non confrontabile. Tuttavia, il confronto tra questi è almeno un caso di grave abbandono.

Sfortunatamente, nel mondo reale, solo i problemi "banali", come l'ordinamento di una lista, sono così ben definiti che tutti creano un algoritmo che ha esattamente le stesse condizioni pre e post. Un buon documento che confronta gli algoritmi dovrebbe riconoscere queste differenze e studiarne l'impatto.