Aσκήσεις σε στοίβα και ουρά σε ΓΛΩΣΣΑ

Ξεκίνησε από Πέτρος Κ., 22 Ιουν 2015, 08:53:23 ΜΜ

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

evry

Το γεγονός ότι κάποια πολύ καλά βιβλία χρησιμοποιούν τις λειτουργίες push/pop δε σημαίνει ότι και εμείς μπορούμε να τις χρησιμοποιούμε μια χαρά, ούτε σημαίνει ότι αυτό στη δική μας περίπτωση δεν είναι δυσνόητο για τους μαθητές. Τι εννοώ.
Άλλο να γράψεις

      stack.pop()

και άλλο
     ΚΑΛΕΣΕ pop(stack, top, value)

ή ακόμα καλύτερα, άλλο
     queue.delete()

και άλλο
     KAΛΕΣΕ delete(queue, front, rear, value)

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

Είναι φανερό ότι η επιλογή της ΓΛΩΣΣΑΣ για την εισαγωγή των μαθητών σε δομές δεδομένων όπως η στοίβα και η ουρά είναι απλά καταστροφική αφού προσφέρει αρκετό διδακτικό θόρυβο και το σημαντικότερο απ'όλα, δεν προσφέρει καθόλου τη λεγόμενη ενθυλάκωση ή καλύτερα όπως θα έλεγα εγώ απόκρυψη πληροφορίας. Όλες οι μεταβλητές είναι global άρα για τι είδους δομές δεδομένων μιλάμε και για τι σόι Αφηρημένους Τύπους Δεδομένων μιλάμε;
Το πρόβλημα κατά τη γνώμη μου είναι όλο το κεφάλαιο 10.

What I cannot create I do not understand -- Richard Feynman
http://evripides.mysch.gr

ether

#46
Παράθεση από: evry στις 28 Ιουλ 2015, 12:42:51 ΜΜ
Το γεγονός ότι κάποια πολύ καλά βιβλία χρησιμοποιούν τις λειτουργίες push/pop δε σημαίνει ότι και εμείς μπορούμε να τις χρησιμοποιούμε μια χαρά, ούτε σημαίνει ότι αυτό στη δική μας περίπτωση δεν είναι δυσνόητο για τους μαθητές. Τι εννοώ.
Άλλο να γράψεις

      stack.pop()

και άλλο
     ΚΑΛΕΣΕ pop(stack, top, value)

ή ακόμα καλύτερα, άλλο
     queue.delete()

και άλλο
     KAΛΕΣΕ delete(queue, front, rear, value)

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

Είναι φανερό ότι η επιλογή της ΓΛΩΣΣΑΣ για την εισαγωγή των μαθητών σε δομές δεδομένων όπως η στοίβα και η ουρά είναι απλά καταστροφική αφού προσφέρει αρκετό διδακτικό θόρυβο και το σημαντικότερο απ'όλα, δεν προσφέρει καθόλου τη λεγόμενη ενθυλάκωση ή καλύτερα όπως θα έλεγα εγώ απόκρυψη πληροφορίας. Όλες οι μεταβλητές είναι global άρα για τι είδους δομές δεδομένων μιλάμε και για τι σόι Αφηρημένους Τύπους Δεδομένων μιλάμε;
Το πρόβλημα κατά τη γνώμη μου είναι όλο το κεφάλαιο 10.
Προφανώς αν έχεις κάνει υποπρογράμματα πρώτα, τα έχεις εξηγήσει στα παιδιά αυτά που λες. Να είσαι σίγουρος ότι έχουμε προσέξει τις διαφορές που αναφέρεις ανάμεσα σε χρήση δομών σε γλώσσες που δεν παρέχουν ενθυλάκωση και σε object oriented ή object based γλώσσες.

Προφανώς εννοείς όλες οι μεταβλητές είναι local στη ΓΛΩΣΣΑ. Δεν είναι όμως αυτό το χαρακτηριστικό της ΓΛΩΣΣΑΣ που δε μας δίνει τη δυνατότητα να κάνουμε τα πράγματα όπως θα θέλαμε από πλευράς ενθυλάκωσης κτλ.

