Επιχειρήματα μέσα από τα σχολικά βιβλία υπέρ της χρήσης πίνακα στο Γ

Ξεκίνησε από bagelis, 29 Μαΐου 2010, 01:20:01 ΜΜ

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

alkisg

Παράθεση από: Βιβλίο καθηγητή, σελίδα 66
Από τις παραπάνω τρεις εναλλακτικές προτάσεις, η πλέον προφανής για το
μαθητή είναι η πρώτη. Άλλωστε είναι δυνατό μετά τον υπολογισμό του αποτελέ-
σματος y, να ακολουθεί η εντολή "Γράψε y". Επίσης αντί για τη γραμμή Δεδομένα,
να υπάρχει η εντολή "Διάβασε α, β, γ, δ". Ωστόσο χωρίς να απορρίπτουμε την
προσέγγιση αυτή, προτιμότερη είναι η τρίτη πρόταση για τους εξής λόγους:
I) Ο αλγόριθμος λύνει το πρόβλημα και δεν ασχολείται με τον τρόπο εισαγωγής
δεδομένων και παρουσίασης αποτελεσμάτων.
ΙΙ) Αν ο αλγόριθμος υλοποιηθεί ως υποπρόγραμμα ή συνάρτηση, τότε είναι προ-
τιμότερο να μην έχει εντολές εισόδου-εξόδου. Οι γραμμές Δεδομένα και Απο-
τελέσματα παραπέμπουν ακριβώς στο πέρασμα παραμέτρων στη διαδικα-
σία.


merlin

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

Η εντολή Δεδομένα, για μένα, δεν ισοδυναμεί με τη διάβασε, δεν ισοδυναμεί με το πέρασμα παραμέτρων σε υποπρόγραμμα, δεν ισοδυναμεί με εντολές εκχώρησης τιμής. Δεν είναι 1 προς 1 η σχέση.
Κάποιες φορές η εντολή Δεδομένα μπορεί να αντικατασταθεί με το διάβασε, κάποιες φορές με παραμέτρους σε υποπρόγραμμα κλπ.

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

Στις ασκήσεις που παρέθεσες θα σου αναφέρω τη χρήση της εντολής Δεδομένα για κάθε μια:
1) Δεδομένα //Μ1,Μ2// στον πολ/μό αλά Ρωσικά
       Τι θέλουμε να δείξουμε στο μαθητή? Τον τρόπο που θα λύσει το πρόβλημα, με δεδομένους 2 αριθμούς. Ναι, το Μ1 και το Μ2 μπορεί να είναι γνωστά από πριν, μπορεί και όχι. Εδώ μπορούμε να χρησιμοποιήσουμε εναλλακτικά και τη Διάβασε

2) Δεδομένα //a,b// στον αλγόριθμο της δύναμης
Εδώ πρέπει να γνωρίζουμε από πριν την τιμή του b για να "προετοιμάσουμε" τα κατάλληλα υλικά για τη λύση του προβλήματος. Μας έβαλε ο καθηγητής μας άσκηση για το σπίτι τον υπολογισμό του 4^56. Ξέρω ότι θα χρειαστώ το πολύ 56 γραμμές τετραδίου (πίνακας 56 θέσεων) για να αποθηκεύω προσωρινά κάποια δεδομένα (στην πραγματικότητα είναι πολύ λιγότερα αλλά με παίρνει να το παίζω large). Αλλάζει κάτι στην διαδικασία επίλυσης (αλγόριθμο) αν είναι 56 ή 76 ο εκθέτης? Τίποτα. Μπορώ να λύσω οποιοδήποτε ίδιο πρόβλημα, αρκεί να γνωρίζω τον εκθέτη ως δεδομένο.

Μπορώ να χρησιμοποιήσω εδώ τη διάβασε? Όχι!
Τί σημαίνει όμως αυτό? Ότι ο καθηγητής μου είπε (κακώς) ότι θα βάλει διαγώνισμα να υπολογίσω μια δύναμη με τον παραπάνω τρόπο, αλλά θα μάθω τον εκθέτη όταν δω τα θέματα!
Πόσα τετράδια (μέγεθος πίνακα) πρέπει να έχω μαζί μου για να είμαι καλυμμένος ότι θα μου φτάσουν για την επίλυση του προβλήματος?

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

