C# assigned sporadisch NaN

[justice strike]

Ik zit met een zeer vreemd probleem wat me echt behoorlijk wat tijd gekost heeft.

In het programma wat ik maak doe ik ergens een normale double assignment

code:

double x; 

x = functie();

de functie doet een bepaalde berekening. Hier is niets speciaals aan. Deze functie retourneert altijd hetzelfde.

als ik mijn simulatie 5000 keer laat draaien. Dan komt het vaak voor (minstens 10% van de gevallen) dat deze assignment verkeerd verloopt en dat x de waarde NaN krijgt.

ik heb dit nu opgelost door een while functie te maken

code:

while(double.isNaN(x))
{
x = functie();
}

toch begrijp ik niet waarom de assignment van deze variabele niet consistent verloopt. Is er bij iemand iets bekend over deze "willekeurige" assignment?

[Devion]

Not A Number, wat doet je functie als er iets fout loopt? Try catch? return values etc.

[Sebazzz]

@hieronder: Indien er geen return value wordt teruggegeven in één van de mogelijke paden in de functie zal de compiler dat al onderscheppen. En indien niet wordt er geloof ik een exceptie gegooid.

@TS: Te grote getallen... memory corruptie?

Heb je geen andere rare dingen, verschijnselen of problemen met je PC?

Ik stel voor te debuggen, en dan in een if clause waarin je controleert of het geen nummer is (Not a Number, NaN) de boel eens stap voor stap volgt.

Komen de NaN assignments achter elkaar voor en is het ook willekeurig?

[ Voor 23% gewijzigd door Sebazzz op 17-09-2008 15:49 ]

[whoami]

deel je soms door nul ?

[L-VIS]

Met hem ^ (Sebazzz dus)
Kun je niet gewoon controleren voordat Functie() retourneerd of ie NaN is? Ik vind dit nogal slordig.

Edit, van de MSDN:

The value of this constant is the result of dividing zero by zero.

This constant is returned when the result of an operation is undefined.

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.

[ Voor 62% gewijzigd door L-VIS op 17-09-2008 15:51 ]

[Sebazzz]

whoami schreef op woensdag 17 september 2008 @ 15:49:
deel je soms door nul ?

Wat dacht je van een System.DivideByZeroException of iets in die geest?
Het kan wel zijn dat de functie sporadisch een null teruggeeft.

[justice strike]

Devion schreef op woensdag 17 september 2008 @ 15:47:
Not A Number, wat doet je functie als er iets fout loopt? Try catch? return values etc.

functie can niet fout gaan. Zijn simpele optellingen.

code:

   private void getPreCalc(double xReturn)
    {
        klo = 0;
        khi = n - 1;

        while (khi - klo > 1)
        {
            k = (khi + klo) >> 1;

            if (x[k] > xReturn) khi = k;
            else klo = k;
        }
        h = x[khi] - x[klo];
        a = (x[khi] - xReturn) / h;
        b = (xReturn - x[klo]) / h;
    }

als de h gelijk is aan 0 dan zou er een NaN uit kunnen komen. Maar dit moet dan consequent gebeuren en dat is dan niet op te lossen door er een while statement achter te zetten.

[justice strike]

Sebazzz schreef op woensdag 17 september 2008 @ 15:47:
@hieronder: Indien er geen return value wordt teruggegeven in één van de mogelijke paden in de functie zal de compiler dat al onderscheppen. En indien niet wordt er geloof ik een exceptie gegooid.

het moet dan ook consequent een NaN zijn, en dat los je dan niet zo even op door een while loop te gebruiken

@TS: Te grote getallen... memory corruptie?
Heb je geen andere rare dingen, verschijnselen of problemen met je PC?

te grote getallen moeten toch geen probleem zijn? wederom, het werkt wel als je een while loop gebruikt.

memory corruptie lijkt me aannemelijker... maar dan zou de laptop ontzettend instabiel zijn... en dat is nu niet het geval.