Προφανώς σε μια γλώσσα σαν τη ΓΛΩΣΣΑ δεν μπορείς να έχεις την ενθυλάκωση και όλα τα άλλα καλά που θα θέλαμε να έχουμε, όπως δεν μπορούσες να τα έχεις ούτε στην Pascal, ούτε στη C, ούτε στη Basic, ούτε σε τόσες άλλες.
Κατά τη γνώμη μου όμως, η υλοποίηση και χρήση υποπρογραμμάτων για τις λειτουργίες της ουράς και της στοίβας είναι σαφώς πιο κοντά σε αυτό που θα θέλαμε απ' ό,τι ο απευθείας χειρισμός των δεικτών.
Κάτι ανάλογο κάναμε και στην Pascal, και στη C, και στη Basic.

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

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

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

Πέτρος Κ.

#47
Διορθώστε με αν κάνω λάθος αλλά χωρίς ενθυλάκωση δεν νομίζω ότι μπορούμε να υλοποιήσουμε στοίβα (ή ουρά).

Αυτό που κάνουμε σε όλες τις περιπτώσεις (είτε υλοποιηθεί με υποπρόγραμμα είτε όχι) είναι ότι έχουμε ένα πίνακα και του συμπερίφερόμαστε σαν να ήταν στοίβα (ή ουρά). Έχουμε πίνακα όχι στοίβα (ή ουρά).

Στο βιβλίο του καθηγητή παρατηρώ (σελ. 86-87) πως όταν υλοποιεί push και pop σε αλγόριθμο δεν δίνει στα δεδομένα τον πίνακα. Εκεί προφανώς αποκρίποτνται τα υπόλοιπα δεδομένα του πίνακα από τον αλγόριθμό που καλεί τις push και pop και υλοποιεί έτσι (χωρίς να το λέει) ενθυλάκωση.

Και για να το δώσω και με παράδειγμα. Όταν κάνεις αυτό:
ΚΑΛΕΣΕ pop(stack, top, value)

τότε μπορείς να κάνεις και αυτό (α):
ΓΡΑΨΕ stack[1]

και αυτό (β):
stack[4] <-- stack[1]


Τα (α) και (β) προφανώς δεν μπορούν να γίνουν αν επρόκειτω για στοίβα. ΟΕΔ

Και μία, ρητορική μάλλον, ερώτηση: Αν σε μία άσκηση που ζητά πρόγραμμα σε γλώσσα και στοίβα (ή ουρά) ένας μαθητής κάνει κάτι από τα (α) ή (β) θα το θεωρήσουμε λάθος;

evry

#48
Δυστυχώς δεν έχω γίνει αντιληπτός. Για αυτό άλλωστε χρησιμοποίησα τον όρο απόκρυψη πληροφορίας (information hiding) και όχι το ενθυλάκωση, το οποίο νομίζω ότι το αντιλαμβάνεστε πιο πολύ σαν προσβασιμότητα των πεδίων και όχι σαν απόκρυψη αυτών. Από παιδαγωγικής πλευράς (και όχι μόνο όμως) το σημαντικότερο είναι το δεύτερο. Δηλαδή να μην υπάρχει στον κώδικα εντολή που αναφέρεται στην εσωτερική υλοποίηση της δομής ώστε αν την αλλάξω να υποχρεωθώ να αλλάξω το interface. Δηλαδή να έχουμε πλήρη διαχωρισμό interface/implementation. Για να το πετύχεις αυτό δεν χρειάζεται απαραίτητα να έχεις ενθυλάκωση με την έννοια των προσδιοριστών πρόσβασης (public/private/protected).