Γενική παρατήρηση:
Θεωρείτε τυχαίο το γεγονός ότι σε όλες τις παραπάνω προτεινόμενες λύσεις το βιβλίο δεν χρησιμοποιεί την εντολή διάβασε? Δε νομίζω.

Συνεχίζω σε επόμενο ποστ για τη χρήση πίνακα σε υποπρογράμματα...
Παρασκευάς Πανάγου
Μηχανικός Η/Υ Συστημάτων
Καθηγητής Πληροφορικής ΠΕ20

merlin

...συνέχεια από το προηγούμενο.

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

Με ποιο μηχανισμό όμως γίνεται αυτό το πάρε - δώσε τιμών? Τι γνωρίζουν οι μαθητές? 1 κουτάκι (μεταβλητή) περιμένουμε να μας έρθει στο υποπρόγραμμα, 1 πρέπει να στείλουμε από το κυρίως πρόγραμμα. 100 περιμένουμε (με τη μορφή πίνακα), 100 πρέπει να στείλουμε.
Πότε το γνωρίζουμε αυτό? Κατά τη συγγραφή του.
Καταφεύγουμε λοιπόν σε εκφωνήσεις (όταν πραγματικά απαιτούνται πίνακες) του στυλ "θεωρήστε ότι έχουμε 100 εργαζόμενους ή έχουμε μέγιστο πλήθος 1000 κλπ". Παρόμοια προβλήματα αντιμετωπίζουμε για την δήλωση των πινάκων είτε το λύσουμε με πρόγραμμα είτε με υποπρόγραμμα.

Φυσικά εμείς σαν έμπειροι προγραμματιστές, θα θέλαμε τα υποπρογράμματά μας  (αλλά και τα προγράμματα) να είναι όσο το δυνατό πιο "γενικά" και να ταξινομούν για παράδειγμα ένα πίνακα "αόριστου" μεγέθους. Έχουμε όμως τις γνώσεις, τα εργαλεία (δυναμικές δομές, pointers, κλπ) για να υλοποιήσουμε πραγματικά "αυτόνομα" υποπρογράμματα. Οι μαθητές δεν μπορούν με τα μέσα που διαθέτουν. Είναι κακό?

Από τον παραπάνω συλλογισμό λοιπόν, εσείς καταλαβαίνετε ότι η εντολή Δεδομένα ισούται πάντα με τις παραμέτρους σε κάποιο υποπρόγραμμα?
Κάποιες φορές (π.χ. για τον πολλαπλασιασμό αλά ρωσικά) μπορούμε να αντιστοιχίσουμε το Δεδομένα // .... // με τις αντίστοιχες παραμέτρους.
Το ίδιο μπορούμε να κάνουμε για τους 100 εργαζόμενους. Όχι όμως για τον υπολογισμό της δύναμης.

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

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



Παρασκευάς Πανάγου
Μηχανικός Η/Υ Συστημάτων
Καθηγητής Πληροφορικής ΠΕ20

Νίκος Αδαμόπουλος

#228
Ας το πιάσω από αλλού: Ουσιαστικά το βιβλίο με την ψευδογλώσσα μιλάει σε «αλγοριθμικό επίπεδο» και με τη ΓΛΩΣΣΑ σε «προγραμματιστικό επίπεδο». Αυτό μπερδεύει καταρχάς τους συναδέλφους που προσπαθούν να τα συγχωνεύσουν όλα σε ένα επίπεδο, το οποίο θα τους άρεσε να το ονομάζουν αλγοριθμική, αλλά που στην ουσία είναι προγραμματισμός! 

