Goto Punkteabzug?

volkard

Naja, hier läuft ein Lehrer rum, der nimmt folgendes nicht an und gibt 0 Punkte drauf:
(f(x)=x³-2*x²)

Untersuchung Achsensymmetrie zur y-Achse (Bedingung f(x)=f(-x)):
f(1)=-1
f(-1)=-3
f(1)!=f(-1)
Da die Bedingung f(x)=f(-x) für x=1 nicht erfüllt ist, kann sie auch nicht für alle x erfüllt sein. Damit ist f nicht achsensymmetrisch zur y-Achse.
Das ist für ihn nicht "gerechnet".

Was er haben will, und mit vollen Punkten versieht, ist folgendes:
Untersuchung Achsensymmetrie zur y-Achse (Bedingung f(x)=f(-x)):
f(x)=f(-x)
x³-2*x²=(-x)³-2*(-x)²
x³-2*x²=-x³-2*x²
x³=-x³
=> nicht achsensymmetrisch.

Samyboy

volkard schrieb:

Naja, hier läuft ein Lehrer rum, der nimmt folgendes nicht an und gibt 0 Punkte drauf:
(f(x)=x³-2*x²)

Untersuchung Achsensymmetrie zur y-Achse (Bedingung f(x)=f(-x)):
f(1)=-1
f(-1)=-3
f(1)!=f(-1)
Da die Bedingung f(x)=f(-x) für x=1 nicht erfüllt ist, kann sie auch nicht für alle x erfüllt sein. Damit ist f nicht achsensymmetrisch zur y-Achse.
Das ist für ihn nicht "gerechnet".

Was er haben will, und mit vollen Punkten versieht, ist folgendes:
Untersuchung Achsensymmetrie zur y-Achse (Bedingung f(x)=f(-x)):
f(x)=f(-x)
x³-2*x²=(-x)³-2*(-x)²
x³-2*x²=-x³-2*x²
x³=-x³
=> nicht achsensymmetrisch.

Genau so hab ichs gemeint :p

asc

Bashar schrieb:

Schlechter Stil gibt Abzug. Ich geb doch nicht volle Punktzahl für ein schlechtes Programm? Dass es funktioniert, ist sehr gut, aber ein Programm muss auch wartbar sein.

Im Studium gab es bei uns zwei parallele Programmierveranstaltungen. In der einen bekam man bei einem nicht lauffähigen Programm am Schluss automatisch eine 5 oder 6, und der Programmierstil war vollkommen egal. Der andere Lehrer hat sich wiederum mit dem Code auseinander gesetzt, geschaut ob dieser a) der Aufgabe entspricht und b) der Codestil akzeptabel war.

Ich war zum Glück in der zweiten Gruppe, da meines Erachtens mehr als nur lauffähig/nicht lauffähig relevant ist. An der Arbeit würde ich auch einen "Punktabzug" bei schlechten Code bekommen (sofern der Code nicht nur von einem selbst gelesen werden soll), und der Zeitfaktor der Fertigstellung ist auch Situationsabhängig (und meinen bisherigen Chefs [wobei sie es teilweise noch lernen mussten] war es im Zweifel lieber, einen Auslieferungstermin ein wenig zu verschieben, als das die Kunden durch schwere Fehler verscheucht werden).

Bashar schrieb:

BTW wenn das goto sinnvoll und berechtigt ist,...

