Beräkningar i C++

Kan du inte publicera koden du har problem med? För det låter ju som ett enkelt problem som exempelvis kan lösas med en enkel for loop.

hehe ja, trivialt probblem. Verkar som någon inte orkar göra programmerings uppgift i skolan.

edit såg att du posta källkoden.

antar att man kan göra med while loop, men som skrevs tidigare en for loop är enklare i detta fallet.

Variablen i inkrementerar du men aldrig använder.. värt att tänka över.

Dessutom adderar du inte till summan utan bara skriver över den.

Där har du några tips att arbeta vidare på. Eftersom det är skoluppgift så tycker jag inte du ska fråga efter lösningen utan snarare vägledning.

Jag måste erkänna att jag inte riktigt hänger med i dina tankebanor, while loopen borde väl pågå x-y antal gånger? nu kommer z=x+1 bli samma tal varje gång då du aldrig ändrar x. Sen vad använder du "i" till?

Faktum är att jag vet inte riktigt om jag borde publicera lösningen, men jag känner mig på bra humör. Lösningen är dock i C# och implementerar inte inläsning av tal:

            int startVärde = 2;
            int slutVärde = 7;

            int produkt = 1;

            for (int i = startVärde; i < (slutVärde+1);i++)
            {
                produkt = produkt * i;
            }


            Console.WriteLine(produkt);

Hejsan jag var bara tvungen att göra en oneliner:

	int func(int m, int n) {
		return m == n ? m : n * func(m, n - 1);
	}

När nånting inte funkar som det ska är det en bra idé och gå igenom sin kod steg för steg. Har man en debugger kan man steppa igenom koden, annars funkar det att tex skriva ut värden på alla variablar, men det kan oxå vara en god idé och skriva ner allt på papper. Gör man det brukar det framgå vad som gör rätt och vad som gör fel.

Dvs, i ditt fall (jag misstänker att du inte använt en debugger) så är det nog enklast och bara skriva ut allt, antingen manuellt på papper eller genom koden. Eller ännu bättre, gå igenom koden på papper först och skriv ut vad allting borde vara vid varje steg och jämför med vad det verkligen blir. Om du lägger en cout << efter varje rad i while-loopen blir det ungefär såhär:

cout << "x:" << x << endl;
cout << "y:" << y << endl;
cout << "z:" << z << endl;
while(z < y)
{
i++
cout << "i:" << i << endl;
z=x+1;
cout << "z:" << z << endl;
tot=z*z;
cout << "tot:" << tot << endl;
summa= x*tot*y;
cout << "summa:" << summa << " x:" << x << " y:" << y <<endl;
}

När du gjort det här klarnar det förhoppningsvis. (Ser du det inte direkt så börja med det enklaste fallet, dvs x = y = 1, och sedan x = 1, y = 2 osv så att du hänger med i vad koden gör) .

matti4s: Tyvärr är inte din lösning lika bra, den kommer nämligen krasha om det blir för många tal (dvs många funktionsanrop) som måste summeras.

En vettig compiler kan enkelt göra tail recursion optimization och ersätta det med en loop.

Dessutom så krävs det väl ett flertal miljoner iterationer innan det blir problem och vid det laget så har man passerat gränsen för vad en int klarar av att hantera flera gånger om. En gräns som kommer att få nästan vilken lösning som helst att falera.

Jag tycker man ska så fort som möjligt få upp en fungerande kod som är enkel och klar, sen om det visar sig att den är för slö eller äter för mycket minne kan man börja optimera om det behövs (vilket det i 90% av fallen inte gör).
Iofs kan man ju argumentera hurvida en rekursiv eller iterativ lösning är lättare att förstå, beror väl på var man kommer ifrån, om man är matematiskt lagd, osv.

Nej, en sådan optimering kan man bara göra om det rekursiva anropet görs sist i metoden, dvs return myfunc(..), inte när resultatet från anropet ska multipliceras med n.

I just det här fallet är det så, men det beror ju på att funktionen stiger i värde så snabbt. Ändrar man så att funktionen ska addera istället för att multiplicera är det däremot ganska jämnt vad som går i taket först... Dessutom segfaultar inte programmet om en int slår runt, men däremot om stacken tar slut (som blir fallet med för många rekursiva anrop)..

Föreslår man en alternativ lösning tycker jag det är på sin plats att iaf varna den man försöker hjälpa ifall lösningen är sämre och dessutom innehåller en lurig optimerings-möjlighet som inte tas tillvara. Speciellt nu när det var C++ där inte rekursion är lika centralt som i tex Haskell.

Eller ännu bättre, förklara vad problemet är och visa hur en bra rekursiv lösning utan problemet i fråga kan se ut. Men det skulle nog vara överkurs för trådskaparen