Έτσι λοιπόν η ψευδογλώσσα είναι πολύ πιο χαλαρή... και μάλλον εσκεμμένα έχει μικροδιαφορές στη σύνταξή της (μονά-διπλά εισαγωγικά, πεζά-κεφαλαία, κόμμα-τελεία για υποδιαστολή, κλπ) και κυρίως στη λειτουργία της από τη ΓΛΩΣΣΑ. Θα έλεγα ότι κάποια που λέμε θεωρητικά ότι γίνονται σε αλγοριθμικό επίπεδο, δεν προκύπτουν στην πράξη στο προγραμματιστικό επίπεδο! Τα παραδείγματα είναι πολλά και σκέφτομαι να ανοίξω ειδικό θέμα στο Στέκι. Ενδεικτικά, μερικά:

Α) Η ψευδογλώσσα δεν κάνει διάκριση ακέραιων και πραγματικών και για αυτό και δεν είχε μέχρι πρόσφατα div και mod. Υπήρχαν βέβαια τρόποι να βρούμε το πηλίκο και το υπόλοιπο ακέραιας διαίρεσης (π.χ =[Μ/2], =Μ-[Μ/2]*2). Βέβαια αυτό δεν μας άρεσε και ουσιαστικά προκαλέσαμε την πρόσφατη σχετική διόρθωση του βιβλίου, το οποίο όμως απομακρύνθηκε από το αρχικό πνεύμα του.

Β)  Στη ΓΛΩΣΣΑ αναπόφευκτα έχουμε περιορισμούς στα μεγέθη των αριθμών. Έτσι, στην ψευδογλώσσα το παρακάτω λέμε ότι κάνει άπειρες επαναλήψεις.
  i <- 10000
  ΑΡΧΗ_ΕΠΑΝΑΛΗΨΗΣ
    i <- i* 2
    ΓΡΑΨΕ i
  ΜΕΧΡΙΣ_ΟΤΟΥ i <= 100

Στην ΓΛΩΣΣΑ όμως όχι! (στον Διερμηνευτή της ΓΛΩΣΣΑΣ το δοκίμασα και κάνει μόλις 50!!!).

Γ)  Ομοίως, στην ψευδογλώσσα το παρακάτω λέμε ότι δεν εμφανίζει τίποτα.
  b <- 1/ 1000000000
  ΑΝ b = 0.000000002 ΤΟΤΕ
    ΓΡΑΨΕ '*'                                           
  ΤΕΛΟΣ_ΑΝ

Στην ΓΛΩΣΣΑ όμως εμφανίζει το «*» ! (με τις default ρυθμίσεις του Διερμηνευτή).

Δ) Ομοίως το παράδειγμα με τον περιβόητο αλγόριθμο υπολογισμό του a^b. Στην ψευδογλώσσα είναι ΟΚ, όμως στην ΓΛΩΣΣΑ όχι! Εκτός κι αν το πετσοκόψουμε και μιλάμε π.χ. για α^53.

