La matematica in virgola mobile è coerente in C #? Può essere?

No, questa non è un'altra domanda "Why is (1 / 3.0) * 3! = 1" .

Ultimamente ho letto parecchi punti in virgola mobile; in particolare, come lo stesso calcolo potrebbe dare risultati diversi su architetture o impostazioni di ottimizzazione diverse.

Questo è un problema per i videogiochi che memorizzano replay o sono collegati in rete peer-to-peer (al contrario del server-client), che si affidano a tutti i client che generano esattamente gli stessi risultati ogni volta che eseguono il programma - una piccola discrepanza in uno il calcolo in virgola mobile può portare a uno stato di gioco drasticamente diverso su macchine diverse (o persino sulla stessa macchina! )

Ciò accade anche tra i processori che "seguono" IEEE-754 , principalmente perché alcuni processori (vale a dire x86) usano una doppia precisione estesa . Cioè, usano i registri a 80 bit per eseguire tutti i calcoli, quindi si troncano a 64 o 32 bit, portando a risultati di arrotondamento diversi rispetto alle macchine che usano 64 o 32 bit per i calcoli.

Ho visto diverse soluzioni a questo problema online, ma tutte per C ++, non C #:

• Disabilitare la doppia modalità di precisione estesa (in modo che tutti i doublecalcoli utilizzino IEEE-754 a 64 bit) utilizzando _controlfp_s(Windows), _FPU_SETCW(Linux?) O fpsetprec(BSD).
• Esegui sempre lo stesso compilatore con le stesse impostazioni di ottimizzazione e richiedi a tutti gli utenti di avere la stessa architettura della CPU (nessuna riproduzione multipiattaforma). Poiché il mio "compilatore" è in realtà il JIT, che può ottimizzare in modo diverso ogni volta che il programma viene eseguito , non penso che sia possibile.
• Usa l'aritmetica in virgola fissa, ed evita floate del doubletutto. decimalfunzionerebbe a questo scopo, ma sarebbe molto più lento e nessuna delle System.Mathfunzioni di libreria lo supporta.

Quindi, questo è anche un problema in C #? Cosa succede se intendo supportare solo Windows (non Mono)?

In tal caso, esiste un modo per forzare l'esecuzione del mio programma alla normale doppia precisione?

In caso contrario, ci sono librerie che potrebbero aiutare a mantenere coerenti i calcoli in virgola mobile?

Non conosco alcun modo per rendere deterministici i normali punti fluttuanti in .net. A JITter è consentito creare codice che si comporta diversamente su piattaforme diverse (o tra versioni diverse di .net). Quindi floatnon è possibile usare normali s in codice .net deterministico.

Le soluzioni alternative che ho considerato:

1. Implementare FixedPoint32 in C #. Anche se questo non è troppo difficile (ho un'implementazione quasi finita), l'intervallo molto piccolo di valori lo rende fastidioso da usare. Devi stare attento in ogni momento in modo da non traboccare, né perdere troppa precisione. Alla fine l'ho trovato non più semplice dell'utilizzo diretto di numeri interi.
2. Implementare FixedPoint64 in C #. Ho trovato questo piuttosto difficile da fare. Per alcune operazioni sarebbero utili interi intermedi di 128 bit. Ma .net non offre questo tipo.
3. Implementare un punto mobile personalizzato a 32 bit. La mancanza di un intrinseco BitScanReverse provoca alcuni fastidi durante l'implementazione. Ma attualmente penso che questo sia il percorso più promettente.
4. Utilizzare il codice nativo per le operazioni matematiche. Supporta l'overhead di una chiamata delegata su ogni operazione matematica.

Ho appena iniziato un'implementazione software di matematica a virgola mobile a 32 bit. Può fare circa 70 milioni di aggiunte / moltiplicazioni al secondo sul mio i3 a 2,66 GHz. https://github.com/CodesInChaos/SoftFloat . Ovviamente è ancora molto incompleto e difettoso.

La specifica C # (§4.1.6 Tipi in virgola mobile) consente specificamente di eseguire calcoli in virgola mobile utilizzando una precisione superiore a quella del risultato. Quindi, no, non penso che tu possa rendere quei calcoli deterministici direttamente in .Net. Altri hanno suggerito varie soluzioni alternative, in modo da poterle provare.

