Domanda

Ho fatto il porting di un progetto c ++ con i test GTEST ad un progetto di c # avere un test NUnit. Ora ho incontrato problemi con precisione in virgola mobile.

nel test NUnit ho non essendo ok (rosso)

Assert.AreEqual(0.7, 7 * 0.1); 

nel test GTEST ho:

ASSERT_DOUBLE_EQ(0.7, 7 * 0.1);

che è ok (verde)

La domanda ora è PERCHE ' ???

È stato utile?

Soluzione

In alternativa è possibile aggiungere un terzo parametro, che è la massima differenza tra i due valori, come si può leggere qui .

public static void AreEqual (
    double expected,
    double actual,
    double delta
)
  

Verifica che due precisate Doubles   sono uguali, o all'interno della specificato   accuratezza di ogni altro. l'asserzione   non riesce se non sono all'interno del   la precisione specificata di ogni altro.

Altri suggerimenti

mai-mai confrontare i numeri in virgola mobile per l'uguaglianza! numeri frazionari decimali (come 0.1) non possono essere rappresentati in IEEE galleggia senza precisione piccola perduta. ciò che può apparire come 0.7 può essere 0,6999,999 mila o qualcos'altro davvero. sono numeri diversi allora. Si dovrebbe usare la tecnica epsilon:. Considerare a == b if abs(a - b) <= epsilon, dove epsilon è molto piccolo numero costante

leggere questo e molti altri ^

http://docs.sun.com/source/806-3568 /ncg_goldberg.html

Cosa c'è di sbagliato con l'utilizzo == per confrontare galleggianti in Java ?

verifica ASSERT_DOUBLE_EQ() di Google prova che il valore effettivo è entro 4 ULPs di quello atteso (per più informazioni all'indirizzo https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#floating-point-comparison ) . Nunit probabilmente eseguendo confronto esatto.

Assert.AreApproximatelyEqual quando si confrontano i galleggianti al posto.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top