Ε) Έτσι, το θέμα 3 σε ψευδογλώσσα δεν έχει (κατ' εμέ) πρόβλημα με Διάβασε Ν και πίνακες, ενώ στη ΓΛΩΣΣΑ δεν γίνεται (βέβαια σε άλλες γλώσσες γίνεται!)

-------------

Σε σχέση με την εντολή Δεδομένα δεν μίλησε κανείς για «ισοδυναμία» ούτε καν για «1-1». Οι 3 εναλλακτικές που αναφέρω είναι για την περίπτωση που κάποιος πήγαινε να κάνει μετατροπή του αλγορίθμου σε πρόγραμμα σε κάποια γλώσσα προγραμματισμού. Το γεγονός ότι δεν είναι εφικτές πάντα όλες αυτές οι μετατροπές σε ΓΛΩΣΣΑ, και εξετάζεις με διαφορετικό τρόπο μία μία περίπτωση, είναι επειδή ακριβώς λαμβάνεις υπόψη σου τους περιορισμούς της ΓΛΩΣΣΑΣ. Όμως αυτό ακριβώς είναι που δείχνει ότι δεν μετατρέπονται (αν δεν κατακρεουργηθούν) όλοι οι αλγόριθμοι του βιβλίου στη ΓΛΩΣΣΑ. Όμως αυτό δεν είναι σημαντικό ούτε και ουσιώδες, αφού (όπως ανέφερα παραπάνω) έτσι κι αλλιώς υπάρχουν σημαντικές διαφορές ανάμεσα στο «αλγοριθμικό επίπεδο» και στο «προγραμματιστικό επίπεδο», ή, αλλιώς, στη «λειτουργία» της ψευδογλώσσας από αυτήν της ΓΛΩΣΣΑΣ. Αρκεί που οι μετατροπές είναι εφικτές σε άλλες γλώσσες προγραμματισμού. Το τι νόημα έχει η εντολή αυτή προκύπτει από το βιβλίο καθηγητή και τη δημοσίευση του Κοίλια και όχι ανάλογα με το τι εκτιμάμε εμείς. Το να δίνουμε εμείς στην εντολή Δεδομένα διαφορετικό νόημα κάθε φορά, προκειμένου να καταστήσουμε συμβατή την ψευδογλώσσα με τη ΓΛΩΣΣΑ δείχνει ότι δεν διακρίνουμε το αίτιο από το αιτιατό. Το ότι δεν εφικτές όλες οι μετατροπές στη ΓΛΩΣΣΑ είναι αναπόφευκτο αποτέλεσμα, και όχι κάτι που πρέπει να καταπολεμήσουμε, αφού μας ενδιαφέρει η αλγοριθμική και όχι ο προγραμματισμός όπως λες.

Όλα αυτά δεν σημαίνουν ότι προτείνω πίνακες παντού (όπως τονίζω σε κάθε μήνυμά μου), αλλά άλλο είναι να λέμε ότι κάτι «είναι λάθος», άλλο είναι να λέμε ότι «δεν είναι η καλύτερη λύση».

Τα συγκεκριμένα παραδείγματά σου κατ' αμέ είναι αδύναμα αφού φαίνεται καθαρά ότι η επιχειρηματολογία τους είναι βεβιασμένη και επινοήθηκε εκ των υστέρων για να δικαιολογηθεί η άποψη της ΚΕΕ. Έτσι, επικαλείσαι την επίλυση προβλημάτων της καθημερινότητας χωρίς τη χρήση υπολογιστή, αλλά υιοθετείς περιορισμούς από το χώρο του προγραμματισμού υπολογιστών. Όμως οι αναλογίες σου θεωρώ θα προκαλούν προβληματισμό στα παιδιά! Έτσι, σύμφωνα με την επιχειρηματολογία σου δεν θα μπορούσαμε να ταξινομήσουμε τα CD αν δεν ξέρουμε από την αρχή πόσα είναι, το οποίο σε έναν μαθητή θα προξενούσε σύγχυση... Σύγχυση καταρχάς σε σχέση με το τι σημαίνει από την αρχή. Ποια είναι η αρχή; Όταν θα έχει διατυπωθεί το πρόβλημα; Ή μήπως αφού φροντίσουμε να έχουμε μάθει κάποιες επιπλέον πληροφορίες (βλ. το πλήθος των CD ως σταθερά); Σε επίλυση προβλημάτων χωρίς υπολογιστή αυτό δεν έχει σημασία! Η αναζήτηση των επιπλέον πληροφοριών μπορεί να είναι και μέρος της φάσης επίλυσης (βλ. το  «Διάβασε» το πλήθος των CD ως μεταβλητή, ή και η ανεύρεση των απαιτούμενων θηκών που ναι μπορεί και να μην υπάρχουν). Μάλιστα, ο μαθητής θα σου έλεγε πως: «Εγώ τα CD μου τα έχω ήδη σε θήκες (βλ. σε πίνακες) και παρόλα αυτά δεν ξέρω πόσα είναι! Ξεκινάω τη διαδικασία της επίλυσης, αρχικά βλέπω πόσα είναι, και στη συνέχεια εφαρμόζω ταξινόμηση»! Τι θα του πεις τότε; Ότι «δεν επιτρέπεται αυτό» γιατί η μέθοδός του δεν ταιριάζει καλά σε αυτό που θέλεις να του εξηγήσεις; Ή ότι θα πρέπει να τα μετρήσει πρώτα και μετά να «κηρύξουμε» την έναρξη της επίλυσης; Και ποια είναι η διαφορά; Στο τέλος θα χάσουμε το δάσος για να μη μας χαλάσει το δέντρο! Τα προβλήματα της καθημερινότητας συνήθως είναι ανοιχτά – δεν έχουμε από την αρχή όλα τα δεδομένα και καμιά φορά θα πρέπει να τα ανακαλύψουμε μόνοι μας. Βιβλίο σελ. 12: «Δεν είναι πάντοτε ιδιαίτερα κατανοητό τι ακριβώς ζητάει ένα πρόβλημα. Σε μια τέτοια περίπτωση θα πρέπει να θέτονται μια σειρά από ερωτήσεις με στόχο την διευκρίνηση πιθανών αποριών σχετικά με τα ζητούμενα, τον τρόπο παρουσίασής τους, το εύρος τους κ.λπ. Οι ερωτήσεις αυτές μπορούν να απευθύνονται είτε στο δημιουργό του προβλήματος, είτε στον ίδιο μας τον εαυτό αν εμείς καλούμαστε να αντιμετωπίσουμε το πρόβλημα.» Όμως στο σχολείο έχουμε μάθει να μιλάμε για συγκεκριμένου τύπου προβλήματα, με αυστηρούς περιορισμούς, που τα απομακρύνουν από τον πραγματικό κόσμο (π.χ. να μην έχουμε ισοβαθμίες, να δεχτούμε ότι μπορεί κάποιος να κάνει πήδους ακόμα και 50 μέτρων αν η άσκηση δεν μας λέει το αντίθετο, να φροντίσουμε ώστε η μέθοδός μας να δουλεύει σωστά για όλους τους πλανήτες και στον αιώνα τον άπαντα, να μη βάζουμε μόνοι μας «αυθαίρετα» όρια, κλπ.) Αυτό μπορεί να ισχύει για τα μαθηματικά, όπου αυτή η αφαίρεση είναι αναγκαία και που η έννοια της απόδειξης καταλαμβάνει το κεντρικό ρόλο, ή στη φυσική-χημεία που λύνουμε προβλήματα υπό ιδανικές συνθήκες (π.χ. χωρίς τριβές), αλλά δεν θα έπρεπε σε εμάς. Για τους ίδιους λόγους μας ενοχλεί όταν κάποιες ασκήσεις του τετραδίου μαθητή δεν διευκρινίζουν απόλυτα ποια είναι τα δεδομένα και τα ζητούμενα. Μας ενοχλεί όταν υπάρχουν δεδομένα που περισσεύουν – που δεν παίζουν ρόλο στη λύση – ή όταν λείπουν πράγματα που χρειάζονται. Και θεωρούμε ότι είναι πολύ σημαντικό το αν θα ξέρουμε από την αρχή το πλήθος των CD ή αν θα κάνουμε Διάβασμα στην πορεία. Έτσι καταλήγουμε σε ανούσιους τυφλοσούρτες του στυλ «αν έχουμε Διάβασε Ν τότε δεν μπορούμε να...». Κι όμως η σχετική βιβλιογραφία για το επίπεδο της αλγοριθμικής δεν συμφωνεί καθόλου με κάτι τέτοιο (βλ. σχετική παρουσίαση στο WIE στην Τρίπολη φέτος)....

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

Παρασκευά δεν σου κρύβω ότι προχώρησα να απαντήσω με μεγάλη απροθυμία για διάφορους λόγους: α) σε εκτιμάω και σε σέβομαι επειδή γνωρίζω το επίπεδο που κρατάς ως εκπαιδευτικός, οπότε δεν ήθελα να χαλάμε τις καρδιές μας, β) θεωρώ όμως ότι μου δίνεις αποσπασματική και όχι ολοκληρωμένη απάντηση σε αυτά που είχα γράψει και για αυτό είχα σκεφτεί αρχικά να μην συνεχίσω, γ) έχει φανεί από την αρχή ότι ο καθένας που συμμετείχε σε αυτή τη συζήτηση έχει τις πεποιθήσεις του τις οποίες και δεν αλλάζει, για αυτό και η συζήτηση δεν καταλήγει πουθενά (θα λέγαμε ότι σε «αλγοριθμικό επίπεδο» η συζήτηση είναι ατέρμονη – σε «προγραμματιστικό επίπεδο» δεν μπορεί να είναι ατέρμονη μεν, αλλά δεν θα δώσει αποτέλεσμα δε!), δ) ίσως όλη η συζήτηση να αποδειχθεί άχρηστη στο μέλλον λόγω των σχεδίων του υπουργείου! Έτσι δεν νομίζω ότι θα επανέρθω, τουλάχιστον αν πρώτα δεν προκύψει θετικό αποτέλεσμα σε αυτό το τελευταίο.

