Έλεγχοι περιττών συνθηκών στη δομή ΑΝ

Ξεκίνησε από Wizard, 14 Οκτ 2008, 05:30:47 ΜΜ

« προηγούμενο - επόμενο »

bagelis

Παράθεση από: evry στις 16 Οκτ 2008, 02:17:36 ΜΜ

Θα έκοβα όμως με το σκεπτικό ότι ο μαθητής δεν κάνει σωστή χρήση της Αλλιώς_Αν. Αν ήταν από την αρχή να κάνει τόσους περιττούς ελέγχους γιατί να μην χρησιμοποιήσει 4 ξεχωριστές απλές Αν? Αυτό δεν θα ήταν πιο απλό? Είναι φανερό λοιπόν ότι δεν έχει καταλάβει τον λόγο ύπαρξης της δομής πολλαπλής επιλογής, που είναι ένας από τους διδακτικούς στόχους του μαθήματος και για αυτό δεν πρέπει να πάρει άριστα στο συγκεκριμένο θέμα.


Διαφωνώ με το παραπάνω επιχείρημα διότι διακυβεύεται κάτι πολύ σημαντικό: η αντικειμενικότητα της βαθμολόγησης.
Δεν είναι αρμοδιότητα του διορθωτή να "ανακαλύψει" τι έχει καταλάβει και τι δεν έχει καταλάβει ο μαθητής. Η ευθύνη του διορθωτή είναι να διορθώσει ότι λανθασμένο υπάρχει και να αφαιρέσει αντίστοιχες μονάδες. ΤΙΠΟΤΑ ΑΛΛΟ.

Είναι αρμοδιότητα του θεματοδότη να αποφασίσει ότι θέλει να ελέγξει τον διδακτικό στόχο "μη χρήση περιττών συνθηκών". Σε αυτή τη περίπτωση κάλιστα μπορεί να βάλει ένα θέμα σαν το θέμα 1 των επαναληπτικών που αναφέρθηκαν.

pgrontas

Στο συγκεκριμένο θέμα δεν νομίζω ότι μπορούμε να αποφανθούμε γενικά.
Αφενός συμφωνώ με τον evry ότι μια περιττή λογική συνθήκη σε κάποιον έλεγχο ίσως είναι ένδειξη ότι ο μαθητής δεν έχει καταλάβει κάτι στην δομή επιλογής που χρησιμοποιεί.
Από την άλλη διαφωνώ γιατί δεν μπορούμε να αποκλείσουμε το γεγονός ότι ο μαθητής (η γενικότερα ο συγγραφέας του αλγορίθμου) την έχει βάλει για να δώσει έμφαση στο τμήμα κώδικα που θα εκτελεστεί σε περίπτωση που ο έλεγχος είναι επιτυχής λχ.
Στο παράδειγμα δηλαδή:
ΑΝ Χ < 0 ΤΟΤΕ
   ΓΡΑΨΕ 'ΑΡΝΗΤΙΚΟΣ'
ΑΛΛΙΩΣ_ΑΝ Χ>=0 ΚΑΙ Χ<10 ΤΟΤΕ
   ΓΡΑΨΕ 'ΜΟΝΑΔΕΣ'
ΑΛΛΙΩΣ_ΑΝ Χ>=10 ΚΑΙ Χ<100 ΤΟΤΕ
   ΓΡΑΨΕ 'ΔΕΚΑΔΕΣ'
ΑΛΛΙΩΣ_ΑΝ Χ>=100
   ΓΡΑΨΕ 'ΜΕΓΑΛΟΣ ΑΡΙΘΜΟΣ'
ΤΕΛΟΣ_ΑΝ

μπορούμε να καταλάβουμε κάτι για την τιμή του Χ κοιτώντας αμέσως πάνω στην συνθήκη, χωρίς να χρειαστεί να ανατρέξουμε πολλές εντολές. Ο περιττός έλεγχος δηλαδή κάνει τον αλγόριθμο πιο ευανάγνωστο.

Βέβαια υπάρχει και η πρώτη συνιστώσα, της μη κατανόησης, οπότε το συμπέρασμα για μένα είναι ότι πρέπει να είμαστε πολύ προσεκτικοί στην στόχευση των ασκήσεων με τις οποίες θέλουμε να ελέγξουμε την κατανόηση των λογικών συνθηκών και των δομών επιλογής.
Programs must be written for people to read, and only incidentally for machines to execute - Harold Abelson

