È comune non usare le librerie per algoritmi numerici standard e perché?

Molti algoritmi numerici (integrazione, differenziazione, interpolazione, funzioni speciali, ecc.) Sono disponibili in librerie di calcolo scientifico come GSL . Ma vedo spesso il codice con implementazioni "manuali" di queste funzioni. Per i piccoli programmi che non sono necessariamente destinati alla distribuzione pubblica, è pratica comune tra gli scienziati computazionali implementare da soli algoritmi numerici (con cui intendo copiare o trascrivere da un sito Web, Ricette numeriche o simili) quando ne hai bisogno? Se è così, c'è un motivo particolare per evitare di collegarsi a qualcosa come GSL, o è solo più "tradizione" di qualsiasi altra cosa?

Lo chiedo perché sono un grande fan del riutilizzo del codice , il che suggerisce che dovrei provare a utilizzare le implementazioni esistenti quando possibile. Ma sono curioso di sapere se ci sono ragioni per cui il principio ha meno valore nel calcolo scientifico che nella programmazione generale.

Ho dimenticato di menzionare: sto chiedendo in particolare di C e C ++, al contrario di linguaggi come Python dove c'è un chiaro vantaggio (velocità di esecuzione) nell'uso di una libreria.

Prima implementavo tutto da solo, ma ultimamente ho iniziato a usare molto di più le librerie. Penso che ci siano molti vantaggi molto importanti nell'uso di una libreria, oltre al solo problema di scrivere o meno una routine da soli. Se usi una libreria, ottieni

• Codice che è stato testato da centinaia / migliaia / più utenti
• Codice che continuerà ad essere aggiornato e migliorato in futuro, senza alcun lavoro da parte tua
• Codice ottimizzato che è più efficiente e forse più scalabile di quello che scriveresti al primo tentativo
• A seconda della libreria, stabilendo un'interfaccia con essa nel tuo codice potresti avere accesso a molti algoritmi che attualmente non usi ma che potresti voler in futuro

Nell'ultimo punto sopra, sto pensando a grandi biblioteche come Trilinos o PETSc . Posso rafforzarlo con un paio di esempi personali concreti nello sviluppo di PyClaw . Sebbene sarebbe stato semplice parallelizzare Clawpack con le chiamate MPI, abbiamo scelto di utilizzare PETSc. Questo ci ha permesso di limitare il codice paralle nel pacchetto a meno di 300 righe di Python, ma ancora meglio, mettendo i nostri dati nel formato PETSc abbiamo ottenuto l'accesso immediato ai solutori impliciti di PETSc, consentendo il lavoro corrente su un solutore implicito in PyClaw. Come secondo esempio, PyClaw inizialmente includeva la ricostruzione WENO del quinto ordine con codice manuale, ma alla fine abbiamo deciso di fare affidamento sul PyWENOpacchetto per questo. Questo è stato un enorme vantaggio, dal momento che PyWENO può generare automaticamente routine WENO di qualsiasi ordine in diverse lingue.

Infine, se usi le librerie, puoi contribuire sviluppando miglioramenti o trovando bug, che andranno a beneficio di molte altre persone, mentre il debug o il miglioramento del tuo codice ti avvantaggiano.

Vi è un notevole sovraccarico del programmatore nel collegamento a una funzione di libreria, specialmente se quella libreria è nuova per il programmatore. Spesso è più semplice riscrivere semplici algoritmi piuttosto che capire i dettagli di una particolare libreria. Man mano che gli algoritmi diventano più complessi, questo comportamento cambia.

Python si è distinto nel ridurre questo sovraccarico con strumenti come pip / easy_install e un'interfaccia uniforme per la struttura dei dati (ovvero ogni libreria sembra prendere e produrre un array intorpidito).

Uno dei progetti in cui sono coinvolto in questo momento è la stesura di un pacchetto di simulazione e analisi flessibile per una classe di rilevatori di fisica delle particelle. Uno degli obiettivi di questo progetto è fornire la base di codice da utilizzare in queste cose per i decenni a venire.

