Archief - [C++] MSVC9 en GCC geven ander rekenresultaat

Beste 9livers,

Ik zal de serieuze kant van dit forum een uitproberen vandaag.

Ik heb als examen Informatica een programmaatje moeten schrijven dat (heel simpel) de kritische massa van een blok of sfeer Uranium bepaald. Nu dacht ik, ik zal hem eens invoeren in mijn VirtualBox Ubuntu en eens onder linux compileren. Code::Blocks en build-essential geinstalleerd, en hij compileerde met een enkele warning die hier niets toe doet...

Om een lang verhaal kort te maken, de berekende resultaten zijn voor beide platformen anders, en dat maar voor een specifiek geval. Als je mijn programma eventjes compileert en runt, zal er een file Taak 1 - Test komen te staan. Onder Windows geeft ie gewone waarden en onder linux geeft die allemaal inf's. Voor mij is dit een reeel raadsel...

Het programma maakt simpel geburik van polymorfisme (dat was ook de opdracht). Als iemand zich geïnteresseerd voelt...

Hier is een link naar de source:MEGAUPLOAD - The leading online storage and file delivery service

Hartelijk bedankt!

Ik heb geen windows bij de hand dus ik kan niet vergelijken. Ik heb ook maar eens vluchtig met de debugger erdoor getraced, maar met code::blocks en Ubuntu 9.04 heb ik gemerkt dat er in het volgende stuk een probleem zit:

Bij de 2de run wordt F1 = 1 en F0 is ook 1 => 1 - 1 = 0 en delen door 0 gaat niet.

En welke waarden geeft hij onder Windows? Als die waarden belachelijk groot zijn, is het niet zo gek dat hij inf(inity) print.

Amai, snelle respons

Hij geeft goede en reële waarden onder windows:
1.61412
1.76948
1.68766
1.55808
1.65322
1.63722
1.52273
1.59156
1.67918
1.72677
(inhoud Taak 1 - Test)

Hoe komt het dan dat hier een verschil tussen zit? En belangrijker, hoe los ik dat op?
EDIT: zou het op te lossen zijn door de initiële grenzen van de Regula-Falsi te beperken (ie de bovengrens kleiner maken? Maar de vraag vanwaar het verschil blijft geldig...
EDIT2: als ik x2 initialiseer op 2 ipv 100 krijg ik hetzelfde. Daar zou getSurvivalF toch niet meer 2 mogen geven, want dat ligt dicht bij waar F=1 (x=+-1.6). Ik blijf op inf uitdraaien terwijl Taak 3 - Test juiste waarden oplevert voor een sfeer.

Sorry voor alle edits en nu de nieuwe reply, maar...

Ik merk juist dat F0 in Visual Studio altijd gelijk is aan -1, wat ook zou moeten... hij is nooit gelijk aan 1. Ik ben dik in de war (en kan geen debugging doen in Ubuntu en Code::Blocks want hij zegt dat ie het bestand niet kan vinden)

2 of 100 maakt niets uit, want uw getSurvivalF() geeft een verkeerde waarde terug. Alle, verkeerd, het is te zeggen. Voor neutron 1 en 2 doet ge ++NiN, en die voert dat nu dus 2x uit, waardoor uw resultaat in dit geval altijd 2 is. en 2-1 = 1, 1-1 = 0 en delen door 0 is INF.

Ik gok dat het ergens met uw rand de mist in gaat. Ik zou dat eens nakijken of dat wel correct is. Ik ken niet echt de details van uw taak en of dat allemaal correct zou zijn.

Edit: Om te debuggen in code::blocks moet je zorgen dat GDB geinstalleerd is. Ik kan me niet herinneren dat ik iets anders speciaals gedaan heb. Welk bestand kan die niet vinden?

Het komt erop neer dat er in MSVC niks mis is, ie alle waarden zijn wat ze moeten zijn. En die ++Nin twee keer hoort idd bij de taak: F(m) loopt tussen F(0)=0 en F(inf)=2 voor alle mogelijke vormen.

Als k ff gedebugged heb met Visual Studio, lijkt mij het volgende: x0 is 0, dus de F waarde die daarvoor berekend wordt moet 0 zijn (wat in Windows althans ook zo is). Dus wordt F0=-1, en komt ie nooit in de buurt van 1. Mijn unirand is toch een random variabele tussen 0 en 1 ((double)rand()/RAND_MAX) en dit platformonafhankelijk toch, hij doet het alleen beter onder linux (RAND_MAX is hoger). Daarnaast zijn alle random getallekes enzo correct berekend voor de taak. Het zit em ergens in het verschil win32-linux volgens mij.
Al bedankt voor de respons trouwens, da k t nie vergeet

Ik heb het gevonden!!!!!!!!!!!!

Ik had ooit ergens eens gelezen dat abs() een functie is die soms de foute keuze maakt qua type. Ze is overloaded voor int, float en double, maar het kan dat deze een slechte keuze maakt. Bij deze heb ik in isInside van Bar.cpp de abs vervangen door fabs en het werkt gewoon zoals het hoort.

That's some crazy shit right there

Bedankt voor de hulp nochtans

PS: het probleempje met debuggen is ook opgelost: ik had mijn cpp files in een map code::block gestoken, maar blijkbaar ziet de debugger de ":" als een regelaanduiding en kan die er dus niet mee overweg.