evry


Για να μην δημιουργούνται παρεξηγήσεις αυτά που είπα δεν ισχύουν αποκλειστικά για τις πανελλήνιες αλλά γενικότερα. Είναι προφανές πως οποιοδήποτε σχήμα βαθμολόγησης στις πανελλήνιες πρέπει να είναι προσυνενοημένο μεταξύ των βαθμολογητών ώστε να μην υφίστανται αδικίες.
   Επειδή όμως ο προγραμματισμός και η αλγοριθμική μπορούν να υπάρξουν και χωρίς τις πανελλήνιες (θέλω να πιστεύω) μιλάω γενικότερα για το πως θα βαθμολογούσα για παράδειγμα ένα τεστ στην τάξη.

Παράθεση από: bagelis στις 16 Οκτ 2008, 05:34:57 ΜΜ
Διαφωνώ με το παραπάνω επιχείρημα διότι διακυβεύεται κάτι πολύ σημαντικό: η αντικειμενικότητα της βαθμολόγησης.
Δεν είναι αρμοδιότητα του διορθωτή να "ανακαλύψει" τι έχει καταλάβει και τι δεν έχει καταλάβει ο μαθητής. Η ευθύνη του διορθωτή είναι να διορθώσει ότι λανθασμένο υπάρχει και να αφαιρέσει αντίστοιχες μονάδες. ΤΙΠΟΤΑ ΑΛΛΟ.
What I cannot create I do not understand -- Richard Feynman
http://evripides.mysch.gr

evry

Ένα λεπτό, μιλάμε για συγκεκριμένη γλώσσα προγραμματισμού ή για ψευδογλώσσα, γιατί και στην υπογραφή σου λες ότι

Το μάθημα ΑνάπτυξηΕφαρμογών δεν έχει σαν στόχο την εκμάθηση κάποιου συγκεκριμένου προγραμματιστικού περιβάλλοντος ούτε την καλλιέργεια προγραμματιστικών δεξιοτήτων από τη μεριά των μαθητών

με το οποίο συμφωνώ απόλυτα, άρα όσον αφορά την Pascal δεν δέχομαι το επιχείρημα, γιατί με το ίδιο σκεπτικό η αλλαγή του μετρητή του Για στις C, C++, Java είναι δεκτή άρα θα μπορούσα να το χρησιμοποιήσω και εγώ σαν επιχείρημα. Άρα αν μπλέξουμε με συγκεκριμένες γλώσσες δε νομίζω ότι θα βγάλουμε άκρη.
  Επίσης λες ότι το τετράδιο μαθητή αναφέρει καθαρά ότι καλό είναι τη Για να μην την χρησιμοποιούμε όπως την αναφέρεις. Επίσης συμφωνώ απόλυτα και εκεί ακριβώς είναι το πρόβλημα. Ότι ναι μεν δεν είναι καλό να χρησιμοποιούμε έτσι τη Για, είναι όμως λάθος?? αυτό δεν το λέει πουθενά, κάνει απλά μια σύσταση ότι είναι κακή πρακτική. ʼλλο όμως κακή πρακτική και άλλο λάθος.
  Όσον αφορά τώρα την παραβίαση των αρχών του δομημένου προγραμματισμού σε αυτό διαφωνώ κάθετα. Δεν παραβιάζει καμία μα καμία αρχή του δομημένου προγραμματισμού διότι πολύ απλά δεν ισοδυναμεί με εντολή goto. Αυτό ισχύει διότι όταν αλλάξει ο μετρητής θα εκτελεστούν οπωσδήποτε οι εντολές μετά την αλλαγή και στη συνέχεια θα επιστρέψει στην αρχή της επανάληψης. Όπως ακριβώς και με την Όσο. Για αυτό δίνω το παρακάτω παράδειγμα

Κώδικας: ΓΛΩΣΣΑ
ΓΙΑ i ΑΠΟ 1 ΜΕΧΡΙ 100
   ΔΙΑΒΑΣΕ Χ
   ΑΝ Χ = 0 ΤΟΤΕ
       i <-- 101
   ΤΕΛΟΣ_ΑΝ
   ΓΡΑΨΕ 'ΘΑ ΕΚΤΕΛΕΣΤΩ ΟΤΙ ΚΑΙ ΝΑ ΓΙΝΕΙ'