A questo punto abbiamo già due dozzine di dipendenze, il che rende il processo di creazione un incubo tale che è partito da un progetto separato gestito dal centro di calcolo Fermilab solo per fornire una catena di strumenti affidabile.

Ora immagina di incontrare la necessità di alcuni strumenti che non fanno parte di quella catena di strumenti (mi è successo proprio il mese scorso). Hai tre scelte

1. Rotoli tu stesso. Con tutti i rischi e le seccature che comporta.
2. Raschia un po 'di codice da una libreria da qualche parte e includilo nella direzione di The Project. Ciò significa che dovrai occuparti della manutenzione in futuro e che dovrai capire il codice di qualcun altro quando ciò accade.
3. Vai alle persone che mantengono la catena degli strumenti, chiedili ciò di cui hai bisogno e quindi attendi un ciclo di rilascio per ottenerlo. Questi ragazzi sono piuttosto reattivi, ma devi farlo per caso senza un codice funzionante o dopo aver fatto (1) o (2).

È molto facile scegliere (1). Forse troppo facile.

Penso che sia abbastanza comune, con alcuni algoritmi che hanno maggiori probabilità di essere implementati rispetto ad altri.

C'è un delicato compromesso tra quanto sia fastidiosa l'installazione di una libreria, quanto sia difficile implementare l'algoritmo da soli, quanto sia difficile ottimizzarla e quanto la libreria si adatti alle tue esigenze. Inoltre, a volte usare una libreria è semplicemente eccessivo: ho usato l'algoritmo di bisection lento in uno dei miei programmi perché l'ho chiamato solo poche volte e non volevo aggiungere una libreria solo per quello.

Scrivere una versione ottimizzata per te è facile? Se lo è, potresti fare meglio a farlo. Otterrai esattamente ciò di cui hai bisogno e non dipenderai dal lavoro di nessuno. Ma ovviamente devi davvero sapere cosa stai facendo: anche semplici algoritmi possono essere difficili da implementare.

Sarei curioso di vedere uno studio su questo, ma dalla mia prospettiva distorta, gli scienziati spesso usano le librerie per l'algebra lineare e generatori di numeri casuali, con la maggior parte del codice rimanente fatto in casa.

Penso che l'implementazione di un algoritmo anziché l'utilizzo di una libreria possa talvolta fornire una migliore comprensione e controllo del modello. Quando sto programmando un programma per calcoli scientifici, è importante per me capire cosa sto facendo. L'implementazione di importanti algoritmi mi aiuta a conoscere meglio il problema e a controllarlo meglio.

D'altra parte, a volte non è un compito banale selezionare una libreria che è necessaria per ottenere una soluzione, quindi è meglio cercare algoritmi già implementati quando sei sicuro di cosa stai cercando di ottenere e perché lo desideri.

Se gli algoritmi sono complessi, la loro codifica manuale offre l'opportunità di migliorare le prestazioni / la qualità della soluzione utilizzando funzionalità specifiche dell'attività. E a volte è necessario modificare un po 'l'algoritmo, il che è più semplice se conosci il codice che hai scritto e puoi modificarlo nel modo desiderato.

Una risposta è che ci sono così tante leggere variazioni al codice numerico che è davvero difficile incapsularlo in una libreria. Prendi questo in confronto al software web, che è spesso facile da installare e ha un chiaro set di input e output. Penso che più comuni siano le persone che afferrano un framework o una grande libreria che si comporta come un framework (Trilinos / PETSc) e che utilizza tale ecosistema per ottenere i vantaggi dell'utilizzo dei codici di community.

Prima di decidere se utilizzare o meno le librerie, penso che vorrai anche capire quanto l'uso di una libreria aiuterà il tuo codice. Se stai per utilizzare una libreria ben ottimizzata per un kernel computazionale chiave, allora è probabilmente molto più efficiente di provare a scrivere il tuo.

Tuttavia, se stai scrivendo una routine specializzata che verrà chiamata una sola volta durante l'esecuzione di un programma, potrebbe non valerne la pena adattare il tuo codice per adattarlo al framework richiesto da una libreria.