Παράθεση από: ether στις 28 Ιουλ 2015, 01:27:04 ΜΜ
Προφανώς σε μια γλώσσα σαν τη ΓΛΩΣΣΑ δεν μπορείς να έχεις την ενθυλάκωση και όλα τα άλλα καλά που θα θέλαμε να έχουμε, όπως δεν μπορούσες να τα έχεις ούτε στην Pascal, ούτε στη C, ούτε στη Basic, ούτε σε τόσες άλλες.
με Basic δεν έχω ασχοληθεί, αλλά σε pascal και C μπορείς μια χαρά να έχεις αυτό που λέμε απόκρυψη πληροφορίας, δηλαδή να μην "φαίνεται" η εσωτερική δομή της στοίβας/ουράς. Πως το καταφέρνεις? ορίζεις ένα record/struct και βάζεις μέσα τους δείκτες και τη στοίβα/ουρά. Αν μιλάμε για δυναμική δομή είναι μια χαρά, αλλά και με πίνακα δουλεύει. Έτσι κρύβεις την υλοποίηση και ο μαθητής βλέπει μόνο το interface οπότε γράφει

remove(queue) και τέλος
πάλι είναι καλύτερο από το
ΚΑΛΕΣΕ remove(queue, front, rear, value)

Το ότι η πρόσβαση είναι public δε μας ενδιαφέρει, μπορούμε με παραδείγματα να δείξουμε στους μαθητές ότι είναι καλό να μην πειράζουν την εσωτερική δομή.
π.χ. στην Python μπορούμε να ορίσουμε κάποιο μέλος private με το σκεπτικό ότι δεν πρέπει να πειραχτεί. Ωστόσο εκείνος που θα το χρησιμοποιήσει μπορεί να το πειράξει. Το αν θα το πειράξει επαφίεται καθαρά στην ωριμότητά του.
Ας το δούμε και από εκπαιδευτικής πλευράς. Δεν θέλουμε κάποιος να μην πειράζει κάτι επειδή κάποιος άλλος το όρισε private αλλά να καταλαβαίνει ότι δεν μπορεί να το πειράξει για λόγους software engineering. Άλλωστε δε μιλάμε για ιδιαίτερα πολύπλοκο κώδικα

Παράθεση
Τώρα γι' αυτό που λες για το αν δείχνει κάτι το τι χρησιμοποιούν μερικοί από τους καλύτερους συγγραφείς και δασκάλους στο συγκεκριμένο θέμα, και αν μπορούμε να έχουμε κι εμείς την ίδια φιλοσοφία, διαφωνώ με αυτό που γράφεις.
Δεν κατάλαβες τι είπα, οι συγγραφείς που λες δεν χρησιμοποιούν ΓΛΩΣΣΑ, π.χ. στο CLR χρησιμοποιούν μια δική τους ψευδογλώσσα, απαλλαγμένη από τον διδακτικό θόρυβο της δικής μας ΓΛΩΣΣΑΣ

Παράθεση
Άλλωστε, δε θα υπάρχει πρόβλημα που να λύνεται με υποπρογράμματα και να μη λύνεται χωρίς, ούτε το ανάποδο.
έχω στο μυαλό μου μερικά ενδιαφέροντα αναδρομικά προβλήματα, όπως για παράδειγμα να προσπαθήσεις να υπολογίσεις τη συνάρτηση του Ackermann χωρίς αναδρομή, ή να υλοποιήσεις επαναληπτικά την quickSort ή τους πύργους του Ανόι.
Δε λέω ότι δε γίνονται επαναληπτικά αλλά ότι είναι πολύ δύσκολο να γίνουν. Άλλωστε δεχόμαστε τη θέση των Church-Turing
What I cannot create I do not understand -- Richard Feynman
http://evripides.mysch.gr

itt

Παράθεση από: Πέτρος Κ. στις 28 Ιουλ 2015, 04:54:35 ΜΜ
Διορθώστε με αν κάνω λάθος αλλά χωρίς ενθυλάκωση δεν νομίζω ότι μπορούμε να υλοποιήσουμε στοίβα (ή ουρά).

Αυτό που κάνουμε σε όλες τις περιπτώσεις (είτε υλοποιηθεί με υποπρόγραμμα είτε όχι) είναι ότι έχουμε ένα πίνακα και του συμπερίφερόμαστε σαν να ήταν στοίβα (ή ουρά). Έχουμε πίνακα όχι στοίβα (ή ουρά).
λάθος;