ΤΕΛΟΣ_ΕΠΑΝΑΛΗΨΗΣ


όπου η Γράψε θα εκτελεστεί ότι και να γίνει δεν πρόκειται να παραληφθεί όπως θα συνέβαινε για παράδειγμα αν είχαμε μια break ή μια continue ή μια goto.

Παράθεση από: ntzios kostas στις 16 Οκτ 2008, 04:40:07 ΜΜ
Φίλε evry το τετράδιο μαθητή αναφέρει καθαρά ότι καλό είναι τη Για να μην την χρησιμοποιούμε όπως την αναφέρεις. Τρέξε, λοιπόν, αυτό που λες στην Pascal για να δεις τι πρόβλημα έχει.  

s:=0
for i:=1 to 10 do begin
   read(x);
   s:=s+x;
   if s>10 then
       i:=11;
end

Το παράδειγμά σου νομίζω εκτός του ότι είναι επικινδυνο γιατί βγάζει λάθος αποτελέσματα σε μερικές γλώσσες, χαλάει και την έννοια του δομημένου προγραμματισμού. Αυτό είναι κάτι αντίστοιχο με το πήγαινε.  Η περιττή συνθήκη δεν χαλάει τις αρχές του δομημένου προγραμματισμού.

Φιλίκα Κώστας Ντζιός
What I cannot create I do not understand -- Richard Feynman
http://evripides.mysch.gr

bagelis

Παράθεση από: evry στις 16 Οκτ 2008, 11:36:51 ΜΜ

Για να μην δημιουργούνται παρεξηγήσεις αυτά που είπα δεν ισχύουν αποκλειστικά για τις πανελλήνιες αλλά γενικότερα. Είναι προφανές πως οποιοδήποτε σχήμα βαθμολόγησης στις πανελλήνιες πρέπει να είναι προσυνενοημένο μεταξύ των βαθμολογητών ώστε να μην υφίστανται αδικίες.
Φίλε evry συγνώμη αν επιμένω αλλά το θεωρώ πολύ σημαντικό σημείο:
Οποιοδήποτε σχήμα βαθμολόγησης θα έπρεπε να είναι γνωστό εκ των προτέρων.

Από την στιγμή λοιπόν που εγώ σαν καθηγητής δεν έχω σαφή απάντηση ότι οι περιττές συνθήκες κόβουν (και φαντάζομαι ότι σε αυτό το σημείο συμφωνούμε όλοι εδώ μέσα) δεν δέχομαι να με αιφνιδιάσουν οι διορθωτές και να μου κόψουν. Σε κάθε περίπτωση που κάτι είναι διφορούμενο μέχρι να διασαφηνιστεί πλήρως δεν μπορεί να αποτελεί αιτία αφαίρεσης έστω και 0.1 μορίου.

Από την άλλη μεριά αν εγώ σαν καθηγητής μέσα στην τάξη έχω αναφέρει ρητά ότι: "προσέξτε τις περιττές συνθήκες, είναι λάθος και θα χάσετε μόρια" έχω κάθε δικαίωμα σε τεστ να κόψω, γιατί έχω ήδη προκαθορίσει τους κανόνες βαθμολόγησης, οι οποίοι είναι γνωστοί σε όλους.


ntzios kostas

Το βιβλίο αναφέρει ότι η αλλάγη του μετρητή μπορεί να δημιουργήσει προβλήματα. Και πράγματι στη γλώσσα Pascal είναι δεκτή η αλλαγή του μετρητή αλλά τα δύο παραδείγματα που φέρνεις δεν έχουν περατότητα. Τώρα στη C, C++ και Java ξέρεις πολύ καλά ότι η λογική του Για είναι τελείως διαφορετική.  Ακόμα όμως και στη C δεν είναι προγραμματιστικά σωστό κατά την γνώμη μου να χρησιμοποιώ την for να έχω γράψει τις προυποθέσεις για τον τερματισμό της στην πρώτη της γραμμή και αυτή να τερματίζει για άσχετο λόγο.   Ακόμα και την όσο να χρησιμοποιείς στη ΓΛΩΣΣΑ και να τερματίζεις έτσι βιαία την επανάληψη για εμένα δεν είναι σωστός προγραμματισμός, αφού μπορείς και αυτό το λόγο τερματισμού να το βάλεις με κάποιον τρόπο στην συνθήκη της όσο.  Στα παραδείγματα που βάζεις για τερματισμό φαίνεται ότι υπεύθυνος είναι το ι και τελικά είναι και το χ. Αυτό πρέπει να φαίνεται στην συνθήκη.