merlin

Νίκο συμφωνώ στο 98% αυτών που λές. Ξεκινώντας από το τέλος, θέλω να δηλώσω ότι ούτε εγώ πιστεύω ότι θα βγει εύκολα άκρη (αν βγει), ούτε έχω διάθεση άλλης αντιπαράθεσης, ούτε πια έχει και πολύ νόημα με όλα αυτά που συμβαίνουν τον τελευταίο καιρό.

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

Η επιμονή μου στη "σύνδεση" των προβλημάτων με αναφορές στην πραγματική ζωή πηγάζει από το γεγονός ότι δεν θέλω να νομίζουν οι μαθητές ότι αυτά που κάνουν είναι άχρηστα για τους περισσότερους (εκτός από αυτούς που θα γίνουν προγραμματιστές ή εκείνους που θα τύχει να έχουν 1 ή 2 μαθήματα σχετικά στο πανεπιστήμιο).

Θα με βοηθούσε αν μου έλεγες που έχω λάθος στην παρακάτω φιλοσοφία μου:
1) Ένας κλασσικός πίνακας μπορεί να παρομοιαστεί με ένα σύνολο από κουτάκια (συνεχόμενα), κάτω από ένα όνομα . Άπειρες αναφορές μπορούμε να έχουμε (εργαλειοθήκες, CDθήκες, κλπ). Η στατικότητά τους, έτσι όπως ορίζεται (ανεπαρκώς ίσως) στο βιβλίο, σημαίνει ότι πριν αρχίσουμε να λύνουμε το πρόβλημά μας πρέπει να έχουμε φροντίσει να "αγοράσουμε" τα κατάλληλα μεγέθη.
2) Κάποιες γλώσσες (όπως η C) έχουν στατικούς πίνακες μεν, αλλά μπορούμε να "αγοράσουμε" όσα κουτάκια θέλουμε on demand, τη στιγμή της λύσης (έχουμε το μαγαζί με τις CDθήκες στον κάτω όροφο)
3) Υπάρχουν οι δυναμικές δομές στις οποίες θα μπορούσα να πω και εκεί παραδείγματα, είτε είναι απλά είτε διπλά συνδεδεμένες λίστες, δέντρα, κλπ