Ik stel voor te debuggen, en dan in een if clause waarin je controleert of het geen nummer is (Not a Number, NaN) de boel eens stap voor stap volgt.

Komen de NaN assignments achter elkaar voor en is het ook willekeurig?

het is moeilijk te debuggen aangezien het dus niet consequent gebeurt. Dat maakt het zo een vreemd probleem.

[sig69]

Je functie returned niks, en heeft ook niet double als return type. Dit zou niet eens mogen compileren.

[ Voor 21% gewijzigd door sig69 op 17-09-2008 15:56 ]

[justice strike]

sorry dit is de functie die iets retourneerd

code:

 public double getYAtX(double xReturn)
    {
        getPreCalc(xReturn);
        return (a*y[klo]+b*y[khi]+((a*a*a-a)*y2[klo] + (b*b*b-b)*y2[khi])*(h*h)/6.0);
    }

de andere functie berekent echter de waardes uit, dus die was wel relevant.

[sig69]

Met simpel debuggen moet dit trouwens echt wel te vinden zijn. Zet een conditional breakpoint met als conditie:

code:

(a*y[klo]+b*y[khi]+((a*a*a-a)*y2[klo] + (b*b*b-b)*y2[khi])*(h*h)/6.0).IsNaN

Wacht tot hij hit en inspecteren die handel.

[Snake]

Bij getPreCal: gebruik this voor wat meer duideljikheid.

En gebruik aub eens duidelijke variablenamen, want dit is echt verschrikkelijk.

[ Voor 9% gewijzigd door Snake op 17-09-2008 16:02 ]

[justice strike]

dan alsnog, dit zou consequent of fout of goed moeten gaan. Er is nergens een conditie waardoor dit sporadisch fout of goed moet gaan.

[Sebazzz]

justice strike schreef op woensdag 17 september 2008 @ 15:55:

[...]

het is moeilijk te debuggen aangezien het dus niet consequent gebeurt. Dat maakt het zo een vreemd probleem.

Nou ik bedoelde eigenlijk daar een breakpoint plaatsen. En dat in de functie.
Je controlleert dus simpelweg in de functie of je een NaN gaat returnen en indien dat zo is doe je niks maar je kan dan wel een breekpunt plaatsen. Dan kan je kijken wat de interne waardes in de functie waren toen je de NaN kreeg.

C#:

if (double.IsNaN(ToReturn)) {
string x = ""; //hier een breakpoint plaatsen
}

Heb je nog verdere problemen met de computer waarop je dit draait of compileert? Problemen of rare dingen? Al geprobeerd te draaien op een andere computer?

[ Voor 10% gewijzigd door Sebazzz op 17-09-2008 16:04 ]

[bigbeng]

Ik zie allemaal variabelen gebruikt worden die niet uit de functie zelf afkomstig zijn. Dat maakt (gezien de afwezigheid van synchronisaties) jouw functie niet threadsafe. Met threads aan het stoeien?

Kun je misschien iets meer vertellen over waar je mee bezig bent? Met iets meer achtergrondinformatie kunnen wij je misschien ook meer helpen.

En een tip: werk met zinvollere naamgeving van je variabelen. Misschien dat namen als khi en klo mensen met kennis van het probleemdomein nog wel iets zeggen, maar dingen als n, h, a en b zijn niet echt heel erg handig gekozen en komen de leesbaarheid van je code niet ten goede.

[whoami]

Sebazzz schreef op woensdag 17 september 2008 @ 15:50:
[...]

Wat dacht je van een System.DivideByZeroException of iets in die geest?
Het kan wel zijn dat de functie sporadisch een null teruggeeft.

Een double delen door nul returned een NaN, en geen DivideByZeroException.
Waarom ? Omdat een 0 (in double) nooit echt echt 0 is, maar bv 0.000000000001.

Als je een Decimal deelt door 0, ga je wel een DivByZeroException krijgen.

[justice strike]

Snake schreef op woensdag 17 september 2008 @ 16:01:
Bij getPreCal: gebruik this voor wat meer duideljikheid.