Αυτά που αναφέρω δεν νομίζω ότι ειναι εκτός από τους στόχους του μαθήματος, γιατί πραγματικά δεν θέλω και εσύ πιστεύω δεν θέλεις και το μάθημα το ίδιο δεν θέλει να διδάσκουμε ένα τέτοιο είδος προγραμματισμού.

Eίναι μεγάλη κουβέντα αν ικανοποιεί ή όχι τις αρχές του δομημένου προγραματισμού και κακός το ανέφερα εδώ.   


Για τις περιττές συνθήκες στα πλαίσια του μαθήματος τις θεωρούμε σωστές. Εδώ θεωρούμε σωστές τις περιττές επαναλήψεις που μπορεί να είναι και χιλιάδες παραπάνω απ' ότι πρέπει (θέλει ο μαθητής να βρει το μέγιστο του πίνακα και αυτός τον ταξινομεί για να εμφανίσει το πρώτο του στοιχείο) και αναρωτιόμαστε τι γίνεται για μία παραπάνω συνθήκη;
Το μάθημα Ανάπτυξη Εφαρμογών δεν έχει σαν στόχο την εκμάθηση κάποιου συγκεκριμένου προγραμματιστικού περιβάλλοντος ούτε την καλλιέργεια προγραμματιστικών δεξιοτήτων από τη μεριά των μαθητών. Δεν αποσκοπεί στη λεπτομερειακή εξέταση της δομής, του ρεπερτορίου και των συντακτικων κανόνων κάποιας γλώσσας...

pgrontas

Σχετικά με την αλλαγή μετρητή: Είναι σαφές ότι από μόνη της δεν πρόκειται ούτε για λογικό ούτε για συντακτικό λάθος. Είναι καθαρά μια σύσταση.
Σχετικά με τον πρόωρο τερματισμό της for στις γλώσσες C κτλ. νομίζω ότι ο κώδικας που προκύπτει είναι πολύ πιο απλός με χρήση break (ισοδύναμη με αλλαγή μετρητή) παρά με την ύπαρξη μιας πολύπλοκης λογικής συνθήκης.
Οι αλγόριθμοι δεν έχουν αξία μόνο από την πλευρά του υπολογισμού αλλά και ως τεκμηρίωση για την λύση ενός προβλήματος. Και για τον λόγο αυτό πρέπει να είναι απλοί και ευανάγνωστοι.
Programs must be written for people to read, and only incidentally for machines to execute - Harold Abelson

ntzios kostas

Ένα break μπορείς εύκολα να το αντικαταστήσεις με μία μεταβλητή που θα βρίσκεται στην συνθήκη της επανάληψης και θα αλλάζει κατάσταση εκεί που θέλεις να βάλεις το break. To break είναι ακριβώς το GOTO με λιγότερες δυνατότητες γιατί απλά σε πάει μετά την επανάληψη.
Όταν κάνουμε ένα σχεδιασμό του προβλήματος και λέμε ότι θα χρησιμοποιήσουμε για παράδειγμα την δομή όσο, στο σχεδιασμό πάνω πρέπει να βρούμε τι πρέπει να ισχύει για να τερματίσει ή να συνεχίζεται η επανάληψη. Όταν κάποιος λοιπόν διαβάσει αυτή τη λύση, κατά την οποία η δομή όσο μπορεί να αποτελείται από πολλές εντολές, θα καταλάβει αμέσως τι πρέπει να ισχύει για να τερματίσει η επανάληψη. Η ύπαρξη των break σε διάφορα σημεία κάνει τον κώδικα αρκετά δυσνόητο.
Επίσης βλέποντας μία δομή επανάληψης με μετρητή, για παράδειγμα την για χ από 1 μέχρι 100 ξέρω αμέσως ότι θα κάνει 100 επαναλήψεις. Αυτός είναι και ο ρόλος της. Δεν θέλω να κοιτάξω όλες τις γραμμές του κώδικα για να δω μήπως υπάρχει και κάτι άλλο που θα μου χαλάσει την επανάληψη.
Το μάθημα Ανάπτυξη Εφαρμογών δεν έχει σαν στόχο την εκμάθηση κάποιου συγκεκριμένου προγραμματιστικού περιβάλλοντος ούτε την καλλιέργεια προγραμματιστικών δεξιοτήτων από τη μεριά των μαθητών. Δεν αποσκοπεί στη λεπτομερειακή εξέταση της δομής, του ρεπερτορίου και των συντακτικων κανόνων κάποιας γλώσσας...

