[Java] Erklärung von Code

[Ozymandiaz]

Nabend zusammen,

ich bin derzeit für meine Klausur Algorithmen und Programmierung 1 am lernen. Jedoch komm ich bei diesem Code nicht weiter.

    public static int doIt(int[] g)
    {
        int[] f = new int[g.length];
        int s = 0;
        for (int i = 0; i < g.length; i = i+1)
        { 
            f[i] = g[i]/3;
            s = s + f[i];
        }
    
        return s;
    }
    
    public static void main(String[] args)
    {
        int s = 0;
        int[] f = {12, 15};
        s = doIt(f);
        System.out.println(s);
        for (int i = 0; i < f.length; i=i+1)
            System.out.println(f[i]);
    }

Vom Prinzip verstehe ich den Code, aber ich verstehe nicht, wenn ich diesen ausführe, warum als System.out.println 9, 12 & 15 ausgegeben wird.

In der Funktion oben wird die Schleife so lange durchlaufen wie i < dem Array g.length ist. Woher kommt dann die 9?

Ich wäre froh, wenn mir das einer erklären könnte.
Vielen Dank!

 

[Fabii02]

12/3 = 4
15/3 = 5
5 + 4 = 9

Du gibst s direkt wieder aus und das ist deinem Fall nun mal 9

 

[madmax2010]

da va=orkauen bei sowas extrem wenig bringt:

schreib doch mal komentare an jede Zeile.
Die 9 ist die ausgabe der doIt funktion - einfach mal von Hand durch rechnen. Wenn du nicht auf 9 komst, zeig uns den rechenweg und wir sagen dir wo der Fehler liegt

 

[ReignInBlo0d]

In dem Array g stecken zwei Elemente (12 und15). Die Schleife oben wird also zwei mal durchlaufen. Jedes Mal wird je Element folgendes gemacht:

• Teile das Element durch 3 (das i-te Element von g / 3)
• addiere diesen Wert zu s hinzu.

s wird mit 0 initialisiert. Am Ende der ersten Iteration steht also 0 + (12/3), was 4 ergibt. s hat also bis hierher den Wert 4.
Jetzt wird die Schleife ein zweites mal durchlaufen, diesmal mit 15. Also 4 + (15/3), was 9 ergibt.

Am Schluss schreibt das Programm erst das Ergebnis der obigen Berechnung aus (es erscheint also 9 in der Konsole), und danach noch einmal den Inhalt des Arrays f (es erscheinen also 12 und 15).

edit: Merke: der Editor hier mag keine Arrays :-)

 

[Ozymandiaz]

🙄 oh wow. Ok das macht nun Sinn. Vielen Dank für die Hilfe.

 

[ReignInBlo0d]

Ich kann dem Ratschlag von @madmax2010 nur zustimmen. Sich selbst in einfachen Worten schrittweise dranschreiben, was eine Zeile bzw. ein Block tut, kann helfen einen Algorithmus nachzuvollziehen.

 

[madmax2010]

Ey, ich habe bis heute gummienten auf dem Schreibtisch / Im bad stehen. Um ihnen bei genau so Problemen davon zu erzaehlen. 90% aller Probleme loesen sich so in Wohlgefallen auf

 

[Fabii02]

Ey, ich habe bis heute gummienten auf dem Schreibtisch / Im bad stehen. Um ihnen bei genau so Problemen davon zu erzaehlen. 90% aller Probleme loesen sich so in Wohlgefallen auf

Du erzählst also tatsächlich nem Quietscheentchen wie dein Code funktioniert während du ein Bad nimmst?

Irgendwie voll coole Idee

 

[madmax2010]

https://en.wikipedia.org/wiki/Rubber_duck_debugging

Nimt halt das Prinzip, dass man zu Kommilitonen / Kollegen geht, ihnen das problem erklaert, wobei einem dann fast immer die Loesung einfaellt.

 

[entropie88]

Nur so als Tipp du kannst dir mehrmals mit
System.out.println("Text" & Variable);
ausgeben lassen was gerade passiert. Alternativ gibt es ja noch einen Debugger.

 

[abcddcba]

Zettel und Stift hätte hier gereicht, hat man in der Prüfung im Zweifel auch hab ich mal gehört

 

[aw48]

Wenn ich mir den vorgestellten Programmcode anschaue sieht das für mich nach "übernommen" von jemandem aus, der genau wußte was er da programmiert hat.
Es gibt Foren, wenn man da mit solchen Fragen kommt gibt's voll eine vor den Latz.
Mehr fällt mir zu dem thread nicht ein.

 

[DefconDev]

Wenn ich mir den vorgestellten Programmcode anschaue sieht das für mich nach "übernommen" von jemandem aus, der genau wußte was er da programmiert hat.
Es gibt Foren, wenn man da mit solchen Fragen kommt gibt's voll eine vor den Latz.
Mehr fällt mir zu dem thread nicht ein.

Ja, hinzu kommt, der Code macht null Sinn. Welcher bekannter Algorithmus soll das sein? Die Bezeichner machen einen wahnsinnig und unnötig viel zusätzliche Zeilen.

Für mich sieht das wie ein wirres Gewusel aus von jemanden der null Ahnung wie man mit einem Array umgeht. Und der nicht weiß, was Copy by Value bedeutet.

 

[BeBur]

Für mich sieht das wie ein wirres Gewusel aus von jemanden der null Ahnung wie man mit einem Array umgeht. Und der nicht weiß, was Copy by Value bedeutet.

Der Code wird von einem Mitarbeiter vom Prof kommen .
Vor allem macht mich Zeug wie s, f, doIt völlig wahnsinnig. Vielen Dank dafür, dass an der Uni beigebracht wird, wie man beschissenen Code mit unlesbaren Bezeichnern schreibt.
Man kann ja auch Code so schreiben, dass man NULL Programmierkenntnisse braucht um zu verstehen, was er tut. Aber das ist natürlich nicht "gut genug" für eine Uni.

 

[HorstSch87]

Das sind in der Lehre eben Distraktoren... Da soll getestet werden, ob der Student auch weiß, dass das f in main was anderes ist als das f in doIt, während das s bei beiden das "gleiche" bezeichnet. Die häufigsten Fehler werden hier z.B. wahrscheinlich sein, dass Leute denken dass f in main durch den doIt Aufruf verändert wird. Da mischt man dann gerne noch Typecasts rein, um zu sehen ob Leute auch die unterschiedlichen Datentypen verstehen.
Bin auch kein großer Freund davon, aber man sieht tatsächlich recht schnell, welche Aspekte jemand verstanden hat und welche nicht. Dass der Code kacke ist, ist also genau so gewollt.