En gebruik aub eens duidelijke variablenamen, want dit is echt verschrikkelijk.

dit zijn zeer duidelijke variabele namen. Het gaat hier om splines, iedereen die bezig is met splines weet precies waar dit over gaat.

[whoami]

Sebazzz schreef op woensdag 17 september 2008 @ 15:50:
[...]


Het kan wel zijn dat de functie sporadisch een null teruggeeft.

Yeah sure ... Een method die een double returned, die een null returned .
Ga eens lezen over reference & value types.

[Snake]

justice strike schreef op woensdag 17 september 2008 @ 16:04:
[...]


dit zijn zeer duidelijke variabele namen. Het gaat hier om splines, iedereen die bezig is met splines weet precies waar dit over gaat.

Je hoeft echt niet de dikke nek uithangen hoor.

En ik zie dat je 4 keer p vermenigvuldigd met zichzelf. Doe dan Math.Pow he.

[justice strike]

Snake schreef op woensdag 17 september 2008 @ 16:18:
[...]

Je hoeft echt niet de dikke nek uithangen hoor.

En ik zie dat je 4 keer p vermenigvuldigd met zichzelf. Doe dan Math.Pow he.

Dat was niet mijn intentie

en waarom ik geen Math.Pow gebruik, dat was even voor mijn collega's handiger om te lezen. (zijn een stelletje natuurkundigen/sterrenkundige die makkerlijker lezen met p*p*p*p dan met Math.pow()

ik zie dat de h in getprecalc 0 is. Maar ik kan er met mijn pet niet bij waarom deze soms 0 is en soms niet. Het slaat werkelijk nergens op.

[whoami]

justice strike schreef op woensdag 17 september 2008 @ 16:22:
[...]

ik zie dat de h in getprecalc 0 is. Maar ik kan er met mijn pet niet bij waarom deze soms 0 is en soms niet. Het slaat werkelijk nergens op.

zoals ik al zei.
Afronding ? Zit je soms met waarden die heel dicht nul moeten benaderen ? Misschien moet je je ook wel afvragen of double precies genoeg is voor jouw situatie.
Double is niet echt precies te noemen; misschien neem je beter decimal als datatype ?

[justice strike]

whoami schreef op woensdag 17 september 2008 @ 16:26:
[...]

zoals ik al zei.
Afronding ? Zit je soms met waarden die heel dicht nul moeten benaderen ? Misschien moet je je ook wel afvragen of double precies genoeg is voor jouw situatie.
Double is niet echt precies te noemen; misschien neem je beter decimal als datatype ?

ook afronding is niet willekeurig.

overigens zijn de waarde die uit in x[khi] en x[klo] gewoon precies hetzelfde (als er een NaN uit komt). dus 2 en 2. (niets achter de komma)


h = x[khi] - x[klo];

betekent dus dat die while ervoor niet altijd consequent goed werkt.

[ Voor 7% gewijzigd door justice strike op 17-09-2008 16:30 ]

[.oisyn]

Even het een en ander rechtzetten hoor

whoami schreef op woensdag 17 september 2008 @ 15:49:
deel je soms door nul ?

Dat geeft +/- infinity, tenzij de teller ook 0 is.

Sebazzz schreef op woensdag 17 september 2008 @ 15:50:
[...]

Wat dacht je van een System.DivideByZeroException of iets in die geest?

Wat dacht je van dat gebeurt alleen bij integers? Een deling door 0 op een float/double gooit geen exception.

Snake schreef op woensdag 17 september 2008 @ 16:01:
Bij getPreCal: gebruik this voor wat meer duideljikheid.

Subjectief. En aangezien C# geen losse functies kent, kan het niet anders dat getPreCal() ooit wat anders zou kunnen doen dan this.getPreCal().

En gebruik aub eens duidelijke variablenamen, want dit is echt verschrikkelijk.