Δεν έχει σχέση το encapsulation με τη στοίβα. Είτε ξέρεις ότι έχεις πίνακα και του συμπεριφέρεσαι σαν να είναι στοίβα, είτε δεν ξέρεις ότι έχεις τον πίνακα και συμπεριφέρεσαι σαν να είναι στοίβα, σε κάθε περίπτωση έχεις έναν πίνακα.

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

ΠαράθεσηΔεν υπάρχει κάτι λάθος σε αυτό που συζητάμε. Δεν είπε κανείς να ανοίξεις φιλοσοφική συζήτηση με το τμήμα για τα οφέλη του encapsulation, η ιδέα είναι να τους δώσεις μια πειθαρχία στο πώς μεταφέρουν το mental model που έχουν στο μυαλό τους για το πρόβλημα, στο χαρτί/υπολογιστή. Επίσης εγώ δεν επιχειρηματολογώ υπερ του να τους το διδάξεις πριν κάνεις υποπρογράμματα και όπως είπα και στον απο πάνω, απλά απάντησα στην ερώτηση σου ύπο την σκοπιά του καθηγήτη (τουλάχιστον, τη σκοπιά που υποθέτω εγώ ότι έχουν).

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

Παράθεση1. Προκύπτει από κάπου ότι η χρήση υποπρογραμμάτων για την υλοποίηση των λειτουργιών στοίβας και ουράς σε προγραμματιστικές ασκήσεις είναι δυσνόητη από τους μαθητές, ή πιο δυσνόητη απ' ό,τι ο απευθείας χειρισμών των δεικτών; Ή μήπως δεν προκύπτει αλλά είναι κάποιο αξίωμα; Κατά τη γνώμη μου, ισχύει το ακριβώς αντίθετο, όπως έχω πει και σε προηγούμενο μήνυμά μου.

Κανείς δεν είπε αυτό που γράφεις.

Παράθεση2. Το ότι κάτι γίνεται στον πραγματικό κόσμο, σε πραγματικά προγράμματα, δε σημαίνει ότι είναι και πιο σύνθετο και για προχωρημένους. Άλλωστε, πολλά πράγματα που γίνονται στον πραγματικό κόσμο με τον τρόπο που γίνονται (όπως η ενθυλάκωση/encapsulation), γίνονται ακριβώς για να κάνουν τα πράγματα πιο απλά.

Συμφωνώ, αλλά η σχέση με το μάθημα μας ποια είναι;

Παράθεση3. Τα πιο σημαντικά βιβλία αλγορίθμων (*), κατά την παρουσίαση αλγορίθμων που χρησιμοποιούν στοίβα και ουρά, είτε σε ψευδογλώσσα είτε σε πραγματική γλώσσα προγραμματισμού, απλά καλούν τις λειτουργίες.  Παρουσιάζουν τους αλγορίθμους ως πελάτες (clients) των δομών στοίβα και ουρά. Άραγε το κάνουν λάθος; Ή μήπως έτσι όπως το κάνουν είναι πιο δυσνόητο για τον αναγνώστη να καταλάβει τον αλγόριθμο απ' ό,τι αν χειρίζονταν απ' ευθείας του δείκτες αλλά δεν τους νοιάζει γιατί απευθύνονται σε φοιτητές;

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


Παράθεση4. Ποιος εμποδίζει κάποιον να κάνει κάποιες απλές ασκήσεις (ή και όλες, ακόμα και τις σύνθετες ασκήσεις) σε στοίβα και ουρά χωρίς χρήση υποπρογραμμάτων; Ο καθένας κάνει ό,τι νομίζει καλύτερο.

Σαφώς ο καθένας κάνει ότι νομίζει καλύτερα και κρίνεται από τους μαθητές του.

Παράθεση5. Γιατί πρέπει ντε και σώνει η ουρά και η στοίβα να γίνουν πριν από τα υποπρογράμματα; Επειδή είναι στο κεφάλαιο 3 ενώ τα υποπρογράμματα στο κεφάλαιο 10; Εγώ προσωπικά μέχρι πέρυσι από το κεφάλαιο 3 έκανα πρώτα ό,τι αφορούσε στους πίνακες και στο τέλος του 3 έκανα την ουρά και τη στοίβα. Τι πρόβλημα θα υπάρξει αν τώρα την κάνω ακόμα και μετά τα υποπρογράμματα; Το ότι δε θα καταλάβουν για τη στοίβα χρόνου εκτέλεσης; Θα τους την πω μετά αυτή.