La pagina seguente può essere utile nel caso in cui sia necessaria la portabilità assoluta di tali operazioni. Discute il software per testare le implementazioni dello standard IEEE 754, incluso il software per emulare operazioni in virgola mobile. La maggior parte delle informazioni è probabilmente specifica per C o C ++, tuttavia.

http://www.math.utah.edu/~beebe/software/ieee/

Una nota sul punto fisso

I numeri binari a virgola fissa possono anche funzionare bene come sostituto del virgola mobile, come risulta dalle quattro operazioni aritmetiche di base:

• Aggiunta e sottrazione sono banali. Funzionano allo stesso modo degli interi. Aggiungi o sottrai!
• Per moltiplicare due numeri a virgola fissa, moltiplicare i due numeri quindi spostare a destra il numero definito di bit frazionari.
• Per dividere due numeri in virgola fissa, spostare il dividendo a sinistra del numero definito di bit frazionari, quindi dividere per il divisore.
• Il capitolo quattro di questo documento contiene ulteriori indicazioni sull'implementazione di numeri binari a virgola fissa.

I numeri binari a virgola fissa possono essere implementati su qualsiasi tipo di dati intero come int, long e BigInteger e i tipi non conformi CLS uint e ulong.

Come suggerito in un'altra risposta, è possibile utilizzare le tabelle di ricerca, in cui ogni elemento nella tabella è un numero binario a punto fisso, per aiutare a implementare funzioni complesse come seno, coseno, radice quadrata e così via. Se la tabella di ricerca è meno granulare del numero in virgola fissa, si consiglia di arrotondare l'input aggiungendo una metà della granularità della tabella di ricerca all'input:

// Assume each number has a 12 bit fractional part. (1/4096)
// Each entry in the lookup table corresponds to a fixed point number
//  with an 8-bit fractional part (1/256)
input+=(1<<3); // Add 2^3 for rounding purposes
input>>=4; // Shift right by 4 (to get 8-bit fractional part)
// --- clamp or restrict input here --
// Look up value.
return lookupTable[input];

È un problema per C #?

Sì. Architetture diverse sono le ultime preoccupazioni, framerati diversi, ecc. Possono portare a deviazioni dovute a imprecisioni nelle rappresentazioni float - anche se hanno le stesse imprecisioni (ad esempio la stessa architettura, tranne una GPU più lenta su una macchina).

Posso usare System.Decimal?

Non c'è motivo per cui non puoi, tuttavia è un cane lento.

C'è un modo per forzare l'esecuzione del mio programma in doppia precisione?

