Si può assumere la trasparenza referenziale quando si ha a che fare con l'aritmetica in virgola mobile?

Is there any practical relevance of such violations to functional programming?

Penso che tu abbia chiarito che la risposta è "sì".

If not, should we simply assume referential transparency?

L'unico modo in cui posso vedere questo essere OK è se l'unica cosa che ti interessa è se i risultati sono all'incirca uguali. Ma questo ha grosse insidie poiché piccole incoerenze possono diventare molto più grandi quando sono coinvolti la moltiplicazione e la divisione.

Or should we strive for maximal RT, eg, by choosing a language with better reproducibility of numerical results at the expense of their precision?

Non penso che sia necessario ridurre la precisione. Quello che eliminerebbe questi problemi è di usare un tipo che evita l'uso di frazioni binarie per tentare di fare matematica con numeri in un'altra base (e / o non ha tutte le stranezze storiche del punto mobile.) Un tipo con precisione decimale infinita sarebbe funziona come un tipo con precisione decimale fissa. Se vuoi che occupi lo stesso spazio dei tipi a virgola mobile, potresti dover sacrificare un po 'di precisione.

Tutto dipende dalla qualità della tua implementazione (ea volte l'implementazione dovrà rinunciare alla velocità per preservare le proprietà dell'implementazione che desideri).

In C, C ++ ecc. la stessa identica affermazione sulla stessa implementazione potrebbe dare risultati diversi. Ad esempio, in un ciclo tutte le iterazioni pari potrebbero calcolare un risultato in un modo e tutte le iterazioni dispari potrebbero calcolarlo in un altro modo. Questo è il caso più estremo. Meno estremo: lo stesso codice in luoghi diversi potrebbe dare risultati diversi. Lo stesso codice su due diverse esecuzioni del programma potrebbe dare risultati diversi. Lo stesso codice su due diverse implementazioni potrebbe dare risultati diversi. Assumerei che solo il caso più estremo - la stessa affermazione che dà risultati diversi - sarebbe un problema per quanto riguarda la tua domanda.

Se questo dovesse accadere dovrebbe essere sotto il controllo della tua implementazione. Ma l'esempio che hai dato (due implementazioni che danno risultati diversi) non è un problema (beh, è un problema, ma completamente estraneo alla trasparenza referenziale). L'implementazione deve solo garantire che sullo stesso programma venga eseguito, eseguire lo stesso codice con gli stessi dati una volta, più volte, ritardato, qualunque sia, darà sempre lo stesso risultato. Anche avere due funzioni diverse che dovrebbero dare gli stessi risultati ma non lo è non è un problema in questo senso.

Ovviamente il tuo linguaggio è libero di definire l'aritmetica in virgola mobile in un modo che dia meno libertà all'implementazione e il problema scompare.

La violazione della trasparenza referenziale è un problema se si costruisce su di esso. Si può costruire su di esso solo ragionando su una funzione, e in quel ragionamento si usa effettivamente la proprietà RT. Sentendoti dal tuo testo: immagino: nel luogo in cui la trasparenza referenziale è violata [dalla sotto-specificazione del calcolo in virgola mobile] [ad esempio la comunicazione tra computer]: non applichi nemmeno la programmazione funzionale. L'intero sistema software non ha bisogno di essere espresso completamente in modo funzionale per godere dei benefici della programmazione funzionale. Con altre parole: l'applicazione della programmazione funzionale può essere parziale e comunque enormemente vantaggiosa. La programmazione funzionale non è un paradigma (tutto o niente) ma (più è meglio è).

Ti preoccupi della violazione di alcune proprietà algebriche da operazioni in virgola mobile. Questo problema non è strettamente correlato alla programmazione funzionale, poiché il ragionamento algebrico e la programmazione funzionale possono entrambi essere praticati senza l'altro.

Ma la preoccupazione è ancora valida. Quelle proprietà algebriche si basano su una funzione di uguaglianza sul tipo di numero. Se quel test di uguaglianza è definito da IEEE [il valore predefinito nella maggior parte degli ambienti di programmazione], la somma dei numeri in virgola mobile non è associativa, quindi il tipo non può realmente implementare un'interfaccia Semigruppo. Ma si può avvolgere quel tipo di numero in un tipo di wrapper "Approssimato", sollevare la funzione di sommazione del tipo di numero grezzo al livello di Approssimato e fornire una funzione approssimativa di test di uguaglianza per Approssimato [restituirebbe true costantemente]. Quindi Approximate può implementare il Semigruppo in senso algebrico stretto. Questa sarebbe una pratica di codifica basata sul principio, ma alcuni ingegneri del software in alcune situazioni scelgono di non subire i problemi pratici, e piuttosto ricordano che l'implementazione Semigroup dei tipi di numeri in virgola mobile non elaborati dovrebbe essere interpretata in senso approssimativo.