Όμως από τα 3 παραπάνω μόνο το 1ο μας ενδιαφέρει, έτσι δεν είναι? Τα υπόλοιπα, ούτε καν τα γνωρίζουν τα παιδιά. Ακόμα όμως και αν ρωτήσουν (φυσικά μου έχει τύχει) "αν δω ότι δεν μου φτάνουν τα κουτάκια, πάω και παίρνω και άλλα". Θέλουμε ή όχι να καταλάβουν οι μαθητές ότι το πρόβλημα δεν κατάφεραν να το λύσουν γιατί δεν είχαν κάνει σωστή εκτίμηση? Τι πάει να πει "θα πάω να πάρω κι άλλα"? Κι αν τα αγόρασες από τη Ζιμπάμπουε, θα ξαναπάς?

Είναι λοιπόν πολύ διαφορετικό να ξέρεις από πριν πόσα κουτάκια θα χρειαστείς (πας στη Ζιμπαμπουε, και όταν τα αγοράσεις και είσαι έτοιμος, ΤΟΤΕ ξεκινάς και λύνεις το πρόβλημα).
Στο πρόβλημα με τα CD, ο μαθητής τα είχε ήδη τα CD στις θήκες του, δεν υπάρχει πρόβλημα. Αν όμως πήγαινε στον κολλητό του που ήταν "χύμα" και τα CD τα είχε πεταμένα από δω κι από κει, θα μπορούσε να το λύσει το πρόβλημα?

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