Όπως έγραψες,  "Ο καθένας κάνει ό,τι νομίζει καλύτερο"



ether

Παράθεση από: evry στις 28 Ιουλ 2015, 06:23:13 ΜΜ
Δυστυχώς δεν έχω γίνει αντιληπτός. Για αυτό άλλωστε χρησιμοποίησα τον όρο απόκρυψη πληροφορίας (information hiding) και όχι το ενθυλάκωση, το οποίο νομίζω ότι το αντιλαμβάνεστε πιο πολύ σαν προσβασιμότητα των πεδίων και όχι σαν απόκρυψη αυτών. Από παιδαγωγικής πλευράς (και όχι μόνο όμως) το σημαντικότερο είναι το δεύτερο. Δηλαδή να μην υπάρχει στον κώδικα εντολή που αναφέρεται στην εσωτερική υλοποίηση της δομής ώστε αν την αλλάξω να υποχρεωθώ να αλλάξω το interface. Δηλαδή να έχουμε πλήρη διαχωρισμό interface/implementation. Για να το πετύχεις αυτό δεν χρειάζεται απαραίτητα να έχεις ενθυλάκωση με την έννοια των προσδιοριστών πρόσβασης (public/private/protected).
με Basic δεν έχω ασχοληθεί, αλλά σε pascal και C μπορείς μια χαρά να έχεις αυτό που λέμε απόκρυψη πληροφορίας, δηλαδή να μην "φαίνεται" η εσωτερική δομή της στοίβας/ουράς. Πως το καταφέρνεις? ορίζεις ένα record/struct και βάζεις μέσα τους δείκτες και τη στοίβα/ουρά. Αν μιλάμε για δυναμική δομή είναι μια χαρά, αλλά και με πίνακα δουλεύει. Έτσι κρύβεις την υλοποίηση και ο μαθητής βλέπει μόνο το interface οπότε γράφει

remove(queue) και τέλος
πάλι είναι καλύτερο από το
ΚΑΛΕΣΕ remove(queue, front, rear, value)

Το ότι η πρόσβαση είναι public δε μας ενδιαφέρει, μπορούμε με παραδείγματα να δείξουμε στους μαθητές ότι είναι καλό να μην πειράζουν την εσωτερική δομή.
π.χ. στην Python μπορούμε να ορίσουμε κάποιο μέλος private με το σκεπτικό ότι δεν πρέπει να πειραχτεί. Ωστόσο εκείνος που θα το χρησιμοποιήσει μπορεί να το πειράξει. Το αν θα το πειράξει επαφίεται καθαρά στην ωριμότητά του.
Ας το δούμε και από εκπαιδευτικής πλευράς. Δεν θέλουμε κάποιος να μην πειράζει κάτι επειδή κάποιος άλλος το όρισε private αλλά να καταλαβαίνει ότι δεν μπορεί να το πειράξει για λόγους software engineering. Άλλωστε δε μιλάμε για ιδιαίτερα πολύπλοκο κώδικα
Δεν κατάλαβες τι είπα, οι συγγραφείς που λες δεν χρησιμοποιούν ΓΛΩΣΣΑ, π.χ. στο CLR χρησιμοποιούν μια δική τους ψευδογλώσσα, απαλλαγμένη από τον διδακτικό θόρυβο της δικής μας ΓΛΩΣΣΑΣ
έχω στο μυαλό μου μερικά ενδιαφέροντα αναδρομικά προβλήματα, όπως για παράδειγμα να προσπαθήσεις να υπολογίσεις τη συνάρτηση του Ackermann χωρίς αναδρομή, ή να υλοποιήσεις επαναληπτικά την quickSort ή τους πύργους του Ανόι.
Δε λέω ότι δε γίνονται επαναληπτικά αλλά ότι είναι πολύ δύσκολο να γίνουν. Άλλωστε δεχόμαστε τη θέση των Church-Turing
1. Εγώ αναφέρθηκα σε ενθυλάκωση.

