Tali valori sono per i database. La maggior parte dei database molto tempo fa, e molti oggi, hanno assegnato un numero fisso di cifre per dati con valori interi. Un numero come -999 è il più piccolo che può essere memorizzato in quattro caratteri, -9999 in cinque caratteri e così via.
(Va da sé che - per definizione - un campo numerico non può memorizzare caratteri alfanumerici come "NA". È necessario utilizzare un codice numerico per rappresentare dati mancanti o non validi.)
Perché usare il numero più negativo che può essere memorizzato per indicare un valore mancante? Perché se lo tratti erroneamente come un numero valido, vuoi che i risultati siano drammaticamente errati. Quanto più i tuoi codici per i valori mancanti diventano realistici, tanto più sicuro sei, perché un input enormemente errato di solito rovina l'output. (I solidi metodi statistici sono notevoli eccezioni!)
Come può accadere un simile errore? Ciò si verifica continuamente quando si scambiano dati tra sistemi. Un sistema che presuppone che -9999 rappresenti un valore mancante produrrà beato quel valore quando si scrivono i dati nella maggior parte dei formati, come CSV. Il sistema che legge quel file CSV potrebbe non "conoscere" (o non essere "detto") per considerare tali valori come mancanti.
Un'altra ragione è che i buoni dati statistici e le piattaforme informatiche riconoscono molti diversi tipi di valori mancanti: NaN, valori veramente mancanti, overflow, underflow, mancate risposte, ecc. Ecc. Dedicando i valori più negativi possibili (come -9999, - 9998, -9997, ecc.), È facile interrogare tutti i valori mancanti da qualsiasi tabella o matrice.
Ancora un altro è che tali valori di solito vengono visualizzati nei display grafici come valori anomali estremi. Di tutti i valori che potresti scegliere di distinguere in un grafico, il più negativo possibile ha le maggiori possibilità di essere lontano dai tuoi dati.
Ci sono implicazioni e generalizzazioni utili:
−10303
Adottare una regola standard di questo tipo per semplificare l'invenzione dei codici NoData in nuove circostanze (durante la progettazione del proprio software di database).
Progetta il tuo software e i tuoi sistemi in modo che falliscano drammaticamente se falliscono. I peggiori bug sono quelli intermittenti, casuali o minuscoli, perché possono non essere rilevati ed essere difficili da scovare.