sstergou

Παράθεση από: ntzios kostas στις 17 Οκτ 2008, 01:01:14 ΜΜ
Η ύπαρξη των break σε διάφορα σημεία κάνει τον κώδικα αρκετά δυσνόητο.

Συμφωνώ σε γενικές γραμμές αλλά αυτό δεν ισχύει πάντα. Σε μερικές περιπτώσεις τα άλματα στον κώδικα είναι απαραίτητα. Όλες οι σύγχρονες γλώσσες προγραμματισμού έχουν μηχανισμούς διαχείρισης εξαιρέσεων οι οποίες χειρίζονται την ροή του προγράμματος με τρόπο παρόμοιο με την GOTO. Οι μηχανισμοί εξαιρέσεων έχουν σημαντικά πλεονεκτήματα έναντι των παραδοσιακών μεθόδων όπου κάθε εντολή πρέπει να ελέγχεται για το αν παρήγαγε το κατάλληλο αποτέλεσμα. Ένα από αυτά είναι ότι κάνουν τον κώδικα περισσότερο κατανοητό.

evry

Παράθεση από: ntzios kostas στις 17 Οκτ 2008, 09:00:05 ΠΜ
τα δύο παραδείγματα που φέρνεις δεν έχουν περατότητα.

Δεν κατάλαβα γιατί τα παραδείγματα που έφερα δεν έχουν περατότητα. Αφού θα εκτελεστούν το πολύ 100 φορές. Ότι και να γίνει δεν θα εκτελεστούν παραπάνω. Για την ακρίβεια το παρακάτω κομμάτι κώδικα που έδωσα

Κώδικας: ΓΛΩΣΣΑ
ΓΙΑ i ΑΠΟ 1 ΜΕΧΡΙ 100
   ΔΙΑΒΑΣΕ Χ
   ΑΝ Χ = 0 ΤΟΤΕ
       i <-- 101
   ΤΕΛΟΣ_ΑΝ
   ΓΡΑΨΕ 'ΘΑ ΕΚΤΕΛΕΣΤΩ ΟΤΙ ΚΑΙ ΝΑ ΓΙΝΕΙ'
ΤΕΛΟΣ_ΕΠΑΝΑΛΗΨΗΣ


δεν ισοδυναμεί με το επόμενο σε Όσο? Οι ίδιες επαναλήψεις δεν θα εκτελεστούν? Η μόνη διαφορά είναι ότι στο παρακάτω μπορεί να τελειώσει η επανάληψη και το i να μην έχει πάρει την τιμή 101. Αλλά ουσιαστικά και τα 2 την ίδια δουλειά δεν κάνουν?

Κώδικας: ΓΛΩΣΣΑ
ΔΙΑΒΑΣΕ Χ
i <- 1
ΟΣΟ i<=100 ΚΑΙ Χ<>0 ΕΠΑΝΑΛΑΒΕ
   ΔΙΑΒΑΣΕ Χ
   ΓΡΑΨΕ 'ΘΑ ΕΚΤΕΛΕΣΤΩ ΟΤΙ ΚΑΙ ΝΑ ΓΙΝΕΙ'
   i <- i + 1