Ich persönlich kenne kaum eine Sprache wo ein goto wirklich sinnvoll ist, auch wenn ich dir recht gebe, das man niemals ganz vereinheitlichen kann. Ich habe aber tendenziell für den Punkteabzug gestimmt, da mir bislang keine Ausnahme in meinen bevorzugten Sprachen untergekommen ist (Ausnahme C# in Kombination mit switch, in dem es eine etwas andere Behandlung erfährt).

Bashar

volkard schrieb:

Naja, hier läuft ein Lehrer rum, der nimmt folgendes nicht an und gibt 0 Punkte drauf:[...]
Damit ist f nicht achsensymmetrisch zur y-Achse.
Das ist für ihn nicht "gerechnet".

Das ist ja nichtmal "unschön", sondern ganz klar der Fehler des Lehrers, der nicht weiß, dass man Allaussagen im Allgemeinen durch Gegenbeispiele widerlegt. (Im Übrigen hätte man jetzt bei x^3=-x3 auch noch ein Gegenbeispiel angeben müssen, also ist die ganze Rechnerei für die Katz.)

Aber wie wärs, wenn wir beim Thema blieben?

illuminator

Sowas ist immer ein Problem der Auifgabenstellung. Wenn eine Lösung laut Aufgabenstellung korrekt ist gibt es volle Punkte, fertig.
Ich hab mich als Schüler über wenig Sachen mehr aufgeregt als über unklare und missverständliche Aufgabenstellungen.

Ist dann immer wie ein Überraschungsei was man für eine Note bekommt.
Wenn man dann als Lehrer willkürlich von seinen Schülern verlangt sich zu denken was der Lehrer sich denkt, was er gemeint aber nicht geschrieben hat, hört es auf.

Und so Aktionen können echt die Motivation vieler Schüler _sehr_ negativ beinflussen. Hab ich mehrfach miterlebt.

Mit meinem Informatiklehrer in der 11 bis 13 hatte ich deswegen mehrmals Probleme.

Als Lehrer sollte man solche Gelegenheiten Nutzen aus den Fehlern zu lernen und das nächste Mal klarere Aufgabenstellungen zu verfassen.

volkard

Michael E. schrieb:

Samyboy schrieb:

Nunja mein Lehrer hat das getan

Ich nehme an, dass du noch in der Schule bist. In der Schule haben unschöne Lösungen in Mathe meist die Eigenschaft, dass sie unsauber sind, d. h. nicht alle Fälle zufriedenstellend abdecken. Dann kann man durchaus was abziehen.

Dann nehme ich das auch als Anker. Wenn die Lösung nicht alle gefragten Fälle abdeckt, gibts Abzug. Allerdings muß man dazu den Code auch durchlesen und durchdenken, was mehr Arbeit ist, als auf Stil zu achten.

asc

illuminator schrieb:

Ich hab mich als Schüler über wenig Sachen mehr aufgeregt als über unklare und missverständliche Aufgabenstellungen.

Wobei mit Sicherheit im Unterricht ein ähnlicher Lösungsweg gezeigt wurde. Ich gebe dir aber Recht, das viele Aufgabenstellungen zu Wünschen übrig lassen. In einigen Fällen war bei uns der Lehrer dann aber auch so konsequent das er jede Lösung, die zum vorher gelehrten passt, akzeptiert hat [Und um auf das Beispiel einzugehen hat bei uns hat der Dozent auch erwähnt was er von goto hält, und das kenne ich auch so aus einem Schulunterricht - Und dann muss er es imho nicht mehr in eine Aufgabenstellung schreiben].

illuminator schrieb:

Und so Aktionen können echt die Motivation vieler Schüler _sehr_ negativ beinflussen. Hab ich mehrfach miterlebt.

Ich habe aber auch miterlebt wie Viele, in wirklich klar geschriebenen Sätzen, einiges hinein interpretieren, das definitiv dort nicht stand.

illuminator schrieb:

Als Lehrer sollte man solche Gelegenheiten Nutzen aus den Fehlern zu lernen und das nächste Mal klarere Aufgabenstellungen zu verfassen.

Wobei klar verständlich nicht unbedingt eindeutig ist*. Wenn man z.B. als Student darauf beharrt das eine verkettete Liste (die in der Aufgabenstellung gefordert war) in dem Aufgabenumfeld ja auch durch ein normales Array ersetzt werden kann, habe ich auch kein Verständnis damit. Und jeder Text lässt sich uminterpretieren, wenn man es nur stark genug versucht.

* das gilt aber auch im wahren Leben, und es ist auch leicht dort Probleme zu bekommen. Und am schönsten ist es wenn man eine komplexe Aufgabe bekommt (Auf deren Umsetzung andere Unternehmen etliche Mannjahre investiert haben), diese mit genau einem Satz umrissen ist "Schreibe eine Projektverwaltung im Stil von MS Projekt", und als Zeithorizont dir 2-3 Wochen gegeben werden.

Bashar schrieb:

Das folgende goto finden schließlich alle Leute gut:

Das ist ja auch keins.

Sicherlich ist das eins. Und zwar sogar eins, das über Funktionsgrenzen springt. Die catch-Anweisung ist dabei die Sprungmarke.

asc schrieb:

Ich persönlich kenne kaum eine Sprache wo ein goto wirklich sinnvoll ist

Gotos lassen sich immer vermeiden, aber manchmal sind sie die einfachste und naheliegendste Lösung. Demnach sind gotos nicht grundsätzlich sinnlos oder "böse", wenn man sie mit Bedacht einsetzt.

Doch nun zum Thema: Ich würde einen Punkt abziehen, wenn jemand gotos verwendet, wo gewöhnliche Kontrollstrukturen ausreichend sind. Keinen Punkt abziehen würde ich, wenn jemand goto verwendet, um aus einer tiefen Verschachtelung rauszuspringen oder nach einem Fehler zum Cleanup/Exit-Code verzweigt (Ein Beispiel hat DEvent schon gegeben).

SeppJ

Vorausgesetzt dass es sich um die böse Art von goto handelt UND es keine karriereentscheidende Prüfung ist (was in der Schule wohl der Fall ist): Ich würde Punkte für schlechten Stil abziehen. Auf die Weise lernt der Schüler sehr effektiv, mit gutem Stil zu programmieren. Und ist sicherlich sehr viel besser für ihn, als in irgendeiner unbedeutenden Klausur ein paar Punkte mehr zu bekommen.

Und auch in einer wichtigen Prüfung hätte ich keine Skrupel, Punkte für schlampige Erfüllung der Aufgabe abzuziehen. Wenn der Prüfer die Lösung nicht mehr nachvollziehen kann, ist die Aufgabe falsch gelöst. Ein einzelnes goto reicht dafür noch nicht aus, aber ein richtiger Spagetthicode schon.

Marc++us

Naja, das Spiel kann man ja weitertreiben.

Nehmen wir an, jemand programmiert das, aber macht die Fehlerbehandlung dadurch, daß er überall mit einem Flag weitergeht um aus Schleifenverschachtelung rauszukommen.

Und einer anderer springt mit goto raus auf eine Fehlermarke.

Was ist jetzt schlechter Stil?

Marc++us schrieb:

Naja, das Spiel kann man ja weitertreiben.
Nehmen wir an, jemand programmiert das, aber macht die Fehlerbehandlung dadurch, daß er überall mit einem Flag weitergeht um aus Schleifenverschachtelung rauszukommen.
Und einer anderer springt mit goto raus auf eine Fehlermarke.
Was ist jetzt schlechter Stil?

Für mich programmiert der mit dem Flag in schlechtem Stil. Umständlicher Code, nur um ein goto zu vermeiden, ist schlechter Stil.

Bashar

Z schrieb:

Bashar schrieb:

Das folgende goto finden schließlich alle Leute gut:

Das ist ja auch keins.

Sicherlich ist das eins. Und zwar sogar eins, das über Funktionsgrenzen springt. Die catch-Anweisung ist dabei die Sprungmarke.

Was heißt hier "sogar"? Mit try...catch kannst du nur sehr eingeschränkt springen, immer nur vom throw nach außen zu einem dynamisch(!) umschließenden catch. goto-Labels können so gut wie beliebig platziert werden. Gerade das ist das Problem an goto, weshalb diese populären Gleichsetzungen von goto mit return, break oder sonstigen Sprüngen völlig am Thema vorbeigehen.

rüdiger

DEvent schrieb:

void main() {
 ....

Für das void main würde ich aber Punkte abziehen.

Bashar schrieb:

Mit try...catch kannst du nur sehr eingeschränkt springen, immer nur vom throw nach außen zu einem dynamisch(!) umschließenden catch.

Es ist kein "goto zu fester Sprungmarke" sondern ein "goto zu mehreren Sprungmarken", ein 1-zu-n goto. Ich würde es nicht als sehr eingeschränkt bezeichnen.

Bashar schrieb:

goto-Labels können so gut wie beliebig platziert werden.

Nein. Du kannst nicht aus Funktionen hinausspringen.

Bashar schrieb:

Gerade das ist das Problem an goto, weshalb diese populären Gleichsetzungen von goto mit return, break oder sonstigen Sprüngen völlig am Thema vorbeigehen.

Aber switch/case entspricht in BASIC dem "ON x GOTO ...". Genauso wie break ein goto ohne explizite Sprungmarke ist. Es gibt schon einige versteckte gotos, wir nennen sie nur anders und deshalb finden wir nicht, dass sie böse sind.

Nexus

Z schrieb:

Sicherlich ist das eins. Und zwar sogar eins, das über Funktionsgrenzen springt. Die catch-Anweisung ist dabei die Sprungmarke.

So kann man aber nicht argumentieren. Dann müsste man alle Schleifen und Funktionsaufrufe ebenfalls als goto zählen. Den Unterschied zwischen goto und verstecktem Sprung musst du schon sehen.

asc

Z schrieb:

Bashar schrieb:

Mit try...catch kannst du nur sehr eingeschränkt springen, immer nur vom throw nach außen zu einem dynamisch(!) umschließenden catch.

Es ist kein "goto zu fester Sprungmarke" sondern ein "goto zu mehreren Sprungmarken", ein 1-zu-n goto. Ich würde es nicht als sehr eingeschränkt bezeichnen.

Es gibt mindestens eine sehr wichtige Unterscheidung zu einem goto: Man kann nur in eine Richtung "springen", und nicht kreuz und quer durch den Programmfluß hüpfen. Exceptions habe einen klaren Ablauf, ebenso wie Schleifen, nicht aber wie ein goto-Befehl.

volkard

Würde das behoben sein, wenn man sich darauf beschränken würde, mit goto nur abwärts zu springen und nie in blöcke reinzuspringen?

Shade Of Mine

asc schrieb:

Es gibt mindestens eine sehr wichtige Unterscheidung zu einem goto: Man kann nur in eine Richtung "springen", und nicht kreuz und quer durch den Programmfluß hüpfen. Exceptions habe einen klaren Ablauf, ebenso wie Schleifen, nicht aber wie ein goto-Befehl.

bei einem goto weiss ich immer genau wo es hin springt (ich sehe das label ja direkt am bildschirm) aber wo eine exception gefangen wird, das weiss ich nicht, das kann ich garnicht wissen. ich muss annehmen dass sie korrekt gefangen wird.

dass goto schlecht ist, stammt aus einer anderen zeit. es gibt ja immer mehr goto-ersatz. zB ein break das 2 schleifen breakt und nicht nur eine, exceptions und natürlich returns (früher hatte man ja single entry/single exit). also wo ist das problem wenn man goto verwendet?

das problem ist dann nicht goto sondern spaghetti code...

Nexus schrieb:

Z schrieb:

Sicherlich ist das eins. Und zwar sogar eins, das über Funktionsgrenzen springt. Die catch-Anweisung ist dabei die Sprungmarke.

So kann man aber nicht argumentieren. Dann müsste man alle Schleifen und Funktionsaufrufe ebenfalls als goto zählen. Den Unterschied zwischen goto und verstecktem Sprung musst du schon sehen.

Ja, das stimmt. Funktionsaufrufe sind gotos mit automatischem Rücksprung, Schleifen sind wiederholte gotos mit Abbruchbedingung. Insgesamt sind sie alle mit zusätzlicher Funktionalität versehene gotos, damit wir das echte goto nicht benutzen müssen.

asc schrieb:

Es gibt mindestens eine sehr wichtige Unterscheidung zu einem goto: Man kann nur in eine Richtung "springen", und nicht kreuz und quer durch den Programmfluß hüpfen. Exceptions habe einen klaren Ablauf, ebenso wie Schleifen, nicht aber wie ein goto-Befehl.

Das Verhalten eines gotos ist auch eindeutig, es heisst "Springe von hier bis dort", nicht in die andere Richtung, denn dazu bräuchte man ein weiteres goto.

Shade Of Mine schrieb:

das problem ist dann nicht goto sondern spaghetti code...

Vollkommen korrekt. Und Spaghetticode bekommt man auch ohne goto hin.