Double e approssimazioni

[xyz]

Probabilmente vi ho confuso ancora di più le idee, ma questo è il motivo per cui per me è importante avere lo stesso risultato su tutte le jvm.

Sicuramente sei confuso, per la maggior parte dei casi quei valori sono accettabili. Prova a costruire una scatola di carta con una precisione sulle lunghezze fino alla diciassettesima cifra decimale se ci riesci.

Se volete vedere una differenza di calcolo tra FPU e SSE questo è un semplice programma in C:

387_SSE.c

Codice: Seleziona tutto

#include <stdio.h>
#include <math.h>

double calc(double a, double b)
{
    return sin((a / b) + (a -b));

}

int main(int argc, char **argv)
{
    double val = calc(1.0, 81.0);

    printf(MESSAGE " : %.22e %a\n", val,  val);

    return 0;
}

questo è il Makefile:

Codice: Seleziona tutto

CPU=k8

CC=gcc
CFLAGS=-O1 -ffast-math -march=$(CPU) -lm

SRC=387_SSE.c

all: 387_SSE-32-fpu 387_SSE-32-sse 387_SSE-64-fpu 387_SSE-64-sse

387_SSE-32-fpu: CFLAGS+=-m32 -mfpmath=387 -DMESSAGE="\"32bit 387\""
387_SSE-32-fpu: $(SRC)
   $(CC) $(CFLAGS) -o $@ $<

387_SSE-32-sse: CFLAGS+=-m32 -mfpmath=sse -DMESSAGE="\"32bit SSE\""
387_SSE-32-sse: $(SRC)
   $(CC) $(CFLAGS) -o $@ $<

387_SSE-64-fpu: CFLAGS+=-m64 -mfpmath=387 -DMESSAGE="\"64bit 387\""
387_SSE-64-fpu: $(SRC)
   $(CC) $(CFLAGS) -o $@ $<

387_SSE-64-sse: CFLAGS+=-m64 -mfpmath=sse -DMESSAGE="\"64bit SSE\""
387_SSE-64-sse: $(SRC)
   $(CC) $(CFLAGS) -o $@ $<


La CPU usata è un AMD64, questi sono i risultati dei 4 programmi:

Codice: Seleziona tutto

32bit 387 : 9.9245014186216595764023e-01 0x1.fc226ccc6ac8dp-1
32bit SSE : 9.9245014186216640172944e-01 0x1.fc226ccc6ac91p-1
64bit 387 : 9.9245014186216595764023e-01 0x1.fc226ccc6ac8dp-1
64bit SSE : 9.9245014186216640172944e-01 0x1.fc226ccc6ac91p-1

I risultati sono diversi se usata la FPU (387) o le istruzioni SSE.
il secondo valore è la rappresentazione del numero in float-point nella notazione frazionaria esadecimale (1 seguito dalla mantissa in esadecimale, lettera p e esponente in decimale).

[posta10100]

Sicuramente sei confuso, per la maggior parte dei casi quei valori sono accettabili. Prova a costruire una scatola di carta con una precisione sulle lunghezze fino alla diciassettesima cifra decimale se ci riesci.

OK, in quel caso la precisione non serve.
Sono d'accordo con te che non è necessario essere così precisi nel normale svolgimento del programma ma nel mio caso specifico (ricavare il segmento più lungo dato un insieme di segmenti componenti il perimetro di una ellissi) scegliere un segmento al posto di un altro può avere conseguenze imprevedibili.
Per questo mi preme che tutte le macchine si comportino allo stesso modo.

Ho implementato dei test (JUnit test) che lanciano una serie di metodi java confrontando poi il risultato con un risultato atteso.

Qui spiega meglio quello che volevo dire...

[xyz]

...ricavare il segmento più lungo dato un insieme di segmenti componenti il perimetro di una ellissi, scegliere un segmento al posto di un altro può avere conseguenze imprevedibili.
Per questo mi preme che tutte le macchine si comportino allo stesso modo...

Sicuramente esegui il test senza considerare nessuna tolleranza. Per confrontare dei numeri in float point non si deve mai fare il semplice test diretto ma si usa un codice più complesso, il più semplice codice usa il valore assoluto di una differenza inferiore a un valore di soglia opportuno. Alcuni esempi di codice in Java:

http://mindprod.com/jgloss/floatingpoint.html

[posta10100]

er confrontare dei numeri in float point non si deve mai fare il semplice test diretto ma si usa un codice più complesso, il più semplice codice usa il valore assoluto di una differenza inferiore a un valore di soglia opportuno.

In altre parti del codice lavora esattamente in questo modo ma in questo caso confronta il segmento trovato con quello atteso e succedeva che uno era da una parte e l'altro dal lato opposto!

Purtoppo a volte capita di lottare anche con queste cose!