ΤΕΛΟΣ_ΕΠΑΝΑΛΗΨΗΣ


   Παιδιά δεν είπα σε καμία περίπτωση ότι η αλλαγή του μετρητή του Για είναι καλή πρακτική ή ότι θα πρέπει να ωθήσουμε τους μαθητές σε κάτι τέτοιο. Σε αυτό προφανώς συμφωνούμε όλοι. Αυτό που λέω είναι ότι δεν ξέρω κατά πόσο μπορούμε να το θεωρήσουμε λάθος. Δηλαδή αν κάποιος μαθητής δώσει έναν σωστό αλγόριθμο και μέσα στη Για αλλάζει τον μετρητή κατά πόσο θα του κόψουμε μονάδες. Ποιος είναι ο λόγος δηλαδή? ποιο λάθος έχει κάνει? Ναι οκ είναι κακή πρακτική και κακώς χρησιμοποιεί τη Για. Το ίδιο όμως ισχύει και για τον μαθητή που χρησιμοποιεί την Αλλιώς_Αν και βάζει περιττές συνθήκες. Και οι 2 χρησιμοποιούν δυο αλγοριθμικές δομές με "λάθος" τρόπο. Όμως ο αλγόριθμος που έχουν δώσει δεν έχει πουθενά λάθος. Είναι ολόσωστος, πληροί όλα τα κριτήρια και εφόσον η φιλοσοφία μας είναι πως ότι τρέχει (δουλεύει) και βγάζει σωστό αποτέλεσμα είναι σωστό, δεν ξέρω κατά πόσο έχουμε δικαίωμα να του κόψουμε.
    Το σκεπτικό μου είναι πάντα να εξηγώ στους μαθητές μου γιατί έχουν κάνει λάθος. Δεν μου αρέσει να δίνω απαντήσεις του στυλ "έτσι το λέει στο βιβλίο" ή "επειδή έτσι είναι" ή  "εξ'ορισμού" γιατί δεν πρόκειται να τους πείσω έτσι.
  Απλά πιστεύω ότι η αντιμετώπιση και στις 2 περιπτώσεις πρέπει να είναι η ίδια, δηλαδή ή κόβουμε από αυτό που θεωρείται κακή πρακτική ή όχι.
What I cannot create I do not understand -- Richard Feynman
http://evripides.mysch.gr

P.Tsiotakis

Παράθεση από: pgrontas στις 17 Οκτ 2008, 09:16:22 ΠΜ
Σχετικά με την αλλαγή μετρητή: Είναι σαφές ότι από μόνη της δεν πρόκειται ούτε για λογικό ούτε για συντακτικό λάθος.

Πρόκειται σίγουρα όμως για λάθος χρήση της δομής Για απο πλευράς του μαθητή και κατά πάσα πιθανότητα για λανθασμένη διδασκαλία της απο τους καθηγητές του.

evry

Προφανώς πρόκειται για λάθος χρήση της Για, αλλά δε νομίζω ότι υπάρχει κάποιος καθηγητής  που να διδάσκει κάτι τέτοιο. Αντιθέτως υπάρχουν πολλοί μαθητές που αλλάζουν τον μετρητή μέσα στη Για. Αυτό μου έχει συμβεί όταν ξεκινάω πρώτα με τη Για και μετά με την Όσο. Σε αυτή την περίπτωση σαν καθηγητής δεν έχεις κανένα απολύτως επιστημονικό επιχείρημα για να πείσεις τον μαθητή ότι αυτό που κάνει είναι λάθος.

Παράθεση από: Τσιωτάκης Παναγιώτης στις 17 Οκτ 2008, 07:25:01 ΜΜ

Πρόκειται σίγουρα όμως για λάθος χρήση της δομής Για απο πλευράς του μαθητή και κατά πάσα πιθανότητα για λανθασμένη διδασκαλία της απο τους καθηγητές του.
What I cannot create I do not understand -- Richard Feynman
http://evripides.mysch.gr

pgrontas

Παράθεση από: Τσιωτάκης Παναγιώτης στις 17 Οκτ 2008, 07:25:01 ΜΜ
Πρόκειται σίγουρα όμως για λάθος χρήση της δομής Για απο πλευράς του μαθητή και κατά πάσα πιθανότητα για λανθασμένη διδασκαλία της απο τους καθηγητές του.

Παναγιώτη έχεις δίκιο και κανείς δεν το διδάσκει αυτό. Όπως λέει και ο evry όμως αν το δεις σε άσκηση/γραπτό πώς θα το βαθμολογήσεις; Εγώ νομίζω ότι ο μαθητής που θα κάνει κάτι τέτοιο ή θα είναι εντελώς άσχετος (οπότε η βαθμολόγηση δεν θα κριθεί στο συγκεκριμένο σημείο) ή θα έχει βρει μια πρωτότυπη και έξυπνη λύση. Και τότε δεν θα μπορώ να τεκμηριώσω την απώλεια βαθμών.