Onzin. Kun je niet beweren zolang je de context niet kent. Standaard wiskundige formules gebruiken standaard variabel-namen (a, b, i, k, n, etc.). Hiervan afwijken is juist verschikkelijk, al helemaal als code gelezen gaat worden door andere wiskundigen. Iets met "probleemdomein" enzo.

whoami schreef op woensdag 17 september 2008 @ 16:04:
Waarom ? Omdat een 0 (in double) nooit echt echt 0 is, maar bv 0.000000000001.

Onzin, een 0 is weldegelijk 0 (maar kan wel +0 of -0 zijn, hoewel die twee wel true comparen met elkaar, dus het is niet zo'n big deal)

Snake schreef op woensdag 17 september 2008 @ 16:18:
En ik zie dat je 4 keer p vermenigvuldigd met zichzelf. Doe dan Math.Pow he.

3 muls zijn over het algemeen sneller dan 1 pow.
Snake, je zeikt meer over de code zelf dan dat je iets toevoegt aan de draad, en dan ook nog met imho onzinnige argumenten. Hou dan gewoon je mond

[ Voor 11% gewijzigd door .oisyn op 17-09-2008 16:36 ]

[.oisyn]

justice strike schreef op woensdag 17 september 2008 @ 16:29:
overigens zijn de waarde die uit in x[khi] en x[klo] gewoon precies hetzelfde (als er een NaN uit komt). dus 2 en 2. (niets achter de komma)

Wat zijn khi en klo in dat geval? En de contents van x[]? Is het gegarandeerd dat er nooit dubbele waarden in x[] voorkomen?

betekent dus dat die while ervoor niet altijd consequent goed werkt.

Als ik de aanname maak dat de waarden in x[] uniek en oplopend zijn, dan zie ik zo snel niets verkeerds en lijkt het me een normale binary search.

[whoami]

.oisyn schreef op woensdag 17 september 2008 @ 16:30:
[...]


Dat geeft +/- infinity, tenzij de teller ook 0 is.

Hmm, idd dit geeft infinity.
Ik baseerde me op iets wat ik me herinnerde van een tijd geleden, maar ik vind dat topic niet direct terug.

Onzin, een 0 is weldegelijk 0 (maar kan wel +0 of -0 zijn, hoewel die twee wel true comparen met elkaar, dus het is niet zo'n big deal)

Is het niet zo dat, als je wil checken of een double == aan een andere double, dat je dit dan beter met een soort van 'range' check gaat doen ?
Ik bedoel maar, die variable 'h', die de noemer is van de breuk die TS wil doen, kan perfect het resultaat zijn van een bewerking die resulteert in 0.00...01 oid.

3 muls zijn over het algemeen sneller dan 1 pow.

Ook in .NET ? Gaat de JIT dit niet gaan optimalizeren ?

[justice strike]

Kijk, ik begrijp dat als de khi en de klo resulteren in dezelfde waardes van een bepaalde array (bijvoorbeeld als ze naar dezelfde index wijzen) dat je dan een NaN veroorzaken.

Wat ik echter niet begrijp is waarom dit niet consequent in een bepaalde manier gebeurt. Ik die in principe meteen een while achter de functie. en er wordt nergens nieuwe assignments gedaan naar de array. Je zou dus altijd hetzelfde verwachten uit de functie. Of zie ik nu iets over het hoofd?

[.oisyn]

whoami schreef op woensdag 17 september 2008 @ 16:46:
Is het niet zo dat, als je wil checken of een double == aan een andere double, dat je dit dan beter met een soort van 'range' check gaat doen ?

Natuurlijk, als je wilt controleren of een floating point getal een bepaalde arbitraire waarde heeft die uit een berekening komt rollen, dan kun je beter een foutmarge toevoegen (iets als: abs(a-b)/abs(a+b) > epsilon, met a en b de waarden die je wilt vergelijken en epsilon de foutmarge.

Maar dat was niet het punt. Het punt was dat 0 gewoon 0 is, maar dat een float wel twee manieren heeft om 0 op te slaan: +0 en -0. Maar dat is niet erg, want die twee waarden zijn niet ongelijk aan elkaar.

Ik bedoel maar, die variable 'h', die de noemer is van de breuk die TS wil doen, kan perfect het resultaat zijn van een bewerking die resulteert in 0.00...01 oid.

Maar dat is geen 0, en dus kan er gedeeld worden. Zolang het resultaat past natuurlijk, ik weet even niet meer of IEEE nu voorschrijft dat de waarden geclamped moeten worden of dat er NaN uit komt rollen (volgens mij het eerste), maar de kans is vrij klein dat dat het geval is als de waarden waaruit h wordt berekend van dezelfde orde van grootte zijn als de teller bij de deling door h (wat hier ook het geval blijkt - h is hoogstens een factor 2^-53 van de teller, en in een double kun je van 2^-1022 naar 2¹⁰²³, dus die 53 is maar een vrij kleine marge).

Ook in .NET ? Gaat de JIT dit niet gaan optimalizeren ?

Ik had het over de assembly instructions in hedendaagse floating point units. Of de JITer een aanroep naar Math.Pow() gaat optimizen naar muls betwijfel ik, omdat hij dan de semantiek van Math.Pow() moet kennen én het tweede operand dan exact 0, 1, 2, 3 of 4 moet zijn om het te kunnen optimizen. Het lijkt me tè special case om dat in een compiler in te bouwen.

[ Voor 3% gewijzigd door .oisyn op 17-09-2008 17:04 ]

[.oisyn]

justice strike schreef op woensdag 17 september 2008 @ 16:58:
Kijk, ik begrijp dat als de khi en de klo resulteren in dezelfde waardes van een bepaalde array (bijvoorbeeld als ze naar dezelfde index wijzen) dat je dan een NaN veroorzaken.

Wat ik echter niet begrijp is waarom dit niet consequent in een bepaalde manier gebeurt. Ik die in principe meteen een while achter de functie. en er wordt nergens nieuwe assignments gedaan naar de array. Je zou dus altijd hetzelfde verwachten uit de functie. Of zie ik nu iets over het hoofd?

Weet je zeker dat die functie maar vanuit 1 thread wordt aangeroepen?

[justice strike]

.oisyn schreef op woensdag 17 september 2008 @ 17:02:
[...]


Weet je zeker dat die functie maar vanuit 1 thread wordt aangeroepen?

uhm... ja. Sterker nog, de objecten worden naar een andere pc gestuurd. Ik kan er een synchronized statement voor zetten.

(het klopt overigens wel dat h 0 kan zijn, maargoed dat zou dan dus consequent 0 moeten zijn)

[.oisyn]

Het lijkt me toch het meest aannemelijk dat bepaalde waarden tussendoor veranderen. Desnoods kun je iedere keer een hash berekenen over al je data, en dan kijken of die hash tussendoor wijzigt.

[roy-t]

public double getYAtX(double xReturn)
{
getPreCalc(xReturn);
return (a*y[klo]+b*y[khi]+((a*a*a-a)*y2[klo] + (b*b*b-b)*y2[khi])*(h*h)/6.0);
}

De functies en variabelen waarvan deze functie afhankelijk is worden gezien de code ook door anderen functies gebruikt, het is heel erg lastig te zien of die niet verkeerd beinvloed worden door andere code, ik denk dat er heel ergens anders een bug zit dan in deze en de inner method.

Vooral in getPreCalc(xReturn); gebeurt veel met variabelen buiten de eigen scoop, check is alle references naar die variabelen waar mee gerekend wordt en check is waar ze vandaan komen.

Verder heb je al meerdere keren gereageerd maar nogsteeds niet geprobeerd te debuggen terwijl veel mensen daar al tips voor hebben gegeven.

Tip 1: Debug!!!
Tip2: Check alle references naar de variableen die gebruikt worden. (Ik weet niet precies wat je doet maar al die dependent variabelen zijn waarschijnlijk voor meer methods nodig, maar op deze manier is het wel een beetje eng dat je telkens waarden al opgehoogd / veranderd voor het uitrekenen van iets anders.

[justice strike]

roy-t schreef op woensdag 17 september 2008 @ 17:55:
[...]


De functies en variabelen waarvan deze functie afhankelijk is worden gezien de code ook door anderen functies gebruikt, het is heel erg lastig te zien of die niet verkeerd beinvloed worden door andere code, ik denk dat er heel ergens anders een bug zit dan in deze en de inner method.

Vooral in getPreCalc(xReturn); gebeurt veel met variabelen buiten de eigen scoop, check is alle references naar die variabelen waar mee gerekend wordt en check is waar ze vandaan komen.

Verder heb je al meerdere keren gereageerd maar nogsteeds niet geprobeerd te debuggen terwijl veel mensen daar al tips voor hebben gegeven.

Tip 1: Debug!!!

dat debuggen is dus al gedaan het ligt aan de h waarde die uitgerekent wordt door x[khi]-x[klo].

Tip2: Check alle references naar de variableen die gebruikt worden. (Ik weet niet precies wat je doet maar al die dependent variabelen zijn waarschijnlijk voor meer methods nodig, maar op deze manier is het wel een beetje eng dat je telkens waarden al opgehoogd / veranderd voor het uitrekenen van iets anders.

de waardes die gebruikt worden zijn indexen. Er wordt in principe niets veranderd.

om het probleem wat duidelijker te schetsen. We hebben hier te maken met een cubic spline. Een cubic spline is niets meer dan een aaneenschakeling van 3de machts functies aan elkaar zo dat je een vloeiende lijn krijgt die goed te interpoleren is.

je schiet in een cubic spline een aantal waardes in (minimum van 4 geen max) en de spline wordt dan zodanig geconstrueerd dat deze door alle punten heen gaat. Dit is niet heel moeilijk, en voor de geinteresseerde wil ik dit best nog wel uiteen zetten.

wat ik in de functie die de fout geeft eigenlijk doe is de y waarde uitrekenen voor een gegeven x. Ik vraag dus eigenlijk alleen een waarde op en ben helemaal niet bezig met waardes aanpassen.

2 fases dus:
1. spline fitting, hierin worden dus wel waardes aangepast
2. spline interpolation. De x waarde word opgezocht en de y waarde wordt geretourneerd.

[.oisyn]

Je uitleg is volledig irrelevant (en even terzijde, ik ben zelf behoorlijk bekend met splines ). Het punt blijft dat er soms een andere waarde wordt teruggegeven. Dat betekent dat soms de invoer anders is. Ik heb niet het idee dat jij al eens een keer met een debugger stap voor stap door de code heen bent gegaan om de berekeningen te verifieren, anders was je nu al een paar stappen verder geweest richting de oorzaak van de bug.

Ik snap dat dat lastig is omdat het NaN probleem maar af en toe voorkomt, en je van tevoren moet weten wanneer het fout gaat om fatsoenlijk te kunnen debuggen. Maar je zou eens alle waarden en uitkomsten van alle berekeningen naar een logfile kunnen outputten, zodat je naderhand kunt kijken wat er verschillend is aan die ene keer dat het wel fout gaat tov al die keren dat het goed gaat.

Door gewoon maar naar de code te staren en jezelf ervan te overtuigen dat dat verder allemaal klopt kom je geen steek verder mee, of je eigen code nou daadwerkelijk de oorzaak ervan is of niet.

[ Voor 10% gewijzigd door .oisyn op 18-09-2008 12:00 ]

[roy-t]

.oisyn schreef op donderdag 18 september 2008 @ 11:56:
Je uitleg is volledig irrelevant (en even terzijde, ik ben zelf behoorlijk bekend met splines ). Het punt blijft dat er soms een andere waarde wordt teruggegeven. Dat betekent dat soms de invoer anders is. Ik heb niet het idee dat jij al eens een keer met een debugger stap voor stap door de code heen bent gegaan om de berekeningen te verifieren, anders was je nu al een paar stappen verder geweest richting de oorzaak van de bug.

Ik snap dat dat lastig is omdat het NaN probleem maar af en toe voorkomt, en je van tevoren moet weten wanneer het fout gaat om fatsoenlijk te kunnen debuggen. Maar je zou eens alle waarden en uitkomsten van alle berekeningen naar een logfile kunnen outputten, zodat je naderhand kunt kijken wat er verschillend is aan die ene keer dat het wel fout gaat tov al die keren dat het goed gaat.

Door gewoon maar naar de code te staren en jezelf ervan te overtuigen dat dat verder allemaal klopt kom je geen steek verder mee, of je eigen code nou daadwerkelijk de oorzaak ervan is of niet.

dat debuggen is dus al gedaan het ligt aan de h waarde die uitgerekent wordt door x[khi]-x[klo].

Als je zelfs al weet waar het door komt is het toch slechts een breakpoint op 'h' zetten en kijken wanneer deze veranderd. Verder: RMB->Find All References!

Verder kun je voor alleen de Y uitrekenen beter een Method maken met return Type Double en dan zoiets als "public double GetY(double x)"

Verder verander je H wel degelijk:

code:

h = x[khi] - x[klo];
a = (x[khi] - xReturn) / h;
b = (xReturn - x[klo]) / h;

Je hebt dus niet een simpele functie die de Y teruggeeft en de rest van de waarden met rust laat, OF: alleen waarden aanpast binnen de scope van de method en dan y teruggeeft, maar je geeft blijkbaar public/private variabelen een andere waarde. Als na het aanroepen van deze method iets anders nog even h veranderd voordat je hem weer uitleest ben je fucked .

[ Voor 18% gewijzigd door roy-t op 18-09-2008 12:41 ]

[MSalters]

.oisyn schreef op woensdag 17 september 2008 @ 16:59:
[0.00001]
Maar dat is geen 0, en dus kan er gedeeld worden. Zolang het resultaat past natuurlijk, ik weet even niet meer of IEEE nu voorschrijft dat de waarden geclamped moeten worden of dat er NaN uit komt rollen (volgens mij het eerste),

Overflow levert je +/- INF op. Zelfs x/0 levert je +/- INF op, alleen 0/0 niet.

Of de JITer een aanroep naar Math.Pow() gaat optimizen naar muls betwijfel ik, omdat hij dan de semantiek van Math.Pow() moet kennen én het tweede operand dan exact 0, 1, 2, 3 of 4 moet zijn om het te kunnen optimizen. Het lijkt me tè special case om dat in een compiler in te bouwen.

Voor compilers misschien, maar er zijn pow() implementaties die testen op gehele getallen als exponent.

[.oisyn]

roy-t schreef op donderdag 18 september 2008 @ 12:39:
Als je zelfs al weet waar het door komt is het toch slechts een breakpoint op 'h' zetten en kijken wanneer deze veranderd. Verder: RMB->Find All References!

h wordt iedere keer opnieuw berekend, dus daarmee bereik je niets. De oorzaak zit 'm in x[].

MSalters schreef op donderdag 18 september 2008 @ 13:00:
[...]

Overflow levert je +/- INF op. Zelfs x/0 levert je +/- INF op, alleen 0/0 niet.

Klopt ja, ik was even in de war met de PS2 die geen inf kent en dus +/- FLT_MAX returnt bij een overflow (ook bij een deling door 0 trouwens )

Voor compilers misschien, maar er zijn pow() implementaties die testen op gehele getallen als exponent.

Ik vraag me af hoeveel zin dat heeft op een x86 machine.

[ Voor 42% gewijzigd door .oisyn op 18-09-2008 13:29 ]

[bomberboy]

.oisyn schreef op donderdag 18 september 2008 @ 13:03:
[...]
h wordt iedere keer opnieuw berekend, dus daarmee bereik je niets. De oorzaak zit 'm in x[].

of khi en klo die gelijk zijn aan elkaar? Dat lijkt me niet onmogelijk te zijn, toch? bv in het geval dat n=3 in het begin. (dan kunnen ze beiden 0 worden denk ik)

Maar wat ik nog niet helemaal snap, die NaN's die voorkomen, is dat dan telkens voor dezelfde inputset? En zijn je simulaties deterministisch? Dus voor dezelfde input altijd dezelfde output, of niet?
Indien niet, probeer eens zo'n versie te creëren (indien mogelijk) en zoek een input waar het probleem optreedt, dan moet het wel relatief snel te vinden zijn.

[.oisyn]

bomberboy schreef op donderdag 18 september 2008 @ 13:16:
[...]


of khi en klo die gelijk zijn aan elkaar? Dat lijkt me niet onmogelijk te zijn, toch? bv in het geval dat n=3 in het begin. (dan kunnen ze beiden 0 worden denk ik)

Ze kunnen nooit gelijk worden, tenzij n=1.

C#:

        klo = 0;
        khi = n - 1;

        while (khi - klo > 1)
        {
            k = (khi + klo) >> 1;

            if (x[k] > xReturn)
                khi = k;
            else
                klo = k;
        }

Bij n=3 wordt khi=2. Dan gaat ie de while in (khi-klo = 2, 2 > 1), en k wordt dan 1. Vervolgens wordt khi of klo gelijk aan k, afhankelijk van x[k]. In beide gevallen is khi - klo gelijk aan 1, dus gebeurt er geen volgende iteratie.

[justice strike]

bomberboy schreef op donderdag 18 september 2008 @ 13:16:
[...]


of khi en klo die gelijk zijn aan elkaar? Dat lijkt me niet onmogelijk te zijn, toch? bv in het geval dat n=3 in het begin. (dan kunnen ze beiden 0 worden denk ik)

Maar wat ik nog niet helemaal snap, die NaN's die voorkomen, is dat dan telkens voor dezelfde inputset? En zijn je simulaties deterministisch? Dus voor dezelfde input altijd dezelfde output, of niet?
Indien niet, probeer eens zo'n versie te creëren (indien mogelijk) en zoek een input waar het probleem optreedt, dan moet het wel relatief snel te vinden zijn.

de berekening is deterministisch. Daarom is het vreemd dat de input niet altijd dezelfde output geeft.

[justice strike]

.oisyn schreef op donderdag 18 september 2008 @ 13:27:
[...]

Ze kunnen nooit gelijk worden, tenzij n=1.

C#:

        klo = 0;
        khi = n - 1;

        while (khi - klo > 1)
        {
            k = (khi + klo) >> 1;

            if (x[k] > xReturn)
                khi = k;
            else
                klo = k;
        }

Bij n=3 wordt khi=2. Dan gaat ie de while in (khi-klo = 2, 2 > 1), en k wordt dan 1. Vervolgens wordt khi of klo gelijk aan k, afhankelijk van x[k]. In beide gevallen is khi - klo gelijk aan 1, dus gebeurt er geen volgende iteratie.

ik ga x eventjes printen. Het komt vaak voor bij khi==2of3 en klo==2of3.

[bomberboy]

.oisyn schreef op donderdag 18 september 2008 @ 13:27:
[...]
Ze kunnen nooit gelijk worden, tenzij n=1.

Inderdaad, was daar even de mist in gegaan met mijn redenering.

justice strike schreef op donderdag 18 september 2008 @ 13:37:
[...]
de berekening is deterministisch. Daarom is het vreemd dat de input niet altijd dezelfde output geeft.

Dan moet dit toch bijna een concurrency/race condition-issue zijn? Dat je khi, klo of k variabele ergens extern wordt aangepast, want het valt me wel op dat deze niet intern in je functie zijn gedeclareerd? Waarom niet eigenlijk? Ik ben nu wel niet echt vertrouwd met C#, maar dat moet daar toch ook dacht ik.
Indien je die achteraf nog nodig hebt lijkt het me netter om die te als return value te retourneren.