Σε ένα φόρουμ δεν μπορείς να πεις πολλά, ελπίζω να τα πούμε κάποια στιγμή από κοντά (εκείνο το ουζάκι ακόμη το κανονίζουμε!)  :)


Παρασκευάς Πανάγου
Μηχανικός Η/Υ Συστημάτων
Καθηγητής Πληροφορικής ΠΕ20

Νίκος Αδαμόπουλος

Όπως έχω ξαναπεί παραπάνω ( https://alkisg.mysch.gr/steki/index.php?topic=2937.msg31335#msg31335 ) η στατικότητα όπως ορίζεται από το βιβλίο αναφέρεται στο προγραμματιστικό επίπεδο (βλ. "...κατά τη στιγμή του προγραμματισμού τους, και κατά συνέπεια κατά τη στιγμή της μετάφρασής τους...") και όχι κατ' ανάγκη στο αλγοριθμικό επίπεδο. (ασχέτως αν στην πραγματικότητα δεν ισχύει πλέον ούτε και αυτό σε προγραμματιστικό επίπεδο για όλες τις γλώσσες - θα λέγαμε ότι πρόκειται για έναν παλιό σκονισμένο ορισμό που υπάρχει ακόμα για ιστορικούς λόγους).

Επειδή λοιπόν εμείς μιλάμε σε αλγοριθμικό επίπεδο, οι όποιες αναφορές περί στατικότητας ή δέσμευσης χώρου (μνήμης, κουτιών, κλπ ) δεν έχουν ιδιαίτερη αξία... Έτσι, για μένα, από τις περιπτώσεις που αναφέρεις, η 1 και 2 δεν έχει διαφορά, εκτός κι αν ο σκοπός του παραδείγματός σου είναι ακριβώς αυτός: να δείξεις την στατικότητα όπως την ορίζει το βιβλίο, αλλά σε αλγοριθμικό επίπεδο. Αλλιώς ποια είναι η διαφορά του να αγοράσεις τα κουτάκια πριν ή κατά την επίλυση. Έτσι κι αλλιώς όποτε και να γινόταν η αγορά, πάντα θα έχεις όρια στο πόσα κουτάκια θα αγοράσεις (δεν θα σε φτάνουν τα λεφτά, δεν θα έχεις πού να βάλεις τα κουτάκια, κλπ). Το να τα αγοράσεις από πριν δεν σημαίνει ότι θα μπορείς να ξεπεράσεις αυτά τα όρια. Όπως έλεγα και στο προηγούμενο μήνυμα, γιατί να ενταχθεί η αγορά των κουτιών στη "φάση προετοιμασίας για την επίλυση" και όχι στην "φάση της ίδιας της επίλυσης"; Στο αλγοριθμικό επίπεδο εγώ δεν θέλω να τα ξεχωρίζω αυτά τα δύο. Άλλωστε τα κουτάκια υπάρχουν στο μαγαζί του κάτω ορόφου - εκτός κι αν φοβόμαστε μήπως έχουν ήδη πουληθεί αλλού όταν θα τα χρειαστούμε!

Και για να κλείνω, μη νομίζεις ότι δεν είναι κι εγώ υπέρ των παραδειγμάτων από την καθημερινή ζωή και των αναλογιών γενικότερα. Δες π.χ. ένα παλιότερο κείμενό μου που μιλούσε για διδασκαλία εννοιών από τα δίκτυα: http://www.etpe.gr/files/proceedings/uploads1/paper_s74.pdf

merlin

Δηλαδή, το συμπέρασμα είναι ότι το 3ο κεφάλαιο δε θα έπρεπε να υπάρχει ΚΑΘΟΛΟΥ? Τί είναι τελικά ο "αλγοριθμικός" πίνακας? Ποιά η διαφορά του από τον "προγραμματιστικό"? Εχει νόημα να υπάρχουν οι δομές δεδομένων γενικότερα στους αλγορίθμους? Από αυτά που βλέπω όμως στη βιβλιογραφία, υπάρχουν "αλγοριθμικές" κλάσεις, λίστες, δέντρα  (και φυσικά πίνακες) κλπ.
Μήπως τελικά όταν "εκτελούμε" έναν αλγόριθμο (είτε εμείς οι ίδιοι στο χαρτί, είτε σε PC, είτε με οποιοδήποτε μέσο), μιλάμε για "πρόγραμμα", οπότε είμαστε δέσμιοι του πεπερασμένου των υλικών που χρησιμοποιούμε? Ακόμα και με την malloc στην C για δέσμευση καινούριου κόμβου σε μια συνδεδεμένη λίστα, δεν έχουμε ως πάνω όριο την ελεύθερη RAM του Η/Υ?

Παράθεση από: Νίκος Αδαμόπουλος στις 02 Νοε 2010, 11:30:09 ΜΜ
.... Έτσι, για μένα, από τις περιπτώσεις που αναφέρεις, η 1 και 2 δεν έχει διαφορά, εκτός κι αν ο σκοπός του παραδείγματός σου είναι ακριβώς αυτός: να δείξεις την στατικότητα όπως την ορίζει το βιβλίο, αλλά σε αλγοριθμικό επίπεδο. Αλλιώς ποια είναι η διαφορά του να αγοράσεις τα κουτάκια πριν ή κατά την επίλυση. Έτσι κι αλλιώς όποτε και να γινόταν η αγορά, πάντα θα έχεις όρια στο πόσα κουτάκια θα αγοράσεις (δεν θα σε φτάνουν τα λεφτά, δεν θα έχεις πού να βάλεις τα κουτάκια, κλπ). Το να τα αγοράσεις από πριν δεν σημαίνει ότι θα μπορείς να ξεπεράσεις αυτά τα όρια....

Δεν φαίνεται η διαφορά ότι στην 1η περίπτωση το μαγαζί είναι στη Ζιμπάμπουε (καρα-στατικός πίνακας όπως τον γνωρίζαμε εμείς πριν πολλά χρόνια), άρα αν δε με φτάσουν τα κουτάκια κατά την εκτέλεση της λύσης λέω "κλάφτα Χαράλαμπε", ενώ στη 2η περίπτωση μπορώ άμεσα να αγοράσω όσα κουτάκια μάθω εκείνη τη στιγμή ότι θα χρειαστώ (int array[n] όπου το n το έχω διαβάσει πιο πριν)?

Δε μου λέει τίποτα το γεγονός ότι έχουν εξελιχθεί οι γλώσσες προγραμματισμού και χειρίζονται τις δομές δεδομένων με καλύτερο τρόπο. (Για παράδειγμα στο Microworlds μπορείς να χρησιμοποιείς πίνακα και να προσθέτεις κι άλλα στοιχεία μέσα, κάτι σαν στατικοί - δυναμικοί ταυτόχρονα.)

Στη ζωή τους τα παιδιά θα τα βρουν όλα "έτοιμα" και άμεσα διαθέσιμα (αδιαφορώντας πάντα για το "υλοποιήσιμο")? Θέλουμε να μάθουν να σκέφτονται πώς θα λύσουν τα προβλήματά τους? Τι θα χρειαστούν για τη λύση? Δεν πρέπει να αποτελεί διδακτικό στόχο η επιλογή (ή όχι) μιας δομής δεδομένων? Το ξαναλέω: Στη ζωή τους, όχι στο πανεπιστήμιο για την εργασία τους στη C++

Παρασκευάς Πανάγου
Μηχανικός Η/Υ Συστημάτων
Καθηγητής Πληροφορικής ΠΕ20