Παράθεση από: ntzios kostas στις 17 Οκτ 2008, 01:01:14 ΜΜ
Ένα break μπορείς εύκολα να το αντικαταστήσεις με μία μεταβλητή που θα βρίσκεται στην συνθήκη της επανάληψης και θα αλλάζει κατάσταση εκεί που θέλεις να βάλεις το break. To break είναι ακριβώς το GOTO με λιγότερες δυνατότητες γιατί απλά σε πάει μετά την επανάληψη.

Σύμφωνοι αλλά τότε και για πολλές break θα καταληξεις σε λογική συνθήκη σιδηρόδρομο. Ίσως να είναι και θέμα στυλ αλλά εγώ προτιμώ την τοπικότητα να μην χρειάζεται δηλαδή να ψάχνεις μακριά και σε σύνθετες συνθήκες, ακόμα και αν αυτό δεν ακολουθεί ευλαβικά τις συστάσεις κάποιου πλαίσιου αναφοράς όπως ο δομημένος προγραμματισμός.
Programs must be written for people to read, and only incidentally for machines to execute - Harold Abelson

tsak

Έχω εκφράσει στο παρελθόν την εκτίμησή μου για την ύπαρξη αυτού του forum γιατί συζυτώνται διάφοροι προβληματισμοί πάνω στο μάθημα του προγραμματισμού με σοβαρότητα και μεράκι. Πολλές φορές όμως νομίζω ότι η ανάλυση ενός θέματος ξεφεύγει κατά πολύ, αναλογιζόμενος και τους στόχους που προσπαθούμε να εκπληρώσουμε στο μάθημα κατά τη διάρκεια των 9 περίπου μηνών που το διδάσκουμε.
Πάντως σχετικά με το "κόβουμε" ή "δεν κόβουμε" μονάδες για το α ή β θέμα, έχω μεταφέρει ανοιχτά την ανησυχία μου στους μαθητές μου για το ποιοι βαθμολογούν και με ποια κριτήρια βαθμολογούν οι εξεταστές στις εξετάσεις...

Καρκαμάνης Γεώργιος

Για το εάν κόβονται ή όχι μονάδες για τον έλεγχο περιττών συνθηκών θα παραθέσω δύο παραδείγματα που συνέβησαν σε δυο διαφορετικά έτη βαθμολόγησης των πανελληνίων:

Κατά το έτος 2006 στο 3ο θέμα στην υλοποίηση της συνάρτησης όπου έπρεπε να χρησιμοποιηθεί πολλαπλή επιλογή για την εύρεση των επιτηρητών, τότε ο συντονιστής του βαθμολογικού κέντρου κατά την ενημέρωση προ της βαθμολόγησης πρότεινε την αφαίρεση ενός μορίου (και συμφώνησαν όλοι οι συνάδερφοι )εαν υπήρχαν  περιττοί έλεγχοι μέσα στην αλλιώς_αν.

Στο ίδιο βαθμολογικό κέντρο το καλοκαίρι(έτος 2008) αποφασίστηκε να μην κόβονται μονάδες για περιττούς ελέγχους.........

Θέλω να θέσω ένα πρόβλημα που πιστεύω πως υπάρχει σχετικά με  την συνεννόηση και ενημέρωση των βαθμολογητών πριν από την έναρξη της βαθμολόγησης. Νομίζω ότι η ενημέρωση και η συνεννόηση για το πως θα βαθμολογηθούν τα θέματα(ώστε να υπάρχει μια κοινή γραμμή)γίνεται στα κατά τόπους βαθμολογικά κέντρα και όχι πανελληνίως μεταξύ όλων των βαθμολογικών όπως θα έπρεπε. Αυτό έχει σαν αποτέλεσμα το ίδιο θέμα να βαθμολογείτε με διαφορετικά κριτήρια από βαθμολογικό σε βαθμολογικό, γιαυτό και ποτέ δεν θα υπάρχει ταύτιση απόψεων σε θέματα βαθμολόγησης.
Βέβαια αυτό δεν ισχύει μόνο για ΑΕΠΠ.
Όπως υπάρχει η επιτροπή εξετάσεων που ορίζει τα θέματα, θα έπρεπε να υπήρχε αντίστοιχη επιτροπή που θα είχε προτείνει τον τρόπο βαθμολόγησης των θεμάτων και θα μοίραζε και οδηγίες για το πόσες μονάδες θα κόβονται ανα θέμα