(Un'altra cosa a cui pensare: quanta riprogettazione dovrai fare per sfruttare la biblioteca? A meno che le ore di lavoro che spendi per correggere il codice non siano compensate dai corrispondenti guadagni in termini di efficienza o accuratezza numerica, potrebbe non ne varrà la pena nel lungo periodo. Idealmente, tuttavia, questo è qualcosa che si prevede quando si progettano inizialmente strutture di dati e algoritmi, in modo che il "flusso" della libreria venga preso in considerazione da zero.)

I miei 2 centesimi.

Penso che sia più facile scrivere in generale su questo, piuttosto che solo su C / C ++. Innanzitutto, le librerie in linguaggi come Python non sono necessariamente utilizzate per ottenere un vantaggio in termini di velocità, anche se ciò è una conseguenza. Penso che @ David abbia trattato abbastanza bene i motivi.

Prendendolo dall'alto, l'implementazione del linguaggio determina in una certa misura a quali librerie hai accesso. I linguaggi comunemente usati nella scienza computazionale includono C, C ++, Python, Perl, Java, Fortran e R. Esempi meno comuni potrebbero essere Ocaml e Common Lisp. Ora, poiché la maggior parte di questi linguaggi sono scritti in C, hanno un'interfaccia di funzione esterna naturale con C. Tuttavia, non è così facile chiamare, per esempio, una libreria Perl da Python o viceversa. Quindi in pratica le persone tendono a farlo

1. Utilizzare una libreria scritta nel loro linguaggio di implementazione, di solito qualcosa che fa parte delle librerie standard, o altrimenti ampiamente disponibile, o

2. Chiamare una libreria C / C ++ attraverso le lingue FFI. Ciò presuppone che un wrapper non esista già, poiché in tal caso non è facilmente distinguibile da (1).

(2) di solito è più difficile, perché devi avvolgere tu stesso la funzione C / C ++. Inoltre, è necessario raggruppare la libreria o aggiungere una dipendenza aggiuntiva. Per tale motivo, è più probabile che le persone utilizzino le librerie di lingue integrate anziché utilizzare GSL, ad esempio, che si trova in C.

Per routine molto generiche, ad esempio generare campioni casuali da distribuzioni o routine numeriche di base come la quadratura di integrali, è facile e comune riutilizzare alcune librerie. Man mano che la funzionalità che si sta tentando di implementare diventa più complessa, diventa esponenzialmente più improbabile che si trovi la funzione esatta che si desidera in un'altra libreria e, anche se lo si fa, si può dedicare molto tempo alla ricerca e infine adattare la funzione come necessario (lo stile / il design del codice potrebbe essere un problema ad esempio). E come discusso sopra, si ha accesso solo a un sottoinsieme delle librerie là fuori. D'altra parte, implementare un algoritmo se è complesso e non il focus principale può essere scoraggiante, e ovviamente uno deve affrontare quei fastidiosi problemi di velocità.

Quindi, questo diventa un problema di ottimizzazione nell'analisi costi / benefici. La mia esperienza è che anche per tecniche relativamente standard come MCMC, di solito finisco per scrivere il mio codice, perché si adatta meglio a come sto progettando il software generale.

Certo, anche se finisci per non usare il codice, è possibile imparare dal codice di altre persone. Tuttavia, non so quanto spesso gli scienziati si preoccupino di farlo. La mia impressione è che leggere il codice di altre persone per imparare sia più una cosa da ingegnere del software.

Ripensando al mio corso di meccanica del secondo anno, mi viene in mente che una parte della ragione per cui ho implementato le mie versioni di algoritmi ben noti è che mi è stato insegnato a farlo in quel modo. Non riesco a pensare a un singolo esempio in cui mi è stato insegnato come interfacciarmi e collegarmi in una biblioteca nella mia formazione universitaria in fisica. Ho un affettuoso ricordo di aver visto per la prima volta un elenco di coordinate di una pallina da golf rotante, dopo aver calcolato la soluzione delle equazioni di Newton accoppiate in FORTRAN. C'è un certo brivido e soddisfazione (persino orgoglio) che deriva dal calcolo delle cose da zero.

Penso che uno dovrebbe usare il più possibile le librerie testate. La maggior parte delle persone non è esperta di calcolo numerico e probabilmente non sarà in grado di implementare una soluzione in modo corretto e accurato quanto disponibile in librerie ben collaudate. Detto questo, tuttavia, a volte capita che non ci siano librerie disponibili che implementano la combinazione di funzionalità necessarie in una determinata applicazione. L'ho visto accadere nell'area tecnica in cui lavoro; i codici esistenti non hanno risolto tutti i casi e qualcuno ha finito per implementare un risolutore da zero.

Il problema fondamentale è spesso con l'interfaccia tra l'applicazione e la libreria. Un programmatore dell'applicazione è a conoscenza del problema che spesso viene perso quando si passa il problema (ad esempio come matrice) a una libreria. Questa conoscenza è tale che lo sfruttamento più che compensa i vantaggi dell'utilizzo della libreria altamente ottimizzata. Di conseguenza, il programmatore dell'applicazione "lancia" la propria implementazione che sfrutta la conoscenza.

Pertanto, una libreria davvero buona deve trasmettere tali conoscenze dall'applicazione alla libreria, in modo che anche la libreria possa trarne vantaggio.

Oltre a tutte le cose già dette sopra, ripeterò la mia risposta dalla domanda "Fortran vs C ++": la risorsa più preziosa che un programmatore ha è il suo tempo. Sì, le dipendenze esterne sono spesso imbarazzanti. Ma passare il tempo a reimplementare, eseguire il debug e testare algoritmi che altri hanno già implementato è quasi sempre stupido, e il risultato sarà raramente altrettanto buono del codice che è stato scritto da esperti su un particolare argomento. Riutilizzare ciò che altri hanno fatto!

Il gruppo con cui lavoro utilizza le librerie il più possibile. Sono uno dei pochi programmatori e il resto della gente ha iniziato a programmare sul posto di lavoro. Conoscono abbastanza dei propri limiti per sapere dove non dovrebbero dilettarsi. IMSL è la libreria preferita. Roba come GSL sarebbe vietata a causa delle restrizioni di licenza, anche se si tratta di un'agenzia federale e distribuiamo comunque il nostro software.

"Il riutilizzo è principalmente un fenomeno sociale. Posso utilizzare il software di qualcun altro a condizione che

1. Funziona
2. è comprensibile
3. può coesistere
4. è supportato (o sono disposto a supportarlo da solo, per lo più non lo sono)
5. è economico
6. Posso trovarlo

"- B. Stroustrup, The C ++ Programming Language 2 ed. (1991) p. 383.

Diverse buone ragioni sono state fornite da altri per l'utilizzo delle librerie e anche per il roll-out delle proprie routine.

A volte è possibile velocizzare i calcoli per un'applicazione specifica perché si sa in anticipo che non sarà mai necessario l'ampia gamma di valori coperti dalla routine della libreria o l'accuratezza fornita da tali routine.

Naturalmente, molto dipende dalla particolare applicazione e da quante volte verrà chiamata la routine della libreria. Perché dovresti chiamare una libreria di routine per le funzioni di Bessel miliardi di volte se hai solo bisogno di alcune cifre significative per un piccolo intervallo di x e una tecnica più semplice sarà sufficiente per le tue esigenze?

È poco da aggiungere, dobbiamo riutilizzare il codice, riguarda la sostenibilità del codice e il contributo alla società, ma questo è tutto sopra.

Il motivo per cui non riutilizziamo il codice è che se stai iniziando il programmatore è difficile capire il codice degli altri. È particolarmente difficile con C ++ avanzato e puoi fare anche qualche trucco in C puro.

Molto spesso all'inizio, si capisce il metodo, ma non come è implementato nella libreria, o semplicemente come usare la libreria con la sua interfaccia generica, controllo degli errori e convenzioni, molto spesso documentata per programmatori esperti, se non del tutto. Questo dà l'illusione che è meglio implementare un metodo standard, come la fattorizzazione LU da soli. Inoltre, i nuovi programmatori sottovalutano il valore del test del codice, della convalida e della portabilità per diversi sistemi operativi. Quindi alla fine il motivo è la pigrizia, scrivere il proprio codice sembra una soluzione più semplice e veloce.

La realtà è che possiamo imparare di più usando e leggendo il codice piuttosto che programmare da soli da zero.

La pigrizia mi guida per la maggior parte del tempo, penso anche la maggior parte delle persone. Per lo stesso motivo, alcuni scrivono codice da zero e altri usano librerie esistenti.

Gli algoritmi delle biblioteche forniscono in contrasto con le proprie implementazioni:

• Sono generici e modellati. In seguito è possibile modificare la parametrizzazione dell'implementazione senza preoccuparsi di modificare il proprio codice che dovrebbe avere molti vincoli.
• Esistono casi di dati di input versati rispetto a quelli degenerati. Molti algoritmi di geometria computazionale, ad esempio quelli con scafo convesso, devono gestire ad esempio la colinearità di tre punti. Potresti essere in grado di ignorare quei casi se non prevedi mai di distribuire il tuo codice e inoltre non vuoi riutilizzarlo spesso in futuro.
• Forniscono la minima complessità di runtime per configurazioni di input previste o peggiori. Gli algoritmi di livello superiore hanno come mattoncini di costruzione algoritmi di livello inferiore, ad esempio algoritmi di ordinamento o tipi di dati speciali. L'ordinamento rapido potrebbe essere la scelta più comune per l'ordinamento dei dati, ma se l'implementazione dell'algoritmo deve garantire n (log (n)) non è possibile utilizzarlo.
• Sono efficienti nell'uso della memoria
• Sono ulteriormente ottimizzati per il runtime
• Se supportato, molto più chiuso per essere "privo di bug" in generale, specialmente se lavori con il ramo principale. Niente è più testato di una libreria ben distribuita. Non tutti i bug si bloccano, non tutti i bug producono risultati irragionevoli. L'implementazione del tuo algoritmo potrebbe comunque produrre risultati accettabili, ma non altrettanto buoni per i quali è stata progettata. Meno è visibile un bug, meno è probabile che tu possa rilevarlo come persona singola.

Lo considero ancora buono quando entro in un nuovo campo per implementare una versione di un algoritmo ben comprensibile da solo. Mi ci vuole molto tempo in totale. Ho comprato e letto libri, il nome Press et al. Ho sempre letto molta teoria prima e durante quelle implementazioni. E dopo aver compreso i concetti generali di un campo e aver sperimentato le trappole in pratica per me, è tempo di saltare alle migliori implementazioni della biblioteca in tutti gli aspetti. Penso che diventerai un utente migliore della biblioteca se hai scritto un algoritmo "ciao mondo" nel campo delle biblioteche da solo.

Se lavori in una squadra più grande, potrebbe non essere la tua scelta se la tua squadra utilizza o meno una libreria specifica. Il team principale potrebbe prendere la decisione. E potrebbe esserci una persona responsabile della rilegatura della biblioteca nel tuo progetto con i suoi piani temporali. Riscrivere un algoritmo che puoi fare con la tua pianificazione del tempo, senza fare affidamento sulla decisione di altre persone.

Se sei da solo e ti piace distribuire, c'è un altro problema. Considero, oltre a molti altri codici sorgente, la risorsa più utile. Molti a tutti gli informatici potrebbero essere d'accordo qui. In un campo applicato al di fuori dell'informatica potrebbe essere necessario fornire un eseguibile precompilato su Windows. Sotto Linux puoi configurare le cose relativamente da solo in caso di librerie di utilizzo open source.

Riscrivere un algoritmo da solo dà libertà di svago. Il tuo progetto potrebbe non supportare ad esempio la licenza GPL di GSL .

La libertà potrebbe essere l'unico vincolo che è indipendente dal punto di vista dei rivenditori.