2. Από πού προκύπτει ότι με τον όρο ενθυλάκωση αναφέρομαι κυρίως στην προσβασιμότητα πεδίων; Όπως ξέρεις, μ' αυτόν τον όρο αναφερόμαστε και σ' άλλα πράγματα.

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

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

5. Και στο θέμα των συγγραφέων, όντως δεν καταλαβαινόμαστε.

Γενικώς δεν πολυκαταλαβαινόμαστε, αλλά μπορούμε να ζήσουμε κι έτσι.

ether

Παράθεση από: Καρκαμάνης Γεώργιος στις 28 Ιουλ 2015, 09:07:06 ΜΜ
Κανείς δεν είπε αυτό που γράφεις.
Κανείς δεν το είπε; Τότε μάλλον πρέπει να πάω να κοιταχτώ.

Παράθεση από: Καρκαμάνης Γεώργιος στις 28 Ιουλ 2015, 09:07:06 ΜΜ
Συμφωνώ, αλλά η σχέση με το μάθημα μας ποια είναι;
Η σχέση με το μάθημά μας είναι ότι είπες πως δε σημαίνει ότι κάτι που γίνεται στον πραγματικό κόσμο είναι ντε και σώνει καλό και για το μάθημα και για τους μαθητές, κι ότι μπερδεύει τους μαθητές. Κι εγώ σου απάντησα ότι δεν είναι ντε και σώνει, αλλά πολλές φορές είναι καλό, όπως στην περίπτωση της χρήσης υποπρογραμμάτων για τη στοίβα και την ουρά.

Παράθεση από: Καρκαμάνης Γεώργιος στις 28 Ιουλ 2015, 09:07:06 ΜΜ
Ποιος είπε ότι κάνουν λάθος; Και επίσης αυτά τα βιβλία που αναφέρεις, έχουν άλλο στόχο και όχι να βοηθήσουν έναν μαθητή να ανταποκριθεί στις απαιτήσεις των πανελλαδικών εξετάσεων.
Έχουν στόχο να μάθει ο αναγνώστης αυτό που πραγματεύονται. Νομίζω κι εμείς από εκεί ξεκινάμε.

Παράθεση από: Καρκαμάνης Γεώργιος στις 28 Ιουλ 2015, 09:07:06 ΜΜ
Σαφώς ο καθένας κάνει ότι νομίζει καλύτερα και κρίνεται από τους μαθητές του.
Όπως έγραψες,  "Ο καθένας κάνει ό,τι νομίζει καλύτερο"
Ευτυχώς συμφωνούμε και σε κάτι.

itt

#53
Παράθεση από: Καρκαμάνης Γεώργιος στις 28 Ιουλ 2015, 09:07:06 ΜΜ
Το πρόβλημα δεν είναι αν θα ανοίξουμε φιλοσοφικές συζητήσεις μέσα στο τμήμα, αλλά το ότι ανοίγουμε φιλοσοφικές συζητήσεις για διάφορα θέματα σε αυτό το φόρουμ που πολλές φορές ξεφεύγουν από την παιδαγωγική  και τη διδακτική πλευρά του θέματος.

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

Diotima