Sì. Ospita tu stesso il runtime CLR ; e compilare tutte le chiamate / flag di nessecary (che modificano il comportamento dell'aritmetica in virgola mobile) nell'applicazione C ++ prima di chiamare CorBindToRuntimeEx.

Esistono librerie che potrebbero aiutare a mantenere coerenti i calcoli in virgola mobile?

Non che io sappia.

C'è un altro modo per risolvere questo?

Ho già affrontato questo problema in precedenza, l'idea è di utilizzare QNumbers . Sono una forma di reali a virgola fissa; ma non punto fisso in base-10 (decimale) - piuttosto base-2 (binario); per questo i primitivi matematici su di essi (add, sub, mul, div) sono molto più veloci dei punti fissi ingenui base-10; specialmente se nè lo stesso per entrambi i valori (che nel tuo caso sarebbe). Inoltre, poiché sono integrali, hanno risultati ben definiti su ogni piattaforma.

Tieni presente che il framerate può ancora influire su questi, ma non è così male e può essere facilmente corretto utilizzando i punti di sincronizzazione.

Posso usare più funzioni matematiche con QNumbers?

Sì, andata e ritorno di un decimale per farlo. Inoltre, dovresti davvero utilizzare le tabelle di ricerca per le funzioni trig (sin, cos); poiché possono davvero dare risultati diversi su piattaforme diverse e se li codifichi correttamente possono usare direttamente QNumbers.

Secondo questo post di blog MSDN leggermente vecchio, JIT non utilizzerà SSE / SSE2 per il virgola mobile, è tutto x87. Per questo motivo, come hai detto, devi preoccuparti di modalità e flag, e in C # questo non è possibile controllare. Pertanto, l'utilizzo delle normali operazioni in virgola mobile non garantirà lo stesso risultato esatto su ogni macchina per il proprio programma.

Per ottenere una riproducibilità precisa della doppia precisione, dovrai eseguire un'emulazione software a virgola mobile (o punto fisso). Non conosco le librerie C # per farlo.

A seconda delle operazioni necessarie, potresti riuscire a cavartela con una sola precisione. Ecco l'idea:

• archivia tutti i valori che ti interessano in un'unica precisione
• per eseguire un'operazione:
  • espandere gli input con doppia precisione
  • eseguire operazioni in doppia precisione
  • converti il ​​risultato in precisione singola

Il grosso problema con x87 è che i calcoli potrebbero essere eseguiti con precisione a 53 o 64 bit a seconda del flag di precisione e se il registro è stato versato in memoria. Ma per molte operazioni, l'esecuzione dell'operazione in alta precisione e l'arrotondamento alla precisione inferiore garantiranno la risposta corretta, il che implica che la risposta sarà garantita uguale su tutti i sistemi. Non importa se ottieni la precisione in più, dato che hai abbastanza precisione per garantire la risposta giusta in entrambi i casi.

Operazioni che dovrebbero funzionare in questo schema: addizione, sottrazione, moltiplicazione, divisione, sqrt. Cose come sin, exp, ecc. Non funzioneranno (i risultati di solito corrispondono ma non c'è garanzia). "Quando il doppio arrotondamento è innocuo?" Riferimenti ACM (req. Reg. Pagati)

Spero che questo ti aiuti!

Come già affermato da altre risposte: Sì, questo è un problema in C #, anche quando si utilizza Windows puro.

Per quanto riguarda una soluzione: è possibile ridurre (e con un certo sforzo / hit hit) evitare completamente il problema se si utilizza la BigIntegerclasse integrata e si ridimensionano tutti i calcoli con una precisione definita utilizzando un denominatore comune per qualsiasi calcolo / memorizzazione di tali numeri.

Come richiesto dall'OP - per quanto riguarda le prestazioni:

System.Decimalrappresenta il numero con 1 bit per un segno e Integer a 96 bit e una "scala" (che rappresenta il punto decimale). Per tutti i calcoli effettuati, deve operare su questa struttura di dati e non può utilizzare alcuna istruzione in virgola mobile integrata nella CPU.

La BigInteger"soluzione" fa qualcosa di simile - solo che puoi definire quante cifre hai bisogno / desideri ... forse vuoi solo 80 bit o 240 bit di precisione.

La lentezza deriva sempre dal dover simulare tutte le operazioni su questo numero tramite istruzioni di solo numero intero senza utilizzare le istruzioni integrate CPU / FPU che a loro volta portano a molte più istruzioni per operazione matematica.

Per ridurre il calo delle prestazioni ci sono diverse strategie - come QNumbers (vedi risposta di Jonathan Dickinson - La matematica in virgola mobile è coerente in C #? Può essere? ) E / o memorizzazione nella cache (ad esempio calcoli di trigmi ...) ecc.

Bene, ecco il mio primo tentativo su come fare questo :

1. Creare un progetto ATL.dll che contenga un oggetto semplice da utilizzare per le operazioni critiche in virgola mobile. assicurati di compilarlo con flag che disabilitano l'uso di qualsiasi hardware non xx87 per fare virgola mobile.
2. Creare funzioni che chiamano operazioni in virgola mobile e restituiscono i risultati; iniziare in modo semplice e, se funziona per te, puoi sempre aumentare la complessità per soddisfare le tue esigenze prestazionali in un secondo momento, se necessario.
3. Metti le chiamate control_fp intorno alla matematica attuale per assicurarti che sia fatto allo stesso modo su tutte le macchine.
4. Fai riferimento alla tua nuova libreria e verifica per assicurarti che funzioni come previsto.

(Credo che tu possa semplicemente compilare un .dll a 32 bit e poi usarlo con x86 o AnyCpu [o probabilmente indirizzare solo x86 su un sistema a 64 bit; vedi commento sotto].)

Quindi, supponendo che funzioni, dovresti usare Mono immagino che dovresti essere in grado di replicare la libreria su altre piattaforme x86 in un modo simile (non ovviamente COM; anche se, forse, con wine? Un po 'fuori dalla mia area una volta ci andiamo però ...).

Supponendo che tu possa farlo funzionare, dovresti essere in grado di impostare funzioni personalizzate che possono eseguire più operazioni contemporaneamente per risolvere eventuali problemi di prestazioni e avrai matematica a virgola mobile che ti consente di ottenere risultati coerenti su piattaforme con un importo minimo di codice scritto in C ++ e lasciando il resto del codice in C #.

Non sono uno sviluppatore di giochi, anche se ho molta esperienza con problemi computazionalmente difficili ... quindi, farò del mio meglio.

La strategia che vorrei adottare è essenzialmente questa:

• Usa un metodo più lento (se necessario; se c'è un modo più veloce, fantastico!), Ma prevedibile per ottenere risultati riproducibili
• Usa double per tutto il resto (ad es. Rendering)

Il breve di tutto questo è: devi trovare un equilibrio. Se stai spendendo 30ms di rendering (~ 33fps) e solo 1ms eseguendo il rilevamento delle collisioni (o inserisci qualche altra operazione altamente sensibile) - anche se tripli il tempo necessario per eseguire l'aritmetica critica, l'impatto che ha sul tuo framerate è si scende da 33,3 fps a 30,3 fps.

Ti suggerisco di profilare tutto, tenere conto di quanto tempo viene dedicato a ciascuno dei calcoli notevolmente costosi, quindi ripetere le misurazioni con 1 o più metodi per risolvere questo problema e vedere qual è l'impatto.

Il controllo dei collegamenti nelle altre risposte chiarisce che non avrai mai la garanzia che il punto mobile sia implementato "correttamente" o se riceverai sempre una certa precisione per un determinato calcolo, ma forse potresti fare uno sforzo migliore (1) troncando tutti i calcoli ad un minimo comune (ad esempio, se diverse implementazioni ti daranno da 32 a 80 bit di precisione, troncando sempre ogni operazione a 30 o 31 bit), (2) hanno una tabella di alcuni casi di test all'avvio (casi limite di aggiunta, sottrazione, moltiplicazione, divisione, sqrt, coseno, ecc.) e se l'implementazione calcola i valori corrispondenti alla tabella, non preoccuparsi di apportare modifiche.

La tua domanda in cose abbastanza difficili e tecniche O_o. Tuttavia potrei avere un'idea.

Sicuramente sai che la CPU esegue alcune regolazioni dopo qualsiasi operazione mobile. E la CPU offre diverse istruzioni che rendono diverse operazioni di arrotondamento.

Quindi, per un'espressione, il compilatore sceglierà una serie di istruzioni che ti condurranno a un risultato. Ma qualsiasi altro flusso di lavoro delle istruzioni, anche se intendono calcolare la stessa espressione, può fornire un altro risultato.

Gli "errori" commessi da un aggiustamento per arrotondamento cresceranno ad ogni ulteriore istruzione.

A titolo di esempio possiamo affermare che a livello di assieme: a * b * c non è equivalente a a * c * b.

Non ne sono del tutto sicuro, dovrai chiedere a qualcuno che conosce l'architettura della CPU molto più di me: p

Tuttavia per rispondere alla tua domanda: in C o C ++ puoi risolvere il tuo problema perché hai un certo controllo sul codice macchina generato dal tuo compilatore, tuttavia in .NET non ne hai. Quindi finché il codice della macchina può essere diverso, non sarai mai sicuro del risultato esatto.

Sono curioso di sapere in che modo questo può essere un problema perché la variazione sembra molto minima, ma se hai bisogno di un funzionamento davvero accurato l'unica soluzione a cui posso pensare sarà quella di aumentare le dimensioni dei tuoi registri mobili. Se possibile, usa la doppia precisione o anche il doppio lungo (non sei sicuro che sia possibile utilizzare la CLI).

Spero di essere stato abbastanza chiaro, non sono perfetto in inglese (... per niente: s)