Ifall nån är intresserad så har jag börjat en serie med små frågor angående C# och .NET med kanske inte helt självklara svar.

http://mostlytech.blogspot.com/search/label/Quiz

Kommentera gärna.

Har du själv svar på alla frågorna ?

Tex: (foo == double.NaN)

NaN verkar vara väldigt specialhanterat i clr:en
Om man dekompilerar o tittar på NaN i C# form så ser den ut att vara NaN = 1/0;

men om man tittar i IL så är den deklarerad som float64(NaN)

Dvs någon magisk IL konsant för NaN
Och IsNaN(double) blir man heller inte klokare på

public static bool IsNaN(double d)
{
return (d != d);
}
och det är isnan som anropas av equals..

och tittar man på IL koden för isnan så laddar den samma param på stacken två ggr och kör sedan en compare.

Så jag kan bara tänka mig att det är stenhårt hårdkodat in i IL att compare på nan och nan ger false..

eller har du någon annan förklaring?

NaN != NaN är väl en ganska välkänd princip?
Tror det specificeras så av IEEEs standard för de utökade flyttalen, tillsammans med inf och -inf.

Det är också ett halvfult trick för att kolla om ett värde är NaN; value != value.

Naturligtvis har jag ett svar på alla frågorna.

Och just NaN frågan, så som både Niklas och Ryan i en kommentar säger så är det i slutändan specificerat att det ska vara så av IEEE.

Fast mera åtkomlig är ju MSDN om double.NaN
<b>"Use IsNaN to determine whether a value is not a number. It is not possible to determine whether a value is not a number by comparing it to another value equal to NaN."</b>

Wikipedia:
http://en.wikipedia.org/wiki/NaN

Men det svarar ju inte på fårgan varför NaN != NaN.
dvs hur det går till rent tekniskt i clr:en, dvs hur följande kod kan ge false som svar..

L_0000: ldarg.0
L_0001: ldarg.0
L_0002: beq.s L_0006



Annars kan man ju använda samma svar på allt "Det ska vara så"

Jag har ingen källkod till CLR:en så jag kan inte säga om det är den eller processorn! som specialbehandlar NaN.

Sist och slutligen är ju inte NaN "som alla andra barn", vilket ju var hela poängen med den här frågan.

Jag är, säg, 70% säker på att det är processorns jobb att hantera det.