While-Schleife bei C++

ja vieleicht verständlicher


n soll meine eingabe wert sein und und das programm soll hoch zäheln so 
hoch zählen das 0 + 1+2+3 und so weiter

@Gast
> for (int i=1; i<=eingabe; i++) summe += i;

wir habe zwar heute schnelle cpus, aber man doch ein wenig optimieren

summe = (eingabe + 1) * eingabe / 2;

Marcus Kunze schrieb:
> @Gast
>> for (int i=1; i<=eingabe; i++) summe += i;
>
> wir habe zwar heute schnelle cpus, aber man doch ein wenig optimieren
>
> summe = (eingabe + 1) * eingabe / 2;

:-)

Prinzipiell ja.
Aber darum gehts bei diesem Übungsbeispiel im Grunde gar nicht. Hier ist 
der Weg das Ziel.

Und wie man sieht, ist der Weg noch weit.

Gast schrieb:
> und immer wenn ich eine /2 lese bekomm ichs Kotzen.
>
> Denk mal drüber nach du Held...

Und warum bekommst du da das Kotzen?
(Ich bekomme immer das Kotzen, wenn Leute ihre Compilerbauer für 
Vollidioten halten, die ihrem Compiler absichtlich nicht beibringen, 
dass unter bestimmten Umständen ein /2 identisch ist zu einmal schieben 
nach rechts).

@NurEinGast
> ... und der OP wollte While-Schleifen lernen, nicht die Laufzeit
> optimieren.
Seit wann ist die for Schleife ein while Schleife? (die von Gast)


@gast
> und immer wenn ich eine /2 lese bekomm ichs Kotzen.
> Denk mal drüber nach du Held...

Dann Teste erstmal bevor du etwas schreibst.

@Marcus Kunze

Spielverderber ;-)

Gruß

Olaf

nur zur Info:

> (eingabe + 1) * eingabe

ist immer durch 2 Teilbar

@Gast
> Shifts existieren
Ja, aber das kann doch bitte schön der Compiler entscheiden und nicht 
ich.

Gast schrieb:
> Shifts existieren, und das gilt nicht nur für das Geschreibsel des OP.

optimierende Compiler existieren ebenfalls.
Das was du da andeutest, ist eine der trivialsten Optimierungen die ein 
Compiler überhaupt nur machen kann.

Wenn /2 am klarsten ist, dann schreibe auch /2. Den Rest macht der 
Compiler.

Gast schrieb:
> Tja, sag das der Optimierungs Voreinstellung.

Würde mich nicht wirklich wundern, wenn die meisten Compiler diese 
Trivialoptimierung selbst dann machen, wenn der Optimizer ausgeschaltet 
ist.

> Abgesehen davon sollte man
> wenn man sich schon damit brüstet optimieren zu wollen sowas auch mal
> selber bedenken.

Nein. Genau solche Dinge sollte man eben NICHT selber bedenken.
Du musst endlich von der Vorstellung weg, dass du irgendjemanden etwas 
Gutes damit tust, wenn du dich um solche Trivialoperationen selber 
kümmerst. Das genaue Gegenteil ist der Fall. Kümmere dich um den 
Algorithmus, kümmere dich um vernünftige Datentypen, kümmere dich darum 
dass dein Code gut lesbar und wartbar ist. Aber lass um Himmels Willen 
derartige Trivialtransformationen den Compiler machen!

> Ich bin ansonsten auch immernoch der Meinung das für hinreichend kleine
> n die Summierung schneller läuft als die Berechnung mit Multiplikation
> und Division, nicht das es dem OP darum gegangen wäre...

Das wäre ein Argument. Aber das ist nicht gekommen.

danke an alle die versucht haben mir zu helfen,

ich hab es selber hin bekommen



#include <cstdlib>
#include <iostream>
#include <conio.h>

using namespace std;

int main ()
{

    int n, i=0;
    cout <<" Gib eine Ganzzahl ein: ";
    cin >> n;
    long sum=0;
    while (i <= n)
   {
    sum = sum+i;
    i=i+1;}
    cout << " Die Summeder ersten " << n << " Ganzzahlenbetraegt: " << 
sum << endl;
    getch();


};

Und arbeite an deiner Codeformatierung.

Gast schrieb:
> Wie du willst Karl Heinz, ist müßig sich mit dir darüber zu streiten,
> insbesondere da du mit sowas bei den meisten Optimierungen und Compilern
> wohl recht haben wirst.

Nicht nur wohl.
Du würdest dich wundern, was Compiler aus solchen trivialen Operationen 
machen.
Oder schreibst du etwa

   x = ( ( y << 2 ) + y ) << 1;

als Ersatz für

  x = 10 * y;

Die meisten Compiler machen diese Ersetzung, wenn sie sich lohnt 
(CPU-abhängig) und haben bei anderen Zahlen noch ganz andere Tricks 
drauf.

Aber der springende Punkt ist:
Der Compiler macht dabei keine Fehler. Änderst du y von int auf long, 
geht obige Optimierung weiterhin. Änderst du den long in double, geht 
sie nicht mehr. Der Compiler berücksichtigt das. Aber ob der 
Programmierer beim Wechsel des Datentyps daran denkt, ist mehr als 
fraglich. Man kann also mit Fug und Recht behaupten, dass sich hier der 
Programmierer unnötigerweise ein Eigentor geschossen hat.

> Ich für meinen Teil bleibe dabei das Leute die optimieren wollen wissen
> sollten was der Compiler draus macht und ein Gefühl für Optimierungen
> haben.

Eben.
Aber du lenkst das Gefühl in die falsche Richtung.
Vor 30 Jahren war es noch cool, solche Ersetzungen zu kennen. Heute 
schmeisst dir jeder Vorgesetzte den Code um die Ohren, wenn du so etwas 
machst.
Optimieren ja. Aber nur dann wenn es sich lohnt. Und wenn ja, fängt man 
beim Algorithmus an und nicht bei Low-Level Operationen, es sei denn der 
Profiler hat gezeigt, dass es dort ein Problem gibt und das Assembler 
Listing hat gezeigt, dass man noch ein paar Nanosekunden schinden kann.

Karl heinz Buchegger schrieb:

> Vor 30 Jahren war es noch cool, solche Ersetzungen zu kennen.

Auch mit dem Hintergedanken, dass derartige Optimierungen auf praktisch 
allen CPUs gegriffen haben.

Heute ist das nicht mehr so. Was auf einer CPU schnell ist, kann auf der 
nächsten saulangsam sein. Der Compiler kennt seine Zielarchitektur und 
sucht sich die Operation raus, die gut geht (Ich würde an dieser Stelle 
gerne schreiben 'die optimial ist', aber das ist vermessen und in der 
Praxis nicht immer so)

Ich habe Wochen damit verbracht einen Hiddenliner auf einem 486 mittels 
Integerarithmetik auf schnell zu trimmen und die Probleme, die durch die 
grobe Diskretisierung entstehen in den Griff zu kriegen.

Ein plain vanilla Rewrite auf einem Pentium mit doubles hat diese 
int-Optimierung aber sowas von ausgehebelt (Coprozessor!)

Trrrrriple Post! ;-)