#54
Η συζήτηση που προηγήθηκε ήταν πραγματικά πάρα πολύ ενδιαφέρουσα από επιστημονική και ερευνητική άποψη σχετικά με τις δυνατότητες της ΓΛΩΣΣΑΣ στην υλοποίηση της στοίβας και της ουράς σαν δομές δεδομένων αλλά και των αντίστοιχων λειτουργιών τους. Προφανώς και δε μπορούμε να έχουμε την υλοποίηση μιας αντικειμενοστραφούς γλώσσας (Αφηρημένο Τύπο Δεδομένων, Ενθυλάκωση κ.τ.λ.) αλλά ούτε και όλες τις δυνατότητες μιας πραγματικής procedural γλώσσας.
Έχουμε τη γλώσσα ΓΛΩΣΣΑ με τις περιορισμένες δυνατότητες που έχει. Θεωρητικά μπορούμε στους μαθητές να αναφέρουμε ένα σωρό ωραία προγραμματιστικά παραδείγματα που υλοποιούνται με στοίβα ή με ουρά, πράγμα που θεωρώ απαραίτητο για να καταλάβουν την τεράστια χρησιμότητα αυτών των δομών και των λειτουργιών τους, τα οποία όμως προγραμματιστικά δε μπορούμε να υλοποιήσουμε στη ΓΛΩΣΣΑ.
Θεωρώ εντελώς απίθανο λοιπόν ο συγγραφέας που έγραψε ή αντέγραψε από κάποιο βιβλίο τους αλγορίθμους για την Ώθηση, Απώθηση, Εισαγωγή και Εξαγωγή στο βιβλίο καθηγητή να είχε στο μυαλό του εκείνη την ώρα την υλοποίηση σε ΓΛΩΣΣΑ (να αναφέρω εδώ και τις λάθος συνθήκες top<=1 για την απώθηση και rear<= front για εξαγωγή που αναφέρονται όχι μόνο στους αλγορίθμους αλλά και εξηγούνται με σχετικές παρατηρήσεις από κάτω). Αν όμως συνέβη αυτό, τότε οι αλγόριθμοι προφανώς και είναι λάθος ως προς τις παραμέτρους, αφού δε μπορούν να υλοποιηθούν σε ΓΛΩΣΣΑ. Πέρα από μια γενική ιδέα δε μπορούν να δώσουν τίποτα άλλο και μου δείχνουν και κάποια σύγχυση. Επίσης η εξαγωγή δε συμβαδίζει με την περιγραφή που κάνει το βιβλίο του μαθητή και δεν ασχολήθηκα μετά από όλα αυτά με τους συγκεκριμένους αλγορίθμους, είναι ακατάλληλοι για τη ΓΛΩΣΣΑ.
Εφ' όσον καλώς ή κακώς μπήκαν στην ύλη ασκήσεις με στοίβα και ουρά, εκτός αν αυτό αλλάξει στο μέλλον, πρέπει να χρησιμοποιήσουμε τις δυνατότητες της ΓΛΩΣΣΑΣ.
Στην ερώτηση αν είναι καλύτερα οι λειτουργίες να περιγράφονται στις ασκήσεις με υποπρογράμματα ή όχι, προσωπικά προτιμώ τη χρήση υποπρογραμμάτων για κάποιους λόγους που έχουν ήδη αναφερθεί και για τους εξής επίσης:
Οι δομές στοίβα και ουρά είναι άρρηκτα συνδεδεμένες με τις πολύ συγκεκριμένες λειτουργίες τους οι οποίες υλοποιούνται πάντα με τον ίδιο κώδικα.
Αν για παράδειγμα πρέπει να γίνει 3 φορές ώθηση σε ένα πρόγραμμα με τον έλεγχο κάποιων συνθηκών, ο μαθητής θα πρέπει να γράψει 3 φορές τις ίδιες εντολές αν δεν έχει το υποπρόγραμμα ΩΘΗΣΗ. Όχι ότι αυτό είναι κακό, αλλά αμέσως καταλαβαίνουμε λογικά ότι η χρήση υποπρογράμματος είναι ενδεδειγμένη για τη συγκεκριμένη λειτουργία και την επανάληψη της.
Επίσης η χρήση υποπρογράμματος διαχωρίζει τις υπόλοιπες εντολές του προγράμματος που εξαρτώνται από τη φύση του προβλήματος που αυτό επιλύει από τη πολύ συγκεκριμένη λειτουργία της Ώθησης ή της Απώθησης ή της Εισαγωγής ή της Εξαγωγής. Μου φαίνεται ότι αν οι εντολές αυτών των λειτουργιών εκτελούνται άμεσα χωρίς υποπρόγραμμα καταντούν κάπως τετριμμένες και θα τις σκέφτονταν ένας μαθητής και χωρίς να ξέρει τίποτα από στοίβα ή ουρά.
Γράφοντας ΚΑΛΕΣΕ ΩΘΗΣΗ(...,..,...) κατανοεί νομίζω καλύτερα ότι εκείνη την ώρα εκτελείται η συγκεκριμένη λειτουργία πάνω στη δομή στοίβα.
Με όλα αυτά δε θέλω να πω πως είναι άσκοπη η υλοποίηση χωρίς υποπρογράμματα.
Μια διδακτική προσέγγιση που σκέφτομαι, είναι να γίνουν δυο τρεις ασκήσεις στη στοίβα και δυο τρεις στην ουρά για κατανόηση στο τέλος του 3ου-9ου κεφαλαίου, πριν ακριβώς την εισαγωγή στα υποπρογράμματα, μαζί με τη θεωρητική παρουσίαση των δομών και μόλις γίνει η εισαγωγή στο 10ο κεφάλαιο μετά τις πρώτες ασκήσεις κατανόησης και συγγραφής απλών υποπρογραμμάτων να γίνει η σύνδεση των λειτουργιών αυτών με την υλοποίηση τους και τη χρήση τους με υποπρογράμματα.
Τα παιδιά θα τις έχουν πρόσφατα στο μυαλό τους και νομίζω ότι θα μπορέσουν να καταλάβουν την αξία υλοποίησης τους με υποπρογράμματα.

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

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

Παράθεση από: Πέτρος Κ. στις 28 Ιουλ 2015, 04:54:35 ΜΜ
Αυτό που κάνουμε σε όλες τις περιπτώσεις (είτε υλοποιηθεί με υποπρόγραμμα είτε όχι) είναι ότι έχουμε ένα πίνακα και του συμπερίφερόμαστε σαν να ήταν στοίβα (ή ουρά). Έχουμε πίνακα όχι στοίβα (ή ουρά).

+1

ether

Συνημμένες δυο ασκήσεις και ενδεικτική λύση τους.

ether

Συνημμένη μια άσκηση και ενδεικτική λύση της (σε δυο εκδοχές, με λίγο διαφορετική γραφή).

bugman

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

bugman

Στην βιβλιογραφία της πληροφορικής αναφέρονται δύο ξεχωριστές οντότητες,  το λεγόμενο  stack και το λεγόμενο heap. Σε ελληνικά βιβλία βρίσκω την heap ως στοίβα και τον stack ως σωρό. Η πραγματική διαφορά τους, εκτός από τα ονόματα, είναι εκπληκτικά μεγάλη. Εδώ έχει αξία να αντιληφθεί ο μαθητής τον χάρτη μνήμης. Ένα μικρό μέρος της μνήμης είναι ο σωρός ή stack. Αντίθετα το μεγαλύτερο μέρος της μνήμης είναι heap.  Ο σωρός γράφει τις διευθύνσεις επιστροφής σε κλήσεις υποπρογραμμάτων αλλά περιλαμβάνει πλαίσια δηλαδή καθορισμένες μικρές περιοχές για πέρασμα παραμέτρων. Ο σωρός χρησιμοποιείται για την αποθήκευση των κσταχωρητών του επεξεργαστή. Το heap είναι το σύστημα απόδοσης μνήμης του λειτουργικού. Αν έχει κανείς ιδέα από assembly θα γνωρίζει ότι η μνήμη παραχωρείται με προηγούμενη δέσμευση. Δηλαδή ζητάει κανείς ένα γίγα και σιγά σιγά το παίρνει. Έτσι ξέρει ότι θα έχει κάποια στιγμή το μεγάλο κομμάτι συνεχόμενης μνήμης αλλά δεν θα το πάρει όλο αν δεν έχει πράμα να το γεμίσει. Αυτή είναι η στοίβα. Αυτά που διαβάζω εδώ είναι ουρές που προσομοιάζουν το stack  ή σωρό για άλλες χρήσεις όμως από τις κανονικές, ενώ το αν θα είναι σε πίνακα ή όχι είναι απλά τεχνικής φύσεως θέμα και όχι ουσίας. Οι ουρές πχ οι κυκλικές ουρές με δύο δείκτες και έναν χώρο, ίσως έναν πίνακα, έχουν χρησιμότητα σε προσομοιώσεις. Νομίζω όμως ότι τέτοιες σπαζοκεφαλιές δεν μπορεί να γίνονται μαθήματα.