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

[Πέτρος Κ.]

Δεν έχω καταλάβει τι εννοεί ο ποιητής;

Είδα στο βιβλίο του καθηγήτή ότι υπάρχουν οι αλγόριθμοί για Ωθηση / Απώθηση και Εισαγωγή / Εξαγωγή για τις ΔΤ3 και ΔΤ4.
α) Οι μαθητές θα τους θεωρούν δεδομένους ως υποπρόγραμματα και θα τους χρησιμοποιούν στα προγράμματά τους;
β) Θα πρέπει οι μαθητές να ξέρουν να τους υλοποιούν σε ΓΛΩΣΣΑ;
γ) Γιατί στην Ωθηση και Απώθηση δίνει δεδομένο το TOP? Αυτή η μεταβλήτή λογικά είναι εσωτερική της δομής και δεν είναι προσπελάσιμη απ'έξω!
δ) Ο πίνακας Stack πως και που θα δηλωθεί;
ε) Πως μπορώ να χρησιμοποιήσω 2 ή περισσότερες στοίβες σε ένα πρόγραμμα; Πώς δηλώνω μία στοίβα σε ΓΛΩΣΣΑ;

[Rathaniel]

α) Πολύ αμφιβάλλω για τους αλγορίθμους σε υποπρογράμματα.
β)Πιστεύω πως ναι θα πρέπει. Το πρόβλημα όμως θα πρέπει να είναι με πολύ καλή περιγραφή για να καταλάβει κάποιος τις απαιτήσεις στοίβας-ουράς.Ειδικά όμως για την ουρά θα πρέπει το πρόβλημα που δίνεται να έχει αρκετές παραδοχές. Ο τρόπος υλοποίησης της ουράς στο βιβλίο είναι εντελώς λάθος προγραμματιστικά (γιατί κανονικά γίνεται με δείκτες), οπότε θα πρέπει να ελαχιστοποιηθούν οι απαιτήσεις από το πρόβλημα.
γ)Αν θεωρείται δεδομένο, τότε στο πρόβλημα θα πρέπει να λεει ότι το δίνει ο χρήστη με Διάβασε. Συμφωνω με την προσπελασιμότητα, η top θα αλλάζει από μόνη της από το πρόγραμμα.
δ)
ΜΕΤΑΒΛΗΤΕΣ
   ΑΚΕΡΑΙΟΣ: Stack[20]
το πρόβλημα θα πρέπει υποχρεωτικά να περιγράφει το μέγεθος της στοίβας.   
ε)Για την δήλωση, σου απάντησα στο δ. Τώρα η χρήση έχει καποια τυποποιημένη διαδικασία προγραμματιστική (έλεγχοι υπερχείλισης-υποχείλισης με χρήση της top, αλλαγή της top, κοκ), αλλά όλα εξαρτούνται από την περιγραφή του προβλήματος. Για το "2 ή περισσότερες" θα έλεγα ότι μπορεί να έχεις δύο στοίβες σαν να είναι δύο παράλληλοι πίνακες (ονόματα βιβλίων και βάρη βιβλίων) , ή να είναι δύο στοίβες διαφορετικές (Στοίβα_βιβλίων1  και Στοίβα_βιβλίων2) και να ελέγχεται σε ποιά από τις δύο έγιναν οι περισσότερες λειτουργίες, ή αν στο τέλος μιας επαναληπτικής διαδικασίας η Στοίβα1 έχει περισσότερα βιβλία από την άλλη.

Η χρήση στοίβας σε πρόγραμμα δεν θα δημιουργήσει πρόβλημα. Τώρα για την ουρά.....

[Sergio]

Η υλοποίηση της στοίβας με πίνακα δε νομίζω πως θα προβληματίσει τους μαθητές.

Για την ουρά διατηρώ κάποιες επιφυλάξεις λόγω της "κυκλικής" λειτουργίας των δεικτών front και rear όταν η υλοποίηση γίνεται με πίνακα .. 

[Πέτρος Κ.]

Αναρωτιέμαι, πώς θα απαντήσουμε στην παρακάτω άσκηση:

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

[nikolasmer]

Αναρωτιέμαι, πώς θα απαντήσουμε στην παρακάτω άσκηση:

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

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

[Κανένας]

Αναρωτιέμαι, πώς θα απαντήσουμε στην παρακάτω άσκηση:

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

Πέτρο, πέντε ωθήσεις και μετά πέντε απωθήσεις.

[Diotima]

Αναρωτιέμαι, πώς θα απαντήσουμε στην παρακάτω άσκηση:

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

Κι εγώ δε νομίζω ότι έχει νόημα αυτή η διατύπωση άσκησης σαν εφαρμογή της στοίβας. Λύνεται απλά χωρίς τις λειτουργίες της στοίβας. Θα ήταν καλύτερα νομίζω να ζητείται να γίνει ώθηση 5 αριθμών σε μια στοίβα και απώθηση τους στη συνέχεια.
Εμένα αυτό που με προβληματίζει και σε σχέση με τη συζήτηση που γίνεται εδώ είναι η εξής παρατήρηση από τη διδακτέα-εξεταστέα ύλη:

"Να προστεθούν ασκήσεις στη στοίβα και ουρά που επίσης θα υλοποιηθούν απ'ευθείας σε ΓΛΩΣΣΑ και με την πρόσθεση της ενότητας 3.9 που θα διδαχθεί."

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

"Οι δυναμικές δομές της ενότητας 3.9 (λίστες, δένδρα, γράφοι) να διδαχθούν αποκλειστικά ως θεωρία."
Μήπως λοιπόν οι δυναμικές δομές διδαχθούν θεωρητικά μόνο και ασκήσεις σε αυτές θα γίνουν μόνο για τη στοίβα και την ουρά;
Αν είναι έτσι βέβαια, τότε η υλοποίηση της στοίβας και της ουράς με πίνακα στο 3ο κεφάλαιο δε θα συμφωνεί με τις ασκήσεις.
Νομίζω λοιπόν ότι χρειάζονται απαραίτητα διευκρινήσεις για τις παρατηρήσεις και δε μπορούμε να βγάλουμε σίγουρα συμπεράσματα τώρα. Αν δε διευκρινιστούν αυτά δε μπορούμε να σκεφτόμαστε ασκήσεις.

[Πέτρος Κ.]

Λύνεται απλά χωρίς τις λειτουργίες της στοίβας. Θα ήταν καλύτερα νομίζω να ζητείται να γίνει ώθηση 5 αριθμών σε μια στοίβα και απώθηση τους στη συνέχεια.

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

[petrosp13]

Δεν θα την δηλώσουμε σαν πίνακα;;;

[Diotima]

Αυτό δε μπορώ να καταλάβω Πέτρο:

"Να προστεθούν ασκήσεις στη στοίβα και ουρά που επίσης θα υλοποιηθούν απ'ευθείας σε ΓΛΩΣΣΑ και με την πρόσθεση της ενότητας 3.9 που θα διδαχθεί."

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

[petrosp13]

Μάλλον λάθος διατύπωση θα έλεγα

[Diotima]

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

[Diotima]

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

ΠΡΟΓΡΑΜΜΑ ΠΕΝΤΕ_ΑΡΙΘΜΟΙ_ΣΕ_ΣΤΟΙΒΑ
ΜΕΤΑΒΛΗΤΕΣ
   ΑΚΕΡΑΙΕΣ: Stack[100], i, top, number, item
   ΛΟΓΙΚΕΣ: done
ΑΡΧΗ
   top <-- 0
   ΓΙΑ i ΑΠΟ 1 ΜΕΧΡΙ 5
      ΔΙΑΒΑΣΕ number
      ΚΑΛΕΣΕ ΩΘΗΣΗ (Stack, number, top, done)
   ΤΕΛΟΣ_ΕΠΑΝΑΛΗΨΗΣ
   ΓΙΑ i ΑΠΟ 1 ΜΕΧΡΙ 5
      ΚΑΛΕΣΕ ΑΠΩΘΗΣΗ (Stack, item, top, done)
      ΓΡΑΨΕ item
   ΤΕΛΟΣ_ΕΠΑΝΑΛΗΨΗΣ
ΤΕΛΟΣ_ΠΡΟΓΡΑΜΜΑΤΟΣ

ΔΙΑΔΙΚΑΣΙΑ ΩΘΗΣΗ (Stack, item, top, done)
ΜΕΤΑΒΛΗΤΕΣ
   ΑΚΕΡΑΙΕΣ: Stack[100], item, top
   ΛΟΓΙΚΕΣ: done
ΑΡΧΗ
   ΑΝ top < 100 ΤΟΤΕ
      top <-- top + 1
      Stack[top] <-- item
      done <-- ΑΛΗΘΗΣ
   ΑΛΛΙΩΣ
      done <-- ΨΕΥΔΗΣ
   ΤΕΛΟΣ_ΑΝ
ΤΕΛΟΣ_ΔΙΑΔΙΚΑΣΙΑΣ

ΔΙΑΔΙΚΑΣΙΑ ΑΠΩΘΗΣΗ (Stack, item, top, done)
ΜΕΤΑΒΛΗΤΕΣ
   ΑΚΕΡΑΙΕΣ: Stack[100], item, top
   ΛΟΓΙΚΕΣ: done
ΑΡΧΗ
   ΑΝ top <> 0 ΤΟΤΕ    ! ή top > = 1
      item <-- Stack[top]
      top <-- top - 1
      done <-- ΑΛΗΘΗΣ
   ΑΛΛΙΩΣ
      done <-- ΨΕΥΔΗΣ
   ΤΕΛΟΣ_ΑΝ
ΤΕΛΟΣ_ΔΙΑΔΙΚΑΣΙΑΣ

[Diotima]

Επισυνάπτω ένα αρχείο με την πρώτη και δεύτερη άσκηση που έγραψα που είναι αυτή:
α) Να γράψετε πρόγραμμα που θα διαβάζει 10 ακεραίους αριθμούς και θα κάνει εισαγωγή των αριθμών σε μια ουρά 10 θέσεων, στη συνέχεια να εξαχθούν 6 αριθμοί οι οποίοι θα εμφανίζονται με τη σειρά που εξάγονται και να εισαχθούν άλλοι 3 ακέραιοι αριθμοί.
Να εμφανιστούν κατά σειρά οι αριθμοί που βρίσκονται στο τέλος μέσα στην ουρά.
β) Το πρόγραμμα θα καλεί τις διαδικασίες ΕΙΣΑΓΩΓΗ και ΕΞΑΓΩΓΗ που θα υλοποιούν τις αντίστοιχες λειτουργίες της ουράς τις οποίες και θα γράψετε. Αν η ουρά γεμίσει αλλά έχει άδειες θέσεις μπροστά, τότε να μεταφέρονται τα στοιχεία που βρίσκονται στην ουρά μπροστά ώστε να συνεχίζεται η διαδικασία της εισαγωγής.
Θα επιστρέφονται από τις διαδικασίες οι λογικές τιμές ΑΛΗΘΗΣ ή ΨΕΥΔΗΣ αναλόγως αν η εισαγωγή ή η εξαγωγή στοιχείου στην ουρά έγιναν επιτυχώς ή όχι.

[tdrivas]

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

[Πέτρος Κ.]

ΠΡΟΓΡΑΜΜΑ ΠΕΝΤΕ_ΑΡΙΘΜΟΙ_ΣΕ_ΣΤΟΙΒΑ
ΜΕΤΑΒΛΗΤΕΣ
	ΑΚΕΡΑΙΕΣ: Stack[100], i, top, number, item
	ΛΟΓΙΚΕΣ: done
ΑΡΧΗ
	top <-- 0
	ΓΙΑ i ΑΠΟ 1 ΜΕΧΡΙ 5
		ΔΙΑΒΑΣΕ number
		ΚΑΛΕΣΕ ΩΘΗΣΗ (Stack, number, top, done)
	ΤΕΛΟΣ_ΕΠΑΝΑΛΗΨΗΣ
	ΓΙΑ i ΑΠΟ 1 ΜΕΧΡΙ 5
		ΚΑΛΕΣΕ ΑΠΩΘΗΣΗ (Stack, item, top, done)
		ΓΡΑΨΕ item
	ΤΕΛΟΣ_ΕΠΑΝΑΛΗΨΗΣ
ΤΕΛΟΣ_ΠΡΟΓΡΑΜΜΑΤΟΣ

Έχω τους εξής προβληματισμούς για το παραπάνω:

1. Είναι σωστό να έχω πρόσβαση στην top μέσα στο κυρίως πρόγραμμα; Αν μέσα στο κυρίως πρόγραμμα ένας μαθητής γράψει top <-- top -1 θα το θεωρήσουμε λάθος;

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

ΓΙΑ i ΑΠΟ 1 ΜΕΧΡΙ 5
	ΓΡΑΨΕ Stack[i]
ΤΕΛΟΣ_ΕΠΑΝΑΛΗΨΗΣ

[ether]

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

ΔΙΑΔΙΚΑΣΙΑ εισαγωγη(ουρα, εμπρος, πισω, στοιχειο, εγινε) 
ΣΤΑΘΕΡΕΣ
  ΧΩΡΗΤΙΚΟΤΗΤΑ_ΟΥΡΑΣ = 3
ΜΕΤΑΒΛΗΤΕΣ
  ΧΑΡΑΚΤΗΡΕΣ: ουρα[ΧΩΡΗΤΙΚΟΤΗΤΑ_ΟΥΡΑΣ], στοιχειο
  ΑΚΕΡΑΙΕΣ: εμπρος, πισω
  ΛΟΓΙΚΕΣ: εγινε
ΑΡΧΗ
  ΑΝ ειναιΓεματηΟυρα(εμπρος, πισω, ΧΩΡΗΤΙΚΟΤΗΤΑ_ΟΥΡΑΣ) ΤΟΤΕ
    εγινε <- ΨΕΥΔΗΣ
  ΑΛΛΙΩΣ
    πισω <- (πισω mod ΧΩΡΗΤΙΚΟΤΗΤΑ_ΟΥΡΑΣ) + 1
    ουρα[πισω] <- στοιχειο
    ΑΝ ειναιΑδειαΟυρα(εμπρος, πισω, ΧΩΡΗΤΙΚΟΤΗΤΑ_ΟΥΡΑΣ) ΤΟΤΕ
      εμπρος <- πισω
    ΤΕΛΟΣ_ΑΝ
    εγινε <- ΑΛΗΘΗΣ
  ΤΕΛΟΣ_ΑΝ
ΤΕΛΟΣ_ΔΙΑΔΙΚΑΣΙΑΣ


ΔΙΑΔΙΚΑΣΙΑ εξαγωγη(ουρα, εμπρος, πισω, στοιχειο, εγινε) 
ΣΤΑΘΕΡΕΣ
  ΧΩΡΗΤΙΚΟΤΗΤΑ_ΟΥΡΑΣ = 3
ΜΕΤΑΒΛΗΤΕΣ
  ΧΑΡΑΚΤΗΡΕΣ: ουρα[ΧΩΡΗΤΙΚΟΤΗΤΑ_ΟΥΡΑΣ], στοιχειο
  ΑΚΕΡΑΙΕΣ: εμπρος, πισω
  ΛΟΓΙΚΕΣ: εγινε
ΑΡΧΗ
  ΑΝ ειναιΑδειαΟυρα(εμπρος, πισω, ΧΩΡΗΤΙΚΟΤΗΤΑ_ΟΥΡΑΣ) ΤΟΤΕ
    εγινε <- ΨΕΥΔΗΣ
  ΑΛΛΙΩΣ
    στοιχειο <- ουρα[εμπρος] 
    ΑΝ μεγεθοςΟυρας(εμπρος, πισω, ΧΩΡΗΤΙΚΟΤΗΤΑ_ΟΥΡΑΣ) = 1 ΤΟΤΕ
      εμπρος <- 0
      πισω <- 0
    ΑΛΛΙΩΣ
      εμπρος <- (εμπρος mod ΧΩΡΗΤΙΚΟΤΗΤΑ_ΟΥΡΑΣ) + 1
    ΤΕΛΟΣ_ΑΝ
    εγινε <- ΑΛΗΘΗΣ
  ΤΕΛΟΣ_ΑΝ
ΤΕΛΟΣ_ΔΙΑΔΙΚΑΣΙΑΣ


ΣΥΝΑΡΤΗΣΗ μεγεθοςΟυρας(εμπρος, πισω, χωρητικοτητα): ΑΚΕΡΑΙΑ
ΜΕΤΑΒΛΗΤΕΣ
  ΑΚΕΡΑΙΕΣ: εμπρος, πισω, χωρητικοτητα
ΑΡΧΗ
  ΑΝ εμπρος = 0 ΤΟΤΕ
    μεγεθοςΟυρας <- 0
  ΑΛΛΙΩΣ_ΑΝ πισω >= εμπρος ΤΟΤΕ
    μεγεθοςΟυρας <- πισω - εμπρος + 1
  ΑΛΛΙΩΣ
    μεγεθοςΟυρας <- πισω + χωρητικοτητα - εμπρος + 1
  ΤΕΛΟΣ_ΑΝ
ΤΕΛΟΣ_ΣΥΝΑΡΤΗΣΗΣ


ΣΥΝΑΡΤΗΣΗ ειναιΑδειαΟυρα(εμπρος, πισω, χωρητικοτητα): ΛΟΓΙΚΗ
ΜΕΤΑΒΛΗΤΕΣ
  ΑΚΕΡΑΙΕΣ: εμπρος, πισω, χωρητικοτητα
ΑΡΧΗ
  ειναιΑδειαΟυρα <- μεγεθοςΟυρας(εμπρος, πισω, χωρητικοτητα) = 0
ΤΕΛΟΣ_ΣΥΝΑΡΤΗΣΗΣ


ΣΥΝΑΡΤΗΣΗ ειναιΓεματηΟυρα(εμπρος, πισω, χωρητικοτητα): ΛΟΓΙΚΗ
ΜΕΤΑΒΛΗΤΕΣ
  ΑΚΕΡΑΙΕΣ: εμπρος, πισω, χωρητικοτητα
ΑΡΧΗ
  ειναιΓεματηΟυρα <- μεγεθοςΟυρας(εμπρος, πισω, χωρητικοτητα) = χωρητικοτητα
ΤΕΛΟΣ_ΣΥΝΑΡΤΗΣΗΣ

[Diotima]

@ Πέτρος Κ.
Στη ΓΛΩΣΣΑ όταν εκτελείται ένα πρόγραμμα στα μόνα που έχει πρόσβαση είναι οι μεταβλητές του προγράμματος. Γενικά έχουμε μόνο τοπικές μεταβλητές.
Στην άσκηση αυτή το ίδιο το πρόγραμμα δημιουργεί τον πίνακα Stack, είναι δικός του πίνακας. Την ώρα που καλεί τις διαδικασίες ΩΘΗΣΗ ή ΑΠΩΘΗΣΗ, εκείνη ακριβώς τη στιγμή, δεσμεύεται χώρος για τις παραμέτρους των διαδικασιών και για όλες τις μεταβλητές τους. Δηλαδή όταν ξεκινάει η εντολή ΚΑΛΕΣΕ ΩΘΗΣΗ (Stack, number, top, done) οι τιμές των παραμέτρων που έχει αυτή η ΚΑΛΕΣΕ (και οι οποίες είναι μεταβλητές του προγράμματος) μεταφέρονται στις αντίστοιχες παραμέτρους της διαδικασίας ΩΘΗΣΗ(Stack, item, top, done) οι οποίες είναι διαφορετικές μεταβλητές εκείνη την ώρα από τις παραμέτρους κλήσης του προγράμματος, ας συμπίπτουν τα ονόματα κάποιων. Όσο εκτελείται η διαδικασία έχουμε δύο πίνακες Stack στη μνήμη, έναν του προγράμματος και έναν της διαδικασίας. Όταν τελειώσει η διαδικασία ΩΘΗΣΗ οι τιμές των δικών της τοπικών μεταβλητών-παραμέτρων επιστρέφονται με αντιστοίχηση κατά σειρά στις παραμέτρους του προγράμματος και στη συνέχεια αποδεσμεύεται η μνήμη από όλες τις μεταβλητές της διαδικασίας, οπότε αυτές χάνονται. Έτσι λειτουργούν οι παράμετροι στη ΓΛΩΣΣΑ. Οπότε η τιμή της top αλλά και η ίδια η στοίβα Stack για να διατηρούν τις τιμές τους καθ' όλη τη διάρκεια εκτέλεσης του προγράμματος πρέπει να ανήκουν στο πρόγραμμα. Ένα υποπρόγραμμα δε μπορεί να διατηρήσει τις τιμές των μεταβλητών του στη μνήμη, διότι αυτές χάνονται όταν τελειώνει η εκτέλεση του.
Προφανώς και μπορεί να επηρεαστεί λοιπόν η τιμή της top μέσα στο πρόγραμμα αλλά αυτό θα μπορούσε να δημιουργήσει λάθος αποτέλεσμα στη λειτουργία του προγράμματος όσον αφορά τη χρήση της στοίβας που χρησιμοποιεί.
Αν το πρόγραμμα δεν είχε πρόσβαση στην top τότε οι διαδικασίες δε θα ήξεραν την τιμή της κάθε φορά που γίνεται μια νέα κλήση τους.
Πολύ κατατοπιστική πάνω στις ερωτήσεις σου είναι η παράγραφος 10.5.3 του σχολικού βιβλίου.
Στην τελευταία ερώτηση όχι, γιατί να είναι λάθος, μπορεί να ζητείται και ως ερώτημα από μια άσκηση. Όπως είπα πριν ο πίνακας Stack είναι πίνακας του προγράμματος.

[tasospap]

Ωραία όλα αυτά που λέτε παραπάνω. Αλλά ξέρετε πως ηχούν στα αυτιά ενός μαθητή 17 χρονών;

Σαν τις δηλώσεις του αντιπροέδρου του Εδεσσαϊκού!

[tsak]

Ωραία όλα αυτά που λέτε παραπάνω. Αλλά ξέρετε πως ηχούν στα αυτιά ενός μαθητή 17 χρονών;

Σαν τις δηλώσεις του αντιπροέδρου του Εδεσσαϊκού!

Πιο ευστοχη απαντηση δεν θα μπορουσε να δοθει!

Εαν πρωτα δεν διευκρινιστει τουλαχιστον για την ουρα, αν θα χρησιμοποιησουμε την λογικη του βιβλιου μαθητη ή αυτην του βιβλιου καθηγητη, νομιζω οτι ουτε σε ασκησεις μπορουμε να προχωρησουμε. Εδω εχουμε μπλοκαρει εμεις και θα παμε να  περασουμε τα περι κυκλικης ουρας στους μαθητες? Και μαλιστα σε ενα κοινο πλεον πιο αδυνατο σε σχεση με αλλες χρονιες 

[Diotima]

ΠΡΟΓΡΑΜΜΑ ΠΕΝΤΕ_ΑΡΙΘΜΟΙ_ΣΕ_ΣΤΟΙΒΑ
ΜΕΤΑΒΛΗΤΕΣ
	ΑΚΕΡΑΙΕΣ: Stack[100], i, top, number, item
	ΛΟΓΙΚΕΣ: done
ΑΡΧΗ
	top <-- 0
	ΓΙΑ i ΑΠΟ 1 ΜΕΧΡΙ 5
		ΔΙΑΒΑΣΕ number
		ΚΑΛΕΣΕ ΩΘΗΣΗ (Stack, number, top, done)
	ΤΕΛΟΣ_ΕΠΑΝΑΛΗΨΗΣ
	ΓΙΑ i ΑΠΟ 1 ΜΕΧΡΙ 5
		ΚΑΛΕΣΕ ΑΠΩΘΗΣΗ (Stack, item, top, done)
		ΓΡΑΨΕ item
	ΤΕΛΟΣ_ΕΠΑΝΑΛΗΨΗΣ
ΤΕΛΟΣ_ΠΡΟΓΡΑΜΜΑΤΟΣ

Έχω τους εξής προβληματισμούς για το παραπάνω:

1. Είναι σωστό να έχω πρόσβαση στην top μέσα στο κυρίως πρόγραμμα; Αν μέσα στο κυρίως πρόγραμμα ένας μαθητής γράψει top <-- top -1 θα το θεωρήσουμε λάθος;

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

ΓΙΑ i ΑΠΟ 1 ΜΕΧΡΙ 5
	ΓΡΑΨΕ Stack[i]
ΤΕΛΟΣ_ΕΠΑΝΑΛΗΨΗΣ

Οι ερωτήσεις σου για μη πρόσβαση στην top και στον πίνακα Stack με προβλημάτισαν και έδωσα την εξής λύση ώστε να μην υπάρχει πρόσβαση από το πρόγραμμα.
Μετατρέπω το πρόγραμμα σε διαδικασία με τον ίδιο κώδικα και παράμετρο τη done:

ΔΙΑΔΙΚΑΣΙΑ ΠΕΝΤΕ_ΑΡΙΘΜΟΙ_ΣΕ_ΣΤΟΙΒΑ(done)

και γράφω το πρόγραμμα:

ΠΡΟΓΡΑΜΜΑ ΧΡΗΣΗ_ΣΤΟΙΒΑΣ
ΜΕΤΑΒΛΗΤΕΣ
  ΛΟΓΙΚΕΣ: flag
ΑΡΧΗ
  ΚΑΛΕΣΕ ΠΕΝΤΕ_ΑΡΙΘΜΟΙ_ΣΕ_ΣΤΟΙΒΑ(flag)
  ΑΝ  flag=ΑΛΗΘΗΣ ΤΟΤΕ                 
    ΓΡΑΨΕ 'Όλα Οk!'                     
  ΑΛΛΙΩΣ
    ΓΡΑΨΕ 'Υπήρξε πρόβλημα στη στοίβα!'
  ΤΕΛΟΣ_ΑΝ                                     
ΤΕΛΟΣ_ΠΡΟΓΡΑΜΜΑΤΟΣ

οπότε εκτελούνται τα ίδια και το πρόγραμμα δεν έχει πρόσβαση ούτε στην top ούτε στον πίνακα Stack. Μπορεί τελικά να πρέπει να διδάξουμε ασκήσεις με αυτή τη λογική;;;; Ίδωμεν!

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

[Rathaniel]

H κυκλική διαχείριση ουράς, είναι εκτός τόπου και χρόνου (θα έλεγα και εκτός ύλης) για μαθητές Γ' Λυκείου.
Το πιθανότερο είναι ένας πίνακας σταθερού μεγάλου μεγέθους με ασ πούμε όριο μεγέθους ουράς 20 στοιχεία.
Τουλάχιστον σύμφωνα με την θεωρία του βιβλίου μαθητή.

[Diotima]

H κυκλική διαχείριση ουράς, είναι εκτός τόπου και χρόνου (θα έλεγα και εκτός ύλης) για μαθητές Γ' Λυκείου.
Το πιθανότερο είναι ένας πίνακας σταθερού μεγάλου μεγέθους με ασ πούμε όριο μεγέθους ουράς 20 στοιχεία.
Τουλάχιστον σύμφωνα με την θεωρία του βιβλίου μαθητή.

Στο ότι η κυκλική διαχείριση της ουράς είναι πολύ δύσκολη για ένα μαθητή της Γ' Λυκείου συμφωνώ απόλυτα. Επίσης δύσκολη για ένα μαθητή της Γ' Λυκείου είναι όλη η επιπρόσθετη ύλη που μπήκε με τους επιπλέον αλγορίθμους ταξινόμησης, αναζήτησης, η θεωρία πολυπλοκότητας αλγορίθμων κ.τ.λ. Όχι ότι δε συμφωνώ με την αναβάθμιση της ύλης του μαθήματος. Αυτό όμως που θα έλεγα ότι είναι εκτός τόπου και χρόνου είναι το σχολικό δίωρο φέτος με το οποίο αυτή η ύλη δε βγαίνει με τίποτα  όπως επίσης εκτός τόπου και χρόνου είναι και το μονόωρο της Β'.
Όσον αφορά τις ασκήσεις που παραθέτουμε εδώ, νομίζω ότι αυτό είναι το όνομα του θέματος που συζητείται, "Ασκήσεις σε στοίβα και ουρά" και δυστυχώς αυτή τη στιγμή βαδίζουμε στα τυφλά περιμένοντας οδηγίες και επιπλέον σημειώσεις που δεν ξέρουμε  πότε θα έρθουν. Και έχουμε και την οδηγία να είναι οι ασκήσεις προγράμματα σε ΓΛΩΣΣΑ και όχι ψευδογλώσσα που έχει το βιβλίο του καθηγητή.
Θέλω να πιστεύω ότι ακολουθώ τουλάχιστον το βιβλίο του μαθητή που είναι για μένα το πιο σημαντικό που έχω στα χέρια μου (και όχι το βιβλίο του καθηγητή που έχει και πολλά λάθη).
Με βάση λοιπόν τη σελίδα 62 που είναι η σχετική βλέπω ότι γράφει:

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

Δε μου διευκρινίζει αν ο ελεύθερος χώρος που πρέπει να ελέγχεται αν υπάρχει για την εισαγωγή, είναι στο πίσω μέρος του πίνακα, αλλά αν είναι στον πίνακα.
Και ελεύθερος χώρος δεν υπάρχει στον πίνακα για εισαγωγή, μόνο όταν είναι γεμάτος από την πρώτη μέχρι και την τελευταία θέση.
Γι αυτό και ασχολήθηκα με τέτοια άσκηση και όχι για να περάσω όπως κάποιος έγραψε παραπάνω τα περί κυκλικής ουράς στους μαθητές.
Ποιος μαθητής της Γ' μπορεί να παρακολουθήσει αυτή τη στιγμή τέτοιες ασκήσεις;
Μπορείτε εσείς σας παρακαλώ να μου υποδείξετε ποια σελίδα και παράγραφος του σχολικού σας παραπέμπει στο "εκτός ύλης" για να τη δω καλύτερα;

[tsak]

Με βάση λοιπόν τη σελίδα 62 που είναι η σχετική βλέπω ότι γράφει:

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

Δε μου διευκρινίζει αν ο ελεύθερος χώρος που πρέπει να ελέγχεται αν υπάρχει για την εισαγωγή, είναι στο πίσω μέρος του πίνακα, αλλά αν είναι στον πίνακα.
Και ελεύθερος χώρος δεν υπάρχει στον πίνακα για εισαγωγή, μόνο όταν είναι γεμάτος από την πρώτη μέχρι και την τελευταία θέση.
Γι αυτό και ασχολήθηκα με τέτοια άσκηση και όχι για να περάσω όπως κάποιος έγραψε παραπάνω τα περί κυκλικής ουράς στους μαθητές.
Ποιος μαθητής της Γ' μπορεί να παρακολουθήσει αυτή τη στιγμή τέτοιες ασκήσεις;
Μπορείτε εσείς σας παρακαλώ να μου υποδείξετε ποια σελίδα και παράγραφος του σχολικού σας παραπέμπει στο "εκτός ύλης" για να τη δω καλύτερα;

Τουλάχιστον σ' αυτό νομίζω είναι ξεκάθαρα τα πράγματα. Οι μαθητές διδάσκονται την στατική ουρά και για τα εισαγωγή/εξαγωγή λέει:
"Για την εισαγωγή ενός νέου στοιχείου στην ουρά αυξάνεται ο δείκτης rear κατά ένα και στη θέση αυτή αποθηκεύεται το στοιχείο. Αντίστοιχα για τη λειτουργία της εξαγωγής, εξέρχεται το στοιχείο που δείχνει ο δείκτης front, ο οποίος στη συνέχεια αυξάνεται κατά ένα, για να δείχνει το επόμενο στοιχείο που πρόκειται να εξαχθεί".

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

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

[ether]

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

[tsak]

Μία άσκηση και από εμένα με ουρά. Δεκτά οποιαδήποτε σχόλια.

[tsak]

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

"Κλέβω" και την παραπάνω άσκηση του συναδέλφου τροποποιώντας την μερικώς για την αντιμετώπιση και άλλων σεναρίων. Παραθέτω και τη λύση της.

[ether]

Συνημμένη η ιδέα των συναδέλφων στην περίπτωση που μπορεί να έχουμε τρία είδη παρενθέσεων () [] {}

[tsak]

Συνημμένη η ιδέα των συναδέλφων στην περίπτωση που μπορεί να έχουμε τρία είδη παρενθέσεων () [] {}

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

[ether]

Εγώ σκέφτομαι να μην τους κάνω προγραμματιστικές ασκήσεις σε στοίβα και ουρά πριν κάνουμε τα υποπρογράμματα.

[Rathaniel]

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

Όταν το μάθημα το "κονσερβοποιούμε" δεν έχουμε καλά αποτελέσματα στις εξετάσεις, και γενικά είναι κακό και για το μάθημα.
Είναι καλό να διδαχθούν πως να γεμίζουν-αδείαζουν τις στοίβες/ουρές και χωρίς υποπρογράμματα στην αρχή.Ακόμα και με μικρές προεκτάσεις-παραλλαγές θα βοηθήσει τον μαθητή (π.χ. να βγαίνουν δύο-δυο τα στοιχεία της στοίβας)

Φυσικά μετά θα γίνει και με υποπρογράμματα.

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

[petrosp13]

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

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

[ether]

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

Όταν το μάθημα το "κονσερβοποιούμε" δεν έχουμε καλά αποτελέσματα στις εξετάσεις, και γενικά είναι κακό και για το μάθημα.
Είναι καλό να διδαχθούν πως να γεμίζουν-αδείαζουν τις στοίβες/ουρές και χωρίς υποπρογράμματα στην αρχή.Ακόμα και με μικρές προεκτάσεις-παραλλαγές θα βοηθήσει τον μαθητή (π.χ. να βγαίνουν δύο-δυο τα στοιχεία της στοίβας)

Φυσικά μετά θα γίνει και με υποπρογράμματα.

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

Κονσερβοποίηση και κακό για το μάθημα η χρήση υποπρογραμμάτων για τις λειτουργίες στοίβας και ουράς;
Διαφωνώ πλήρως.
Κατά τη γνώμη μου, αυτό είναι η ουσία του μαθήματος.
Κατά τη γνώμη μου, όταν καλείται να λύσει ένα πρόβλημα ο μαθητής (και ο καθένας), όχι μόνο δεν είναι κονσερβοποίηση του μαθήματος το να σκέφτεται και να εκφράζεται με έννοιες ώθησης, απώθησης, είναι άδεια η στοίβα, είναι γεμάτη η στοίβα, αντί του να σκέφτεται αυξάνω τον top κατά ένα, μειώνω τον top κατά ένα, αν top = 0, αν top = size, αλλά είναι ο ενδεδειγμένος τρόπος σκέψης, σύμφωνα και με τις επικρατούσες αρχές του δομημένου προγραμματισμού αλλά και της τεχνολογίας λογισμικού. Άλλωστε, το design to interfaces, not implementations, θεωρείται εδώ και πολύ καιρό ως καλή πρακτική στη σχεδίαση και υλοποίηση αλγορίθμων. Αυτό διδάσκεται στα σχετικά μαθήματα στα πανεπιστήμια, αυτό χρησιμοποιείται συνήθως και στον πραγματικό κόσμο.

Τα αυξάνω τον top κατά ένα, μειώνω τον top κατά ένα, αν top = 0, αν top = size, πρέπει να τα ξέρει και να τα σκέφτεται για να υλοποιήσει τις λειτουργίες. Όταν καλείται όμως να αντιμετωπίσει ένα μη τετριμμένο πρόβλημα (δηλαδή ένα πρόβλημα που δεν του ζητάει απλώς να βάλει κάποια στοιχεία στη δομή και να τα βγάλει απ' αυτήν), καλύτερα είναι να σχεδιάζει τον αλγόριθμό του ως χρήστη (client) αυτών των λειτουργιών.

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

Δεν καταλαβαίνω γιατί έχει μεγαλύτερη αξία το "γεμίζω και αδειάζω τη στοίβα χωρίς υποπρογράμματα" από το "γράφω τα υποπρογράμματα για την ώθηση και την απώθηση και μετά τα χρησιμοποιώ". Το αντίθετο μάλιστα: όπως ανέφερα παραπάνω, το δεύτερο το θεωρώ πολύ καλύτερο. Είναι σα να λες ότι κάθε φορά που θες στο πρόγραμμά σου να υπολογίζεις την τετραγωνική ρίζα ενός αριθμού, είναι καλύτερα να γράφεις τις 5-6 εντολές ενός αλγορίθμου υπολογισμού τετραγωνικής ρίζας από το να χρησιμοποιείς τη συνάρτηση Τ_Ρ (ή αν δεν υπήρχε έτοιμη, από το να την υλοποιήσεις και να τη χρησιμοποιείς καλώντας την). Είναι επίσης σα να λες ότι, αφού οι δομές επιλογής και επανάληψης που γράφουμε στις γλώσσες υψηλού επιπέδου τελικά στη γλώσσα μηχανής υλοποιούνται με GOTO, είναι κονσερβοποίηση και τυφλοσούρτης να τις γράφουμε στη γλώσσα υψηλού επιπέδου όπως τις γράφουμε σύμφωνα με τις αρχές του δομημένου προγραμματισμού, και είναι προτιμότερο να χρησιμοποιούμε και στις γλώσσες υψηλού επιπέδου GOTO. Οι ώθηση, απώθηση, είναιΆδεια, είναιΓεμάτη, μου επιτρέπουν, όταν καλούμαι να αντιμετωπίσω ένα πρόβλημα, να σκέφτομαι και να εκφράζομαι σε υψηλότερο επίπεδο αφαίρεσης από τα αυξάνω τον top κατά ένα, μειώνω τον top κατά ένα, αν top = 0, αν top = size, όπως οι ΑΝ, ΟΣΟ, κτλ μου επιτρέπουν να σκέφτομαι και να εκφράζομαι σε υψηλότερο επίπεδο αφαίρεσης απ'  ότι η GOTO.

Αν στην εκφώνηση δε λέει να γίνει με υποποπρογράμματα και ο μαθητής το κάνει με υποπρογράμματα να κοπούν μοναδούλες; Δε φαντάζομαι να το λες σοβαρά.

[Rathaniel]

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

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

[ether]

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

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

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

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

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

[tsak]

Νομιζω οτι η κοινη λογικη υπαγορευει οταν εξηγεις μια νεα ενοτητα, το αμεσα επομενο βημα ειναι να δωσεις μια-δυο ασκησεις τουλαχιστον για την εμπεδωση και εφαρμογη των διδαχθεντων.Οποτε αφου προηγειται χρονικα η μελετη του 3ου κεφαλαιου, λογικο ειναι να δωθει ασκηση χωρις υποππρογραμμα σε ουρα και στοιβα.Και φυσικα επεται η επαναληψη αυτων και στα υποπρογραμματα.

[ether]

Νομιζω οτι η κοινη λογικη υπαγορευει οταν εξηγεις μια νεα ενοτητα, το αμεσα επομενο βημα ειναι να δωσεις μια-δυο ασκησεις τουλαχιστον για την εμπεδωση και εφαρμογη των διδαχθεντων.Οποτε αφου προηγειται χρονικα η μελετη του 3ου κεφαλαιου, λογικο ειναι να δωθει ασκηση χωρις υποππρογραμμα σε ουρα και στοιβα.Και φυσικα επεται η επαναληψη αυτων και στα υποπρογραμματα.

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

Δεν μπορούμε να κάνουμε ό,τι κάναμε μέχρι πέρυσι κάνοντας το κεφάλαιο 3 (ούτως ή άλλως, ένα-δυο παραδείγματα νομίζω οι περισσότεροι τα δείχναμε, για το πώς υλοποιούνται σε ψευδογλώσσα οι λειτουργίες που περιγράφει με λόγια το βιβλίο), χωρίς να κάνουμε προγραμματιστικές ασκήσεις, και τις προγραμματιστικές ασκήσεις να τις κάνουμε αφού πούμε και το 10;

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

[ether]

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

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

Παρακολουθώ με προσοχή τα μηνύματα σε αυτό το θέμα και παρατηρώ ότι υπάρχει η τάση  υλοποίησης αλγορίθμων ΣΤΟΙΒΑΣ και ΟΥΡΑΣ  με υποπρογράμματα.

Γιατί να γίνεται αυτό; Μπορεί κάποιος να το εξηγήσει;

[petrosp13]

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

[itt]

Παρακολουθώ με προσοχή τα μηνύματα σε αυτό το θέμα και παρατηρώ ότι υπάρχει η τάση  υλοποίησης αλγορίθμων ΣΤΟΙΒΑΣ και ΟΥΡΑΣ  με υποπρογράμματα.

Γιατί να γίνεται αυτό; Μπορεί κάποιος να το εξηγήσει;

Γιατί έτσι το υλοποιείς σε όλες τις procedural γλώσσες  που μπορούν να υποστηρίξουν το ελάχιστο δυνατό encapsulation (à la C-struct ας πούμε) εδώ και ~30 χρόνια;

[tasospap]

Καλή φάση.... Θα πω σε λίγες μέρες στους τελειόφοιτους που έχω με μεταγραφή απο την θεωρητική, για procedural με ολίγη απο encapsulation......

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

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

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

[itt]

Καλή φάση.... Θα πω σε λίγες μέρες στους τελειόφοιτους που έχω με μεταγραφή απο την θεωρητική, για procedural με ολίγη απο encapsulation......

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

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

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

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

Κάτι άλλο που έχω παρατήρησει και μου κάνει εντύπωση, είναι πώς υποθέτουμε όλοι ότι οι μαθητές δεν μπορούν να γράφουν ένα ΚΑΛΕΣΕ StackPush(...) χωρίς να πεθαίνει ο εγκέφαλός τους, αλλά να καταλαβαίνουν θεωρήματα του ολοκληρωτικού λογισμού που γενικά δεν είναι και ιδιαίτερα intuitive.

[ether]

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

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

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

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

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

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

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

*
- Thomas Cormen, Charles Leiserson, Ronald Rivest and Cliff Stein: "Introduction to Algorithms", 3rd edition, MIT Press, 2009
- J. Kleinberg, E. Tardos: "Algorithm Design", Addison-Wesley, 2005
- S. Dasgupta, C. H. Papadimitriou, and U. V. Vazirani: "Algorithms", MacGraw-Hill, 2006
- R. Sedgewick, K. Wayne: "Algorithms", 4th edition, Addison-Wesley, 2011

[evry]

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

      stack.pop()

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

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

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

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

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

[ether]

Το γεγονός ότι κάποια πολύ καλά βιβλία χρησιμοποιούν τις λειτουργίες 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.

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

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

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

[Πέτρος Κ.]

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

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

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

Και για να το δώσω και με παράδειγμα. Όταν κάνεις αυτό:

ΚΑΛΕΣΕ pop(stack, top, value)

τότε μπορείς να κάνεις και αυτό (α):

ΓΡΑΨΕ stack[1]

και αυτό (β):

stack[4] <-- stack[1]

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

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

[evry]

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

Προφανώς σε μια γλώσσα σαν τη ΓΛΩΣΣΑ δεν μπορείς να έχεις την ενθυλάκωση και όλα τα άλλα καλά που θα θέλαμε να έχουμε, όπως δεν μπορούσες να τα έχεις ούτε στην 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

[itt]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[ether]

Δυστυχώς δεν έχω γίνει αντιληπτός. Για αυτό άλλωστε χρησιμοποίησα τον όρο απόκρυψη πληροφορίας (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]

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

Κανείς δεν το είπε; Τότε μάλλον πρέπει να πάω να κοιταχτώ.

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

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

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

Έχουν στόχο να μάθει ο αναγνώστης αυτό που πραγματεύονται. Νομίζω κι εμείς από εκεί ξεκινάμε.

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

Ευτυχώς συμφωνούμε και σε κάτι.

[itt]

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

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

[Diotima]

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

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

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

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

+1

[ether]

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

[ether]

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

[bugman]

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

[bugman]

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

[Rathaniel]

Νομίζω όμως ότι τέτοιες σπαζοκεφαλιές δεν μπορεί να γίνονται μαθήματα.

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

[bugman]

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

[itt]

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

Ο σωρός δεν έχει διευθύνσεις επιστροφής. Στον x86 η διεύθυνση επιστροφής περνάει ως το τελευταίο πράγμα στο stack κατά το function prolog. Γενικά για τον επεξεργαστή δεν υπάρχει καν η έννοια του heap, είναι ένα abstraction που υπάρχει σε επίπεδου λειτουργικού για να περιγράφουμε memory pools και που δεν έχει απολύτως καμια σχέση με τη δομή δεδομένων που αποκαλούμε σωρό. Σε επίπεδο assembly δεν υπάρχουν semantics για allocation μνήμης. Για παράδειγμα στα Windows το memory allocation περιλαμβάνει τρία πράγματα:

• τον allocator σε επίπεδο εφαρμογής, είτε του CRT είτε κάποιον custom που έχει στηθεί πάνω στο default process heap
• τον heap manager, font-end και back-end αναλόγως
• και εν τέλη τον virtual memory manager του λειτουργικού

που δεν έχουν να κάνουν σε τίποτα με assembly.

Δηλαδή ζητάει κανείς ένα γίγα και σιγά σιγά το παίρνει. Έτσι ξέρει ότι θα έχει κάποια στιγμή το μεγάλο κομμάτι συνεχόμενης μνήμης αλλά δεν θα το πάρει όλο αν δεν έχει πράμα να το γεμίσει. Αυτή είναι η στοίβα.

Όχι, δεν είναι αυτη η στοίβα. Η στοίβα ειναι private χώρος μνήμης, reserved και commited με lifo semantics για allocation/deletion που παραχωρείται σε κάθε thread. Αυτό που περιέγραψες εσύ είναι μάλλον (δεν εχω ιδέα τι έχεις μπλέξει στο μυαλό σου) ένα heap segment. Προφανώς και επίσης δεν θα εξηγούσες ποτέ σε κάνεναν τη στοίβα με το τι κάνει το λειτουργικό στα threads, οπότε δεν καταλαβαίνω γιατί έγραψες όλα αυτά που έγραψες.

[bugman]

Και εγώ επίσης δεν μπορώ να καταλάβω όλο αυτό το ακατάσχετο jargon που αράδιασες. Αλλά δικαίωμα του καθένα είναι να γράφει ότι θέλει.
Δεν σου αρέσει ο σωρός για διευθύνσεις επιστροφής αλλά είναι λες το τελευταίο που κάνει...και κάτι άλλα αμερικάνικα!!!!
Προφανώς όταν χρησιμοποιούμε Assembly δεν γράφουμε κώδικα για να παίζουμε με τους καταχωρητές αλλά χρειαζόμαστε μνήμη και αυτή την αποδίδει το λειτουργικό, διότι όπως είναι γνωστό η μνήμη δεν μοιράζεται σε πιάτα ή μερίδες στα προγράμματα αλλά όπως αναφέρεις το commit είναι η δεύσμευση που έγραψα. Και φυσικά το heap segment είναι το παραθυρόφυλλο του παραθύρου που κατά τη γνώμη σου δεν είναι παράθυρο. Αλλά νομίζω όταν μιλάω για το παραθυλόφυλλο κάνω αναφορά στο παράθυρο έτσι δεν είναι;
Αναφέρεσαι σε threads και άλλα άσχετα θέματα με το ζητούμενο...απλά μάλλον για να βαρύνεις την συζήτηση. Η υπόθεσή μου είναι απλή. Πρέπει κανείς να μαθαίνει την χρήση των διάφορων δομών, και όχι απλά να παίζει με αυτές με άσχετες ασκήσεις. Διότι αφενός δεν μαθαίνουν τίποτα, και αφετέρου το μόνο που δοκιμάζουν είναι την ψυχολογική κατάσταση του μαθητή. Ανάλογα με το πόσο ψυχάκιας είναι κάποιος μπορεί ή όχι να συνεχίσει..π.χ. να παίζει με Ώθηση και απώθηση για να βρεί αν σε ένα αλφαριθμητικό έχουμε εντάξει τις αριστερές με τις δεξιές παρενθέσεις..(Από εκεί φρίκαρα)...
Εντάξει είμαι και εγώ της γνώμης ότι αν κάτι γίνεται με έναν τρόπο τότε είναι και αυτός σωστός. Όμως στη τελική δεν γίνεται να εμπλουτίζεις με "δύσκολα" κάτι που γίνεται με εύκολο τρόπο.
Δεν έχω διάθεση για αέανη αντιπαράθεση, κ. itt. Προφανώς μου αρέσει να μπλέκω με το μυαλό μου...και να ασχολούμε τα τελευταία τριάντα χρόνια με την πληροφορική.

Επειδή μου αρέσουν και οι αναφορές (είναι καθαρά θέμα επιστήμης)
1. Η εντολή RET του x86 http://x86.renejeschke.de/html/file_module_x86_id_280.html
Διαβάζουμε επιπλέον: The optional source operand specifies the number of stack bytes to be released after the return address is popped; Τι δεν καταλαβαίνουμε από το popped της διεύθυνσης επιστροφής;  Επίσης εδώ κατανοούμε ότι έχουμε και την δυνατότητα (optional) να απελευθερώσουμε ένα αριθμό τιμών στον σωρό που είχαμε δεσμεύσει (το λεγόμενο και stack frame) και χρησιμοποιείται για ότι θέλει ο προγραμματιστής, π.χ. για τοπικές μεταβλητές (μέσω δεικτών).
2. Από το εγχειρίδιο του MASM (Assembler)
http://flint.cs.yale.edu/cs422/doc/art-of-asm/pdf/CH08.PDF
Σελίδα 81 του PDF εμφανίζει τον τρόπο μέσω assembly που φτιάχνουμε πίνακες με δυναμική (δηλαδή μεταβαλλόμενη) δέσμευση μνήμης.  Ουσιαστικά δηλαδή όταν γράφουμε σε assembly δεν γράφουμε για να πάμε να δείξουμε πέντε γραμμές κώδικα που παίζουν με δυο τρεις καταχωρητές και το πολύ να στέλνουν και δυο χαρακτήρες στην κοσνόλα αλλά χρησιμοποιούμε τον υπολογιστή, την μνήμη του, τους δίσκους και όλα τα περιφερειακά μέσω του λειτουργικού.
Δυστυχώς πρέπει τα μαθήματα πληροφορικής να περάσουν σε επίπεδο εφαρμογής, να έχουν δηλαδή παρουσία πέρα από το χαρτί. Σε αυτό το σημείο σίγουρα βοηθούν εφαρμογές όπως αυτή του Διερμηνευτή της Γλώσσας. Όμως και αυτός έχει το κουσούρι της Γλώσσας, δηλαδή ανύπαρκτες εντολές για έξοδο και είσοδο.
Πόσα θέματα πληροφορικής εξηγούνται με τα γραφικά αλλά δεν μπορούν να έρθουν στην Γλώσσα γιατί δεν έχει γραφικά! Ακόμα και ο ΖΧ81 είχε γραφικά!!!!!!Έλεος

[itt]

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

Ποιο ειναι ακριβώς το ακατάσχετο jargon;

Δεν σου αρέσει ο σωρός για διευθύνσεις επιστροφής αλλά είναι λες το τελευταίο που κάνει...και κάτι άλλα αμερικάνικα!!!!

Ποιος σωρός;  Stack = Στοίβα, καταλαβαίνεις τι γράφεις; Μην προσπαθείς να ερμηνεύεις αυτά που γράφω όπως σου κατέβει. Όταν φτιάχνεις το function prolog (κάνε αναζήτηση στο google άμα είσαι τόσο άσχετος με την ορολογία) κάνεις implicitly push με το call τη διεύθυνση της επόμενης εντολής στο STACK και κάνεις expliticly pop και jmp με το ret σε αυτήν την διεύθυνση από τη συνάρτηση.

Προφανώς όταν χρησιμοποιούμε Assembly δεν γράφουμε κώδικα για να παίζουμε με τους καταχωρητές αλλά χρειαζόμαστε μνήμη και αυτή την αποδίδει το λειτουργικό, διότι όπως είναι γνωστό η μνήμη δεν μοιράζεται σε πιάτα ή μερίδες στα προγράμματα αλλά όπως αναφέρεις το commit είναι η δεύσμευση που έγραψα. Και φυσικά το heap segment είναι το παραθυρόφυλλο του παραθύρου που κατά τη γνώμη σου δεν είναι παράθυρο. Αλλά νομίζω όταν μιλάω για το παραθυλόφυλλο κάνω αναφορά στο παράθυρο έτσι δεν είναι;

Τρικυμία εν κρανίω. Όταν λες παραθυρόφυλλο μόνο εσύ ξέρεις τι λες.

Αναφέρεσαι σε threads και άλλα άσχετα θέματα με το ζητούμενο...απλά μάλλον για να βαρύνεις την συζήτηση.

Όχι δεν είνα καθόλου άσχετα. Δεν μπορείς να γράφεις για heap segement και να το βαπτίζεις stack επειδή έτσι γουστάρεις. Τo stack όταν μιλάμε στο επίπεδο του λειτουργικού είναι αυτό που έγραψα, όχι η μπαρούφα που πέταξες.

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

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

Επειδή μου αρέσουν και οι αναφορές (είναι καθαρά θέμα επιστήμης)
1. Η εντολή RET του x86 http://x86.renejeschke.de/html/file_module_x86_id_280.html
Διαβάζουμε επιπλέον: The optional source operand specifies the number of stack bytes to be released after the return address is popped; Τι δεν καταλαβαίνουμε από το popped της διεύθυνσης επιστροφής;  Επίσης εδώ κατανοούμε ότι έχουμε και την δυνατότητα (optional) να απελευθερώσουμε ένα αριθμό τιμών στον σωρό που είχαμε δεσμεύσει (το λεγόμενο και stack frame) και χρησιμοποιείται για ότι θέλει ο προγραμματιστής, π.χ. για τοπικές μεταβλητές (μέσω δεικτών).

"The optional source operand specifies the number of stack bytes to be released after the return address is popped". Καταλαβαίνεις τι ειναι το stack; Ποιος σωρός;

2. Από το εγχειρίδιο του MASM (Assembler)
http://flint.cs.yale.edu/cs422/doc/art-of-asm/pdf/CH08.PDF
Σελίδα 81 του PDF εμφανίζει τον τρόπο μέσω assembly που φτιάχνουμε πίνακες με δυναμική (δηλαδή μεταβαλλόμενη) δέσμευση μνήμης.  Ουσιαστικά δηλαδή όταν γράφουμε σε assembly δεν γράφουμε για να πάμε να δείξουμε πέντε γραμμές κώδικα που παίζουν με δυο τρεις καταχωρητές και το πολύ να στέλνουν και δυο χαρακτήρες στην κοσνόλα αλλά χρησιμοποιούμε τον υπολογιστή, την μνήμη του, τους δίσκους και όλα τα περιφερειακά μέσω του λειτουργικού.
Δυστυχώς πρέπει τα μαθήματα πληροφορικής να περάσουν σε επίπεδο εφαρμογής, να έχουν δηλαδή παρουσία πέρα από το χαρτί. Σε αυτό το σημείο σίγουρα βοηθούν εφαρμογές όπως αυτή του Διερμηνευτή της Γλώσσας. Όμως και αυτός έχει το κουσούρι της Γλώσσας, δηλαδή ανύπαρκτες εντολές για έξοδο και είσοδο.
Πόσα θέματα πληροφορικής εξηγούνται με τα γραφικά αλλά δεν μπορούν να έρθουν στην Γλώσσα γιατί δεν έχει γραφικά! Ακόμα και ο ΖΧ81 είχε γραφικά!!!!!!Έλεος

Ό,τι νανε.

Επίσης άμα σου αρέσουν τα references, να κάνεις cite το Developer Manual της Intel όχι κάποιο random γερμανικό site. Οπότε ακόμα δεν μου απάντησες. Γιατί τα έγραψες όλα αυτά;  Τι σχέση έχουν με το μάθημα και ειδικότερα με το thread που γράφουμε;

[bugman]

Το θέμα αν stack λέγεται σωρός ή στοίβα..είναι ένα θέμα που πρέπει να ξεκαθαριστεί. Προσωπικά λέω σωρό το Stack. και επειδή δεν είμαι ο Κουζινόπουλος Χάρης, εδώ λοιπόν άλλος κύριος γράφει ξεκάθαρα αυτό που λέω...ότι σωρός λέγεται το Stack. http://users.uom.gr/~ckouz/assembly/lesson7.pdf
Λες να το ανέβασα για να υποστηρίξω ντε μεκ τη γνώμη μου;
Σημασία έχει να αντιλαμβάνεσαι τι λεει ο άλλος. Αν λέει την στοίβα σωρό τότε δεν διαφωνείς με αυτό, ας το πει και πατάτα αρκεί να μιλάμε για το ίδιο πράγμα. Και όπως διαπίστωσα εννόησες πως το Stack το μπέρδεψα με το Heap...που το είδες αυτό; Το έγραψα ξεκάθαρα, με το παράδειγμα με τον χάρτη μνήμης, το heap έχει όλη τη μνήμη, o σωρός ή stack όπως το λέω εγώ έχει περιορισμένη μνήμη και έχει και διαφορετική λειτουργία.
Κάπου αναρωτιέσαι γιατί γράφω εδώ. Σωστά, μετά από τη συζήτησή μας το ίδιο αναρωτιέμαι και εγώ! Για το λόγο αυτό χαιρετώ, και εύχομαι να περάσουμε το μεσαίωνα της Ελληνικής Πληροφορικής, και ότι σχετίζεται με Ιερές Εξετάσεις...

[Rathaniel]

Νομίζω ότι χάνουμε το δάσος......

[itt]

Το θέμα αν stack λέγεται σωρός ή στοίβα..είναι ένα θέμα που πρέπει να ξεκαθαριστεί. Προσωπικά λέω σωρό το Stack. και επειδή δεν είμαι ο Κουζινόπουλος Χάρης, εδώ λοιπόν άλλος κύριος γράφει ξεκάθαρα αυτό που λέω...ότι σωρός λέγεται το Stack. http://users.uom.gr/~ckouz/assembly/lesson7.pdf
Λες να το ανέβασα για να υποστηρίξω ντε μεκ τη γνώμη μου;

Εσύ τώρα σοβαρά θες να μας βάλεις να αναφερόμαστε στο stack ως σωρό, ειδικά όταν μιλάμε για δομές δεδομένων, επειδή το λες εσύ και ένας ακαδημαϊκός σε ένα μάθημα 16μπιτης assembly;  Τι ακριβώς περιμένεις να σου απαντήσω;

Σημασία έχει να αντιλαμβάνεσαι τι λεει ο άλλος. Αν λέει την στοίβα σωρό τότε δεν διαφωνείς με αυτό, ας το πει και πατάτα αρκεί να μιλάμε για το ίδιο πράγμα. Και όπως διαπίστωσα εννόησες πως το Stack το μπέρδεψα με το Heap...που το είδες αυτό; Το έγραψα ξεκάθαρα, με το παράδειγμα με τον χάρτη μνήμης, το heap έχει όλη τη μνήμη, o σωρός ή stack όπως το λέω εγώ έχει περιορισμένη μνήμη και έχει και διαφορετική λειτουργία.

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

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

Κάτσε ρε Γιώργο γιατί θα μας τρελάνεις. Δεν μπορείς εσύ, που εδώ και 10+ χρόνια γράφεις την ελληνική vb5 με την vb5 να κατηγορείς τον οποιοδήποτε για μεσαίωνα πληροφορικής. Σε τελική ποιος νομίζεις ότι είσαι; Σοβαρέψου.

[bugman]

Μήπως βιάστηκες να απαντήσεις...itt? Αν ξαναδιαβάσεις τι έχω γράψει θα καταλάβεις ότι μάλλον υπάρχει παρεξήγηση.

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

Για τις δομές δεδομένων
Στα πρώτα βιβλία που διάβαζα περί πληροφορικής..το 81, έπαιζαν τότε οι δομές δεδομένων. Σήμερα δεν υπάρχει αυτό το πράγμα. Ουδείς *ασχολείται με δομές δεδομένων και απορώ πως κολλάει το σχολείο εκεί! (ίσως και αυτοί που ασχολούνται με την ύλη να έχουν κολλήσει από το 80). Τώρα μιλάμε για βάσεις δεδομένων, γιατί να μην μάθουν SQL τα παιδιά;
(πραγματικά πριν δυο χρόνια ασχολήθηκα με μια διπλή συνδεδεμένη λίστα όταν ήθελα να φτιάξω έναν επεξεργαστή κειμένου).


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

[ether]

Για τις δομές δεδομένων
Στα πρώτα βιβλία που διάβαζα περί πληροφορικής..το 81, έπαιζαν τότε οι δομές δεδομένων. Σήμερα δεν υπάρχει αυτό το πράγμα. Ουδείς *ασχολείται με δομές δεδομένων και απορώ πως κολλάει το σχολείο εκεί! (ίσως και αυτοί που ασχολούνται με την ύλη να έχουν κολλήσει από το 80).

Δε φαντάζομαι να σοβαρολογείς

[bugman]

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

[ether]

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

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

[tdrivas]

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

όλα τα προγράμματα που κάνουν χρήση της FIFO ιδιότητας (κυρίως) μπορεί να υλοποιηθούν με συνδεδεμένη λίστα. Σου παραθέτω παραδείγματα λίστας:
1. Παιχνίδια με τράπουλα
2. Η κρυφή μνήμη των browser (για επιστροφή)
3. binary tree - hash tables
4. Undo κουμπί στα προγράμματα.
5. Λίστα αντικειμένων σε 3D παιχνίδι που περιμένουν να γίνουν rentered.
6. Χρονοπρογραμματισμός σε ΛΣ

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

[bugman]

morfeus,
ευχαριστώ για την απάντησή σου. Ασφαλώς και συμφωνώ με το ότι αν θέλει κανείς να χρησιμοποιήσει μια "συνδεδεμένη λίστα" μπορεί να το κάνει, αλλά οι μοντέρνες γλώσσες έχουν άλλα καλά, όπως collections στη Vb6, vector και map στη C++. Και εδώ υπάρχει η συνδεδεμένη λίστα αλλά δεν ασχολείσαι με μεταβλητές τύπου Top...αλλά με μεθόδους και ιδιότητες, δηλαδή η λίστα είναι κρυμμένη στο αντικείμενο. Τώρα αν θέλουν εδώ να μάθουν τα FIFO και LIFO καλώς. Αυτό με το απώθησε δεν μου αρέσει ως όνομα. Στη γλώσσα που έχω γράψει έχω την Βάλε (και ως Push) και Διάβασε (Read). Οπότε
Βάλε 1,2,3
Διάβασε Α,Β,Γ
διαβάζει στο Α το 3, αυτή είναι η LiFO
Σωρός νέος { Σειρά 1, 2, 3 : Διάβασε Α, Β, Γ}   \\ εδώ ανοίγω ένα προσωρινό σωρό (άντε να το πούμε και στοίβα..) και διαβάζω ως FIFO το Α θα είναι 1.
Όπως βλέπεις δεν υπαρχουν Top και ότι άλλο, αλλά υπάρχουν αρκετές εντολές όπως ΑΔΕΙΑΣΕ  αλλά και ΦΕΡΕ για να φέρει κανείς π.χ το 3 στοιχείο στη κορυφή, η Πέτα 3 πετάει τρία στοιχεία από τη κορυφή, η Πάνω 2 παίρνει το δεύτερο στοιχείο και το βγάζει αντίγραφο στη κορυφή. Στο σωρό της Μ2000 μπορεί κανείς να βάλει ακόμα και πίνακα  byvalue και με την Πάνω 1 (παίρνει την κορυφή και βγάζει αντίγραφο) βγάζεις αντίγραφο του πίνακα. Με μια Διάβασε Α() διαβάζεις τον πίνακα...που ήταν στο Top στοιχείο. Ο σωρός στην Μ2000 χρησιμοποιείται κύρια για να επιστρέφει τιμές από βάσεις δεδομένων αλλά και για να περνάει τιμές μεταξύ τμημάτων (κάτι παραπάνω από απλά υποπρογράμματα).
Για μένα αυτά είναι θέμα της εργασίας που κάνω. Όμως για τον μαθητή καλό θα ήταν να μάθει όχι απλά πως να στήνει μια ουρά ή μια στοίβα αλλά και όλες τις ιδιότητες, τις καταστάσεις του και τις μεθόδους. Τότε θα μπορούμε να λέμε ότι κατάλαβε τι έγινε.
Συμφωνείς;

[tdrivas]

morfeus,
ευχαριστώ για την απάντησή σου. Ασφαλώς και συμφωνώ με το ότι αν θέλει κανείς να χρησιμοποιήσει μια "συνδεδεμένη λίστα" μπορεί να το κάνει, αλλά οι μοντέρνες γλώσσες έχουν άλλα καλά, όπως collections στη Vb6, vector και map στη C++. Και εδώ υπάρχει η συνδεδεμένη λίστα αλλά δεν ασχολείσαι με μεταβλητές τύπου Top...αλλά με μεθόδους και ιδιότητες, δηλαδή η λίστα είναι κρυμμένη στο αντικείμενο.

Κατ' εμέ, πρέπει πάντα να ξέρεις πως οι έτοιμες μέθοδοι των αντικειμένων υλοποιούνται για να έχεις μία σφαιρική αντίληψη του τι κάνουν και πως να κάνεις τη βέλτιστη χρήση τους. Φυσικά, υπάρχουν vectors, arrayLists, maps κτλ. αλλά τι νόημα έχει αν δεν ξέρεις πως λειτουργούν, πως υλοποιούνται..

εδώ ανοίγω ένα προσωρινό σωρό (άντε να το πούμε και στοίβα..)

Ο σωρός είναι δένδρο(maxHeap - MinHeap), δεν μπορώ να πω την στοίβα σωρό.

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

Συμφωνώ,αλλά...

[bugman]

Δένδρο θα λέγαμε το σωρό ή κάθε δομή που υλοποιείται με δείκτες εντός των στοιχείων. Φαντάσου το κάθε στοιχείο σαν ένα κουτάκι με τουλάχιστον δυο τιμές, την τιμή που "κουβαλάει" και το δείκτη του επόμενου στοιχείου, και ας το λέμε ενσωματωμένο δείκτη. Τώρα αν βάλουμε και έναν δεύτερο δείκτη φτιάχνουμε καλύτερη δομή, με την έννοια ότι μπορούμε να δείχνουμε και το προηγούμενο. Όμως μπορούν οι δυο δείκτες να έχουν άλλη έννοια δηλαδή το αριστερό κλαδί και το δεξί κλαδί. Σε b-Tree αντί για δυο "ενσωματωμένους" έχουμε μια λίστα δεικτών (και μια λίστα τιμών) με συνέπεια η αναζήτηση να γίνεται πολύ γρήγορα επειδή βασίζεται στο ότι κάθε "σελίδα" δεικτών φορτώνει από το δίσκο με την μία (αυτή είναι η χρησιμότητα του b-tree και ήταν το διαμάντι της dBase). Στο σωρό όπως και σε μια ουρά δεν υπάρχει ανάγκη ενσωμάτωσης του δείκτη. Να γιατί το TOP εμφανίζεται στα Υποπρογράμματα. Π.χ. με έναν πίνακα έστω 100 θέσεων μπορούμε με μια μεταβλητή να δείχνουμε την κορυφή του σωρού. Το αν θα μειώνεται η θα αυξάνεται είναι θέμα γούστου, η σημασία του σωρού σε πράξεις για παράδειγμα είναι να λειτουργεί το λεγόμενο reverse polish notiation  βάζεις 2 μετά 3 και δίνεις εντολή +. Για να τοποθετείς ας πούμε στοιχεία θα μπορούσε κανείς να χρησιμοποιεί Offset, δηλαδή αν το TOP αυξάνει όταν βάζουμε στοιχείο τότε στο Top-1 θα έχουμε την δεύτερη παράμετρο με την έννοια ότι έχουμε κανονίσει να έχουμε παράμετρους στο σωρό για μια κλήση σε μια ρουτίνα. Αυτά τα κόλπα τα κάνουν οι compilers με την χρήση του Stack, γι΄αυτό και έχω κολλήσει στο ότι stack και σωρός είναι το ένα και το αυτό (στον επεξεργαστή ο δείκτης Top Λέγεται Stack Pointer, ή SP).

[bugman]

Να προσθέσω μια άποψη για το λόγο που συνήθως ο Stack μειώνεται. Αυτό γίνεται επειδή οι επεξεργαστές δουλεύουν με σημαίες καταστάσεων. Όταν εμφανιστεί μηδέν στον συσσωρευτή Α (τον κεντρικό καταχωρητή) τότε μια σημαία λέει "έχω μηδέν". Με την χρήση των σημαιών ο επεξεργαστής κάνει άλματα "υπό συνθήκη", δηλαδή οι σημαίες παίζουν τον ρόλο των συνθηκών. Όταν λοιπόν ο σωρός μειώνεται θα φτάσει κάποια στιγμή στο μηδέν. Μάλιστα όχι για όλη την διεύθυνση αλλά για το τμήμα εκείνο, το λιγότερο σημαντικό που εμπίπτει σε αυτό που λέμε σελίδα στη μνήμη. Π.χ. ο 6502 είχε μόνο 256 Bytes stack και αυτός στην σελίδα ένα (ξεκίναγε από μηδέν ο χάρτης μνήμης). Ακόμα όμως και να έφτιαχνε κανείς έναν προγραμματιστικό σωρό (stack) θα βόλευε να εξέταζε το μηδέν αφού αυτό έρχεται εύκολα με την χρήση σημαίας. Το πρόβλημα του σωρού είναι τα άκρα...το μηδέν που σημαίνει άδειος και το άλλο το οποίο γενικά το άφηναν χωρίς έλεγχο...γιατί υποθέτουν ότι θα γυρίσει στο μηδέν (εξετάζοντας μόνο τα λιγότερα σημαντικά μπιτ).

[bugman]

Το βρήκα...http://www.dit.hua.gr/~michail/teaching/datastructures/slides/045_HeapImplementation.pdf
μάλλον κάποιος το ξεκίνησε "στραβά" και τώρα θεωρούν την Heap ως σωρό!!!!! 'Εχει δίκιο ο Morfeus..

Εδώ δείχνει το Stack και το Heap όπως εγώ το καταλαβαίνω (όπως δουλεύει στο Linux για παράδειγμα)..
http://www.ualberta.ca/CNS/RESEARCH/LinuxClusters/mem.html

[ether]

Δένδρο θα λέγαμε το σωρό ή κάθε δομή που υλοποιείται με δείκτες εντός των στοιχείων. Φαντάσου το κάθε στοιχείο σαν ένα κουτάκι με τουλάχιστον δυο τιμές, την τιμή που "κουβαλάει" και το δείκτη του επόμενου στοιχείου, και ας το λέμε ενσωματωμένο δείκτη. Τώρα αν βάλουμε και έναν δεύτερο δείκτη φτιάχνουμε καλύτερη δομή, με την έννοια ότι μπορούμε να δείχνουμε και το προηγούμενο. Όμως μπορούν οι δυο δείκτες να έχουν άλλη έννοια δηλαδή το αριστερό κλαδί και το δεξί κλαδί. Σε b-Tree αντί για δυο "ενσωματωμένους" έχουμε μια λίστα δεικτών (και μια λίστα τιμών) με συνέπεια η αναζήτηση να γίνεται πολύ γρήγορα επειδή βασίζεται στο ότι κάθε "σελίδα" δεικτών φορτώνει από το δίσκο με την μία (αυτή είναι η χρησιμότητα του b-tree και ήταν το διαμάντι της dBase). Στο σωρό όπως και σε μια ουρά δεν υπάρχει ανάγκη ενσωμάτωσης του δείκτη. Να γιατί το TOP εμφανίζεται στα Υποπρογράμματα. Π.χ. με έναν πίνακα έστω 100 θέσεων μπορούμε με μια μεταβλητή να δείχνουμε την κορυφή του σωρού. Το αν θα μειώνεται η θα αυξάνεται είναι θέμα γούστου, η σημασία του σωρού σε πράξεις για παράδειγμα είναι να λειτουργεί το λεγόμενο reverse polish notiation  βάζεις 2 μετά 3 και δίνεις εντολή +. Για να τοποθετείς ας πούμε στοιχεία θα μπορούσε κανείς να χρησιμοποιεί Offset, δηλαδή αν το TOP αυξάνει όταν βάζουμε στοιχείο τότε στο Top-1 θα έχουμε την δεύτερη παράμετρο με την έννοια ότι έχουμε κανονίσει να έχουμε παράμετρους στο σωρό για μια κλήση σε μια ρουτίνα. Αυτά τα κόλπα τα κάνουν οι compilers με την χρήση του Stack, γι΄αυτό και έχω κολλήσει στο ότι stack και σωρός είναι το ένα και το αυτό (στον επεξεργαστή ο δείκτης Top Λέγεται Stack Pointer, ή SP).

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

[bugman]

Έχεις απόλυτο δίκιο...δεν ήξερα ότι το Heap έχει μεταφραστεί σε Σωρός..

[bugman]

Το βρήκα εδώ: https://en.wikipedia.org/wiki/Min-max_heap
Υπάρχει μόνο στην Αγγλική, Γερμανική και Κινεζική γλώσσα! Τυχαίο; Δεν νομίζω!!!!!

[tsak]

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

Ενδιαφέροντα όλα αυτά, αλλά να μην ξεφεύγουμε. Για υποψήφιους φοιτητές μιλάμε, όχι για δευτεροετείς Πληροφορικής..

[itt]

Το βρήκα...http://www.dit.hua.gr/~michail/teaching/datastructures/slides/045_HeapImplementation.pdf
μάλλον κάποιος το ξεκίνησε "στραβά" και τώρα θεωρούν την Heap ως σωρό!!!!! 'Εχει δίκιο ο Morfeus..

Εδώ δείχνει το Stack και το Heap όπως εγώ το καταλαβαίνω (όπως δουλεύει στο Linux για παράδειγμα)..
http://www.ualberta.ca/CNS/RESEARCH/LinuxClusters/mem.html

Ναι μόνο που ο τρόπος που τα καταλαβαίνεις εσύ είναι άσχετος με αυτά που γράφουμε. Το μόνο που χρειάζεται να καταλάβεις είναι αυτό

https://en.wikipedia.org/wiki/Stack_(abstract_data_type)

και αυτό

https://en.wikipedia.org/wiki/Heap_(data_structure)

To τι κάνει τα με τη μνήμη το linux ή τα windows δεν έχουν σχέση με τη συζήτηση.

[bugman]

itt,
ok, Δεν διαφωνώ με τα αγγλικά κείμενα που έθεσες παραπάνω. Μου είναι γνωστά, αν και το heap ως δομή δεδομένων μου φαίνεται κομμάτι χοντρό για εφαρμογή (ίσως η google να το κάνει..).

tsak,
Ασφαλώς τα παιδιά που βρίσκουν το στέκι εδώ δεν έρχονται από πίεση αλλά από ενδιαφέρον. Το τι συζητήσαμε εδώ ίσως να τους ενδιαφέρουν. Δόθηκαν διάφορες παραπομπές. Όπως γράφει και το βιβλίο καθηγητή, τα προβλήματα δεν είναι "προγραμματιστικά", προϋπήρχαν των υπολογιστών, και απλά ο υπολογιστής μπορεί να χρησιμεύσει ως εργαλείο επίλυσης, εφόσον ο μαθητής αντιληφθεί το πρόβλημα. Μέχρι εδώ συμφωνώ απόλυτα. Το θέμα είναι ότι κάπου λέει ότι τα εργαλεία για την επίλυση των προβλημάτων είναι οι αλγόριθμοι και αυτοί είναι ανεξάρτητοι των γλωσσών ή συστημάτων όπου δύναται να "εκπονηθούν" (το βάζω αντί του implemented, δεν μπορώ να σκεφτώ άλλο όρο τώρα). Η ουσία όμως είναι ότι το hardware είναι η βάση του εργαλείου και ο αλγόριθμος μπορεί ή όχι να επιτύχει αν το υλικό το υποστηρίζει, και κατ΄επέκταση πάμε στο λειτουργικό και κατ΄επέκταση πάμε στο περιβάλλον προγραμματισμού. Π.χ. την δεκαετία του 80 δεν υπήρχε περίπτωση να υλοποιηθεί σε υπολογιστή με 32kbyte γλώσσα με αντικείμενα, αντί αυτού μπορούσαν να "παίξουν" η Basic, η Forth και σε ειδικές περιπτώσεις η Pascal. Πήγαμε σε 16bit συστήματα για να δούμε C και χρήση GEM (παραθυρικό περιβάλλον πριν τα Windows, το χρησιμοποιούσα το 1986).
Σήμερα λοιπόν για το σχολείο έχουμε μια ΓΛΩΣΣΑ που θέλει να περιλαμβάνει όχι απλά οδηγίες -ως ψευδογλώσσα- αλλά να καθορίζει μεταβλητές και διακριτές εντολές. Ευτυχώς υπάρχει και ο Διερμηνευτής για να κάνουμε δοκιμές. Όμως έχουμε χάσει την έννοια του εργαλείου, αφού δεν υπάρχει σύνδεση γλώσσας με υπολογιστή. Κάτι κατάφερει ο Νικολαϊδης με τη γλωσσομάθεια http://www.spinet.gr/glossomatheia/ με το Εμπλουτισμένο συντακτικό (για αρχεία στο δίσκο, διαχείριση οθόνης και άλλα).
Με απλά λόγια "εργαλείο" είναι αυτό που φέρνει αποτέλεσμα. Οι ασκήσεις στη ΓΛΩΣΣΑ ναι μεν απαιτούν γνώση και δουλειά για να εφαρμοστούν αλλά ως προς το αποτέλεσμα περιορίζονται.
Δεν γνωρίζω το μάθημα με τις διεπαφές πώς γίνεται, δηλαδή τη γλώσσα χρησιμοποιείτε στο σχολείο για να φτιάξει κανείς user interface...UI.

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

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

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

Δεν γνωρίζω το μάθημα με τις διεπαφές πώς γίνεται, δηλαδή τη γλώσσα χρησιμοποιείτε στο σχολείο για να φτιάξει κανείς user interface...UI.

Αν θέλεις μπορείς να μου λύσεις μερικές απορίες:
- Έχεις κάνει σπουδές πληροφορικής;
- Είσαι εκπαιδευτικός πληροφορικής;
- Διδάσκεις ΑΕΠΠ;
- Το περιβάλλον Μ2000 το έχεις φτιάξει στο πλαίσιο κάποιων σπουδών που κάνεις; Το έχεις δοκιμάσει στην πράξη και έχεις εντοπίσει παιδαγωγικά/διδακτικά πλεονεκτήματα έναντι άλλων περιβαλλόντων;
- Έχεις καμία σχέση με τον fupat*;

[ether]

αν και το heap ως δομή δεδομένων μου φαίνεται κομμάτι χοντρό για εφαρμογή (ίσως η google να το κάνει..).

Δε φαντάζομαι να σοβαρολογείς. Αντιγράφω μερικές από τις εφαρμογές των ουρών προτεραιότητας από το https://www.cs.princeton.edu/~rs/AlgsDS07/06PriorityQueues.pdf:

Event-driven simulation. [customers in a line, colliding particles]
Numerical computation. [reducing roundoff error]
Data compression. [Huffman codes]
Graph searching. [Dijkstra's algorithm, Prim's algorithm]
Computational number theory. [sum of powers]
Artificial intelligence. [A* search]
Statistics. [maintain largest M values in a sequence]
Operating systems. [load balancing, interrupt handling]
Discrete optimization. [bin packing, scheduling]
Spam filtering. [Bayesian spam filter]

[bugman]

ether,
Συμφωνώ για αυτά που αναφέρεις, αλλά σίγουρα κανένα δεν μπορεί να γίνει αντικείμενο σχολικής εκπαίδευσης.Όπως αναφέρθηκε και πιο πάνω υπάρχουν στο προγραμματισμό αντικείμενα που ενσωματώνουν δομές δεδομένων. Ιδιότητα των αντικειμένων αυτών είναι το Encapsulation,  η κρυμμένη λειτουργικότητα κάτω από ένα πέπλο μεθόδων και ιδιοτήτων. Π.χ. μπορεί κανείς να χρησιμοποιεί την MySQL χωρίς να κάτσει να μάθει πώς στο καλό δουλεύει. Διότι και να μάθει, θα χρειαστεί δέκα χρόνια να καταλάβει πλήρως το πώς λειτουργεί και θα χάσει το τραίνο.

Ν. Αδαμόπουλος. Όσα παιδιά έχουν θέμα με το μάθημα πάνε σε φροντιστήριο. Δεν υπάρχουν "Δωρεάν υπηρεσίες" αυτά είναι για τους αφελείς.
Εδώ είδα να συζητούν μεγάλοι άνθρωποι, πιθανόν καθηγητές. Όσο για τα προσωπικά στοιχεία (που δεν οφείλω να καταθέσω, αφού δεν υπάρχει κανόνας που να ορίζει ποιοτικά χαρακτηριστικά του μέλους στο στέκι), ίσως αγνοείς το γεγονός ότι έχω παρουσία εδώ από το 2003 και ότι συντέλεσα με παρατηρήσεις στη βελτιστοποίηση του Διερμηνευτή. Δεν είμαι "freelance" προγραμματιστής, ούτε πουλάω κάτι! Έχω πτυχίο τριτοβάθμιας εκπαίδευσης και έχω φτιάξει εφαρμογές εργαλεία, αλλά και πολλά παρεχόμενα δωρεάν όπως η γλώσσα προγραμματισμού που ξεκίνησα πριν ακόμα βγει και ο Διερμηνευτής και τότε είχα συζητήσει για το θέμα των ελλείψεων σε γραφικά, βάσεις δεδομένων και πολυμέσα και όπως κατάλαβα ήταν θέμα παιδαγωγικού ινστιτούτου να μην τα συμπεριλάβει μέσα.
Οπότε οι απαντήσεις στις ερωτήσεις είναι:
- Ναι αν μπορούμε να πούμε τα εξάμηνα πληροφορικής της σχολής.
- Κατά μια έννοια εκπαιδευτής, για άτομα που δίνουν εξετάσεις πιστοποίησης σε κοινά προγράμματα Word κλπ
- Δεν διδάσκω ΑΕΠΠ (ευτυχώς). Είχα γράψει όμως μερικά παραδείγματα στη ΓΛΩΣΣΑ το 2003
http://spinet.gr/glossomatheia/programs/intro/
Εδώ είναι ένα "Λειτουργικό Αρχείων" http://www.spinet.gr/glossomatheia/programs/viewtopic.php?f=22&t=66 σε εμπλουτισμένο συντακτικό.
Ίσως να έγραψα και την πρώτη συνάρτηση ΤΥΧΑΙΟΣ (δεν υπήρχε στη ΓΛΩΣΣΑ, δεν ξέρω τώρα αν έχει προστεθεί αλλά δεν γίνεται να μην παίζει μια συνάρτηση ΤΥΧΑΙΟΣ σε μια γλώσσα)..
- Στα σαρανταοκτώ μου χρόνια...δεν  χαραμίζω το χρόνο μου και εκμεταλλεύομαι και το τελευταίο κομμάτι φαιάς ουσίας που να μπορεί να αποδώσει κάτι. Είναι κρίμα να φτιάχνω μια γλώσσα προγραμματισμού και να μην φτιάχνει κανείς άλλος. Η συζήτηση εδώ είναι σαν καφενείου, κακώς αλλά έστω ας γραφτεί μια φορά...
To 2006 γράφω εδώ: http://forum.math.uoa.gr/viewtopic.php?f=149&p=238319 και ουδείς απάντησε!!!!!! Κάλεσα άλλα άτομα να ασχοληθούν. Τίποτα. Ή θα υπήρχαν οι γλώσσες για τους επαγγελματίες ή στον αντίποδα η ΓΛΩΣΣΑ ως μια αντιγραφή της Pascal. Θα μπορούσε κανείς να δει την Μ2000 ως αντιγραφή της Basic αλλά δεν είναι, αν και τελευταία για εκπαιδευτικούς λόγους συμπλήρωσα όλες τις εντολές της παλιάς Basic για να μπορούν να γραφτούν παραδείγματα στο ίδιο περιβάλλον τόσο του απλού προγραμματισμού με ΠΡΟΣ (Goto) και  ΔΙΑΜΕΣΟΥ (Gosub) όσο και πιο σύνθετου με ρουτίνες (Subs) αλλά και πιο συνθέτου  με τμήματα και κλάσεις και με νήματα (η Μ2000 έχει πολυεπεξεργασία).
-Αυτό με το fupat* το λαμβάνω ως αστείο!

[ether]

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

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

[bugman]

Ether,
δεν ήθελα να σε θίξω και δεν έχω μια στάση ένας εναντίων όλων. Ίσως έχεις να υπερασπιστείς τις ουρές όχι όμως από το "τις έχω κάνει σε άσκηση" ή "τις έχω διδάξει" αλλά αυτό που κυριολεκτικά πιστεύω ότι ενοχλεί, η απουσία του "τις έχω χρησιμοποιήσει εκτός εκπαίδευσης...".
Προφανώς ένα αλφαριθμητικό είναι μια ουρά αν θες να το δεις σωστά. Αφού ο τελευταίος χαρακτήρας έχει θέση που υποδεικνύεται από μια μεταβλητή, το μήκος του αλφαριθμητικού! Θα μπορούσε κανείς να αυξάνει το αλφαριθμητικό βάζοντας στο τέλος ένα χαρακτήρα που να υποδηλώνει κατάσταση. Και πάλι όμως το ζήτημα για μένα δεν είναι το τι είναι ουρά, αν πιστεύει ο "επαγγελματίας" εκπαιδευτικός ότι αποτελεί πεδίο εκπαίδευσης, (νομίζω ότι οι όροι είναι αντίθετοι στην Ελληνική πραγματικότητα, για το λόγο αυτό βάζω το επαγγελματίας σε εισαγωγικά, εννοείται ότι επαγγελματικά εργάζεται ένας εκπαιδευτικός, θίγω το ζήτημα που υπάρχει χρόνια με τη λεγόμενη σύνδεση της εκπαίδευσης με την παραγωγή...), αλλά αν θέλουμε να έχουν οι μαθητές χρήση εργαλείων ή χρήση σχεδίων, με το δεύτερο θα λένε ότι ξέρουν αλλά δεν θα έχουν κάνει τίποτα. Θα μπορεί ο καθένας να λέει...εντάξει ξέρεις αλλά τι έχεις φτιάξει; Και η απάντηση θα είναι "έχω ολοκληρώσει επιτυχώς σαράντα ασκήσεις, πέντε με ουρά..και τρεις με στοίβα". Αντιλαμβάνεσαι τι γράφω ή πάνε στο βρόντο;

[ether]

Αντιλαμβάνεσαι τι γράφω ή πάνε στο βρόντο;

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

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

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

[bugman]

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

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

- Δεν διδάσκω ΑΕΠΠ (ευτυχώς).

Δες όμως ότι το συγκεκριμένο νήμα είναι κάτω από την ΑΕΠΠ, η οποία έχει συγκεκριμένο στόχο, συγκεκριμένη ύλη, συγκεκριμένες εξετάσεις, κλπ.

[bugman]

Σωστά, η συζήτηση πρέπει να περιστρέφεται γύρω από τις ασκήσεις σε στοίβα και ουρά. Αλλά νομίζω ότι πάνω σε αυτά συζητώ και μάλιστα ως προς την χρησιμότητα της εξάσκησης πάνω σε αυτές. Νομίζω ότι είναι το Στέκι των Πληροφορικών και όχι το http://www.sch.gr/. Σε καμία περίπτωση δεν θα έγραφα στο τελευταίο.
Οπωσδήποτε το να έχει κάποιος την άποψή του για το θέμα δεν αλλάζει το θέμα. Δεν αλλάζει ότι ο μαθητής θα γράψει εξετάσεις και ότι θα πρέπει να μάθει δέκα ασκήσεις. Για την εξεταστική διαδικασία ασφαλώς λοιπόν και έχει νόημα η εμπέδωση ασκήσεων. Εξέφρασα το παράπονό μου για την ύλη αυτή η οποία εμφανίζεται αναγκαία όταν δεν υπάρχει διαφαινόμενη αναγκαιότητα να έχει η γλώσσα στοιχεία εισόδου εξόδου από και προς την οθόνη και προς αρχεία, να μην έχει γραφικά και άλλα ωραία πράγματα, που θα δίνουν "δουλειά" και όχι τεστ ευφυίας...(πιστεύω ότι το θέμα των ουρών είναι πολύ προχωρημένο για το λύκειο).
Θέλω να ευχαριστήσω για την υπομονή σας. Και όποιος ενδιαφέρεται για την Μ2000..διαθέτω τον κώδικά της ανοιχτό εδώ:
https://www.dropbox.com/sh/xq8j8t7kbj37ms0/AABKIv4d9qXTLbEFPvfjPLb0a?dl=0
για Vb6 Enterprise Edition.
Εδώ είναι ένα παράδειγμα με κλάσεις  (Η διάβασε διαβάζει πάντα από σωρό...όπως τον εννοώ εγώ..Stack, με στοιχεία διάφορα, πίνακες, ομάδες - έτσι λέγονται τα αντικείμενα στη Μ2000-, με πέρασμα με τιμή αλλά και με αναφορά. Το πώς γίνεται στο σωρό να περνάει κανείς και με τιμή και με αναφορά...θέλει διάβασμα ο κώδικας)

Φόρμα 40,25 \\40Χ25
Κλάση Αλφα {
      Χ=10, Υ, Α$="Όνομα"
      Τμήμα Αλφα {
            Αν ταύτιση("NN") Τότε Διάβασε .Χ , .Υ
      }
      Τμήμα Νέο.Όνομα {
            Διάβασε .Α$
      }
      Συνάρτηση Νέο.Όνομα$ {
            =.Α$
      }
      Συνάρτηση Ένα { = .Χ**2+.Υ}
}
Κάπα=Αλφα()   \\ κατασκευάζουμε το αντικείμενο χωρίς παραμέτρους
Κάπα.Υ=20
Τύπωσε Κάπα.Ένα()
Βήτα=Αλφα(10,20)  \\ εδώ με παραμέτρους
Τύπωσε Βήτα.Ενα()
Για Βήτα {
      Τύπωσε .Χ, .Υ, .Α$, .Ενα()
}
Λάμδα=Κάπα  \\ αντιγραφή αντικειμένου
Για Λάμδα {
      .Χ-=5
      .Νέο.Όνομα "Λάμδα"
      Τύπωσε .Νέο.Όνομα$(), .Ένα()
}

[alkisg]

bugman, για να διαφημίζεις τη γλώσσα σου, νομίζω θα ήταν καλύτερα να μην συμμετέχεις στους πίνακες συζητήσεων για τα μαθήματα της δευτεροβάθμιας, αφού δεν εμπλέκεσαι στη διδακτική διαδικασία, και καταλήγεις να κάνεις παραπληροφόρηση, να χαλάς τις συζητήσεις των άμεσα ενδιαφερόμενων κ.α.
Νομίζω ότι θα ήταν καλύτερα να συνεχίσεις στο θέμα που ήδη άνοιξες: https://alkisg.mysch.gr/steki/index.php?topic=6318.0

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

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

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

[bugman]

Ok,
συγνώμη για την ενόχληση.

[papaluk]

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

Αλγόριθμος Εξαγωγή_από_Ουρά
Δεδομένα // rear, front, queue, N //
Αν rear > front τότε
  Itemout ← queue[front]
  front ← front+1
  done ← Αληθής
αλλιώς_αν rear=front και rear ≠ 0 τότε
  Itemout← queue[front]
  front ← 0
  rear ← 0
  done ← Αληθής
αλλιώς
  done ← Ψευδής
Τέλος_αν
Αποτελέσματα // itemout, rear, front, done //
Τέλος Εξαγωγή_από_Ουρά   

Αλγόριθμος Εισαγωγή_σε_Ουρά
Δεδομένα // rear, front, queue, N, itemin //
Αν rear < Ν  τότε
  Αν rear ≠ 0 τότε
    rear← rear+1
    queue[rear]← itemin
    done ← Αληθής
  αλλιώς ! rear=front=0
    rear← rear+1
    front ← front+1
    queue[rear]← itemin
    done ← Αληθής
  τέλος_Αν
αλλιώς
  done ← Ψευδής
Τέλος_αν
Αποτελέσματα // rear, front, done //
Τέλος Εισαγωγή_σε_Ουρά

[bugman]

Θα μπορούσες να εμπλουτίσεις την δομή σου με δυο αλγόριθμους:
καθαρή_ουρά
γεμάτη_ουρά  (συνάρτηση).
Κατά την άποψή μου δεν εισάγουμε κάτι με πιθανότητα να πάρουμε λάθος, αλλά  πρώτα κοιτάμε αν μπορούμε να εισάγουμε και μετά κάνουμε την ενέργεια. Εντούτοις θα μπορούσε να βγει λάθος αλλά αυτό το λάθος δεν θα είχε να κάνει με την λογική της δομής αλλά με την αδυναμία εγγραφής..δηλαδή την αδυναμία του υλικού ( δεν μπορεί να συμβεί στη ΓΛΩΣΣΑ αλλά θα μπορούσε να συμβεί με μια άλλη γλώσσα που θα είχε τον πίνακα σε αρχείο, οπότε πολλά θα μπορούσαν να συμβούν).
Με απλά λόγια στον "Αλγόριθμος Εισαγωγή_σε_Ουρά" ο έλεγχος των rear and front για την περίπτωση της υπερχείλισης θα έπρεπε να γίνει πριν.
1) Υπερχείλιση; Όχι ->Εισαγωγή
2) Άδειο; Όχι -> Εξαγωγή
Χρησιμοποιείς την front για να εισάγεις και την rear για να εξάγεις. Θα μπορούσε η rear να είναι αριθμητικά μεγαλύτερη από την front.
π.χ. σε πίνακα δέκα θέσεων (1 εως 10) η front δείχνει την 3 θέση (όπου θα μπει ένα νέο στοιχείο), και η rear θα πρέπει λογικά να δείχνει από εκεί που θα πάρουμε και όχι από την προηγούμενη θέση (όπως δείχνεις στο παράδειγμά σου) αλλά ας το δεχτούμε έτσι, άρα αν έχουμε rear 7 θα πάρουμε από το 8. Πόσα στοιχεία έχουμε; Ας το  δούμε από το μάζεμα, έχουμε το ( 8 ),(9),(10),(1),(2) άρα πέντε στοιχεία. Κάθε φορά η ουρά μπορεί να πάρει το πολύ δέκα στοιχεία, για οποιοδήποτε rear...Να γιατί δεν μπορούμε να σκεφτόμαστε το rear ως το "ήδη εξαγόμενο" και να υπολογίζουμε να πάρουμε από το rear+1.
Ο αλγόριθμος papaluk όπως γράφτηκε δεν εξασφαλίζει ότι για οποιοδήποτε rear μπορώ να βάλω N στοιχεία όσο το μέγεθος του πίνακα. (Αυτή είναι η ουσία μιας ουράς, να μπορεί να πάρει σε όλο το άνοιγμα στοιχεία, και να μπαίνουν και να βγαίνουν χωρίς να μετακινούμε τα στοιχεία που δεν σχετίζονται με την εισαγωγή ή εξαγωγή).

[petrosp13]

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

[nikolasmer]

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

Διαθέτουμε μια τράπουλα με φύλα από το 1 μέχρι το 10 χωρίς βαλέδες , ντάμες και ρηγάδες και με αυτά τα φύλλα (40 στον αριθμό) παίζουμε το παιχνίδι «Stupidity» το οποίο πάει ως εξής. Ρίχνω κάτω χαρτιά μέχρι το άθροισμα του πιο πάνω χαρτιού ή και του αμέσως προηγούμενου κλπ. συμπληρώσει άθροισμα ακριβώς 10. Όταν αυτό συμβεί τότε να αφαιρούνται αυτά τα χαρτιά (που το άθροισμά τους μας κάνει 10) από τη ΣΤΟΙΒΑ φύλλων. Όταν τα φύλλα της Τράπουλας τελειώσουν, να «γυρίζουμε» τη Στοίβα φύλλων ανάποδα και να συνεχίζουμε κατά τον ίδιο τρόπο πάλι ρίχνοντας φύλλα. Στόχος του παιχνιδιού είναι να φύγουν όλα τα φύλλα της τράπουλας, μέχρι και το τελευταίο, σε 10άδες. Να υλοποιηθεί το παραπάνω παιχνίδι με πρόγραμμα σε ΓΛΩΣΣΑ ως εξής:
1.   Θα διαβάζει από το πληκτρολόγιο αριθμούς, οι οποίοι αντιστοιχούν σε φύλλα και θα τους ωθεί σε μια Στοίβα μέχρι να «εξαντληθούν» όλα τα φύλλα της τράπουλας.
2.   Κάθε φορά που το άθροισμα των κορυφαίων φύλλων στη Στοίβα, φτάνει ακριβώς 10, τότε να Απωθεί αυτά τα Φύλλα (ή αυτό το φύλλο) από τη Στοίβα και να συνεχίζει με το διάβασμα των επόμενων φύλλων.
3.   Όταν τελειώσουν τα φύλλα της τράπουλας το πρόγραμμα να αποφαίνεται αν επιτυγχάνεται ο στόχος του παιχνιδιού και να εμφανίζει κατάλληλο μήνυμα σε κάθε περίπτωση. Για το σκοπό αυτό θα πρέπει κάθε φορά που τελειώνουν τα φύλλα, να ξανά εισάγονται οι αριθμοί που έμειναν – φύλλα – σε στοίβα, με την αντίστροφη σειρά. Αν μετά από ένα γύρο (ρίχνουμε όλα τα φύλλα) δεν παρουσιαστεί 10άδα τότε το παιχνίδι «κλείδωσε» και δεν επιτυγχάνεται ο στόχος. Διαφορετικά συνεχίζουμε με επόμενο γύρο.
4.   Στην περίπτωση που ο στόχος επιτυγχάνεται το πρόγραμμα να εμφανίζει τον αριθμό των ολοκληρωμένων 10άδων που δημιουργήθηκαν καθώς και πόσες φορές «ρίχτηκαν» τα φύλλα της τράπουλας από την αρχή.

[nikolasmer]

(1)Έστω ότι έχουμε μια ακολουθία από Λειτουργίες Ώθησης και Απώθησης στοιχείων σε και από μια Στοίβα.
Η λειτουργία της Ώθησης , ωθεί τα ψηφία 0 - 9 σε σειρά (αύξουσα ή φθίνουσα) στη Στοίβα. Η Απώθηση , απωθεί την τιμή που βρίσκεται στην κορυφή της στοίβας εμφανίζοντάς τη παράλληλα στην οθόνη. Ποια από τις παρακάτω ακολουθίες αριθμών που εμφανίζονται στην οθόνη, ΔΕΝ μπορεί να συμβεί με την παραπάνω διαδικασία;
(a)  4 3 2 1 0 9 8 7 6 5
(b)  4 6 8 7 5 3 2 9 0 1
(c)  2 5 6 7 4 8 9 3 1 0
(d)  4 3 2 1 0 5 6 7 8 9

(2) Δείξτε πώς μπορεί μια ουρά να υλοποιηθεί με τη βοήθεια 2 Στοιβών
(3) Δείξτε πώς μπορεί μια Στοίβα να υλοποιηθεί με τη βοήθεια 2 Ουρών

Για τις (2) και (3) δεν έχω ιδέα πως μπορούν να υλοποιηθούν!

Πηγή: http://www.cs.princeton.edu/courses/archive/spring2001/cs126/exercises/adt.html

[Diotima]

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

Κάποια στιγμή, όταν είχα χρόνο, σκέφτηκα ότι πρέπει να διερευνήσω από μαθηματική άποψη τις πιθανές λύσεις ώστε να δω αν έχει νόημα το παιχνίδι, πριν προχωρήσω στην υλοποίηση. Υπέθεσα λοιπόν ότι θέλουμε να στήσουμε την τράπουλα ώστε να βγουν όλα τα φύλλα με αθροίσματα του 10.
Τα 10άρια δεν τα υπολογίζω αφού βγαίνουν μόνα τους.
Κατ' αρχήν τα 9άρια μπορούν να βγουν μόνο αν ακολουθεί ή προηγείται άσσος. Άρα θα πρέπει να έχουμε 4 ζεύγη (9,1) ή (1,9) για να φύγουν τα 9άρια.
Τα 8άρια για να φύγουν θα πρέπει να έχουμε άθροισμα 8+2 ή 8+1+1. Αλλά αφού τα 1 τα θέλουμε για τα 9άρια θα πρέπει τα 8άρια να βγουν μόνο με το συνδυασμό 8+2.
Πάνε και τα τέσσερα 2άρια. Όμοια, τα 7άρια που βγαίνουν με αθροίσματα 7+3 ή 7+2+1 ή 7+1+1+1 πρέπει να βγουν μόνο με άθροισμα 7+3 αφού χρειαζόμαστε τα τέσσερα 2άρια και τους τέσσερις άσσους για να βγάλουμε τα 8άρια και τα 9άρια. Και πάει λέγοντας, τα 6άρια πρέπει να βγουν με 4 και τα 5άρια με 5.
Συμπέρασμα:
Για να επιτευχθεί ο στόχος του παιχνιδιού, η λύση του, πρέπει να έχουμε τα ζεύγη
(9,1), (8,2), (7,3), (6,4) 4 φορές το καθένα (ή αντίστροφα οι αριθμοί) και δύο ζέύγη (5,5) με οποιαδήποτε δυνατή διάταξη τους και τα 10άρια ανάμεσα στα ζεύγη ή στην αρχή ή στο τέλος (αρκετές λύσεις-διατάξεις).
Οπότε τα φύλλα θα βγουν από τον πρώτο γύρο και δε χρειάζεται να γίνει δεύτερος γύρος αν ο στόχος είναι να βγουν όλα τα φύλλα. Αν μείνουν φύλλα από τον πρώτο γύρο ξέρουμε ότι το παιχνίδι κλειδώνει, δεν πρόκειται να βγουν όλα. Όπως επίσης ξέρουμε ότι αν σχηματιστεί άθροισμα του 10 με τρία ή περισσότερα φύλλα το παιχνίδι κλειδώνει, δεν επιτυγχάνεται ο στόχος. Όλα κρίνονται στον πρώτο γύρο.
Αυτό είναι απογοητευτικό, αλλά επειδή το σενάριο και η αλγοριθμική υλοποίηση είναι ωραία για στοίβα σκέφτομαι μήπως κάναμε κάποιες αλλαγές ή να αλλάζαμε το στόχο ώστε να έχουν νόημα οι συνεχόμενοι γύροι.

Ωραίο το link με τις ασκήσεις, ευχαριστώ!

[apoldem]

Μια ουρά μπορεί εύκολα να υλοποιηθεί με 2 στοίβες και το αντίστροφο.

Η ουρά κρατά τα στοιχεία με την σειρά εισαγωγής ενώ η στοίβα με την αντίστροφη σειρά εισαγωγής.

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

Π.χ. για να κάνω μια ουρά χρησιμοποιώντας δύο στοίβες (έστω στοίβα Α και Β) τότε:

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

[apoldem]

Το παιχνίδι με την τράπουλα είναι πολύ ωραίο! Για να λύνεται πάντα θα πρέπει να επεκταθεί το άθροισμα σε όλα τα πολλαπλάσια του 10 και όχι μόνο στο 10 ακριβώς. Δηλαδή ο παίκτης να παίρνει όλα τα φύλλα που έχουν άθροισμα 10, 20, 30... μέχρι την χειρότερη περίπτωση 140 (χωρίς τα δεκάρια).

[P.Tsiotakis]

Ετοίμασα ένα φυλλάδιο για τις Δομές Δεδομένων Στοίβα και Ουρά

καθώς και σχετικό βίντεο περιγραφής τους

[manpoul]

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

[bugman]

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

[mokasa]

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

[NiColas1957]

ο ΚΒ

[gthal]

Θα ήθελα κάποια σχόλια - παρατηρήσεις για τις ασκήσεις, αν κάποιος έχει χρόνο και διάθεση, ευχαριστώ!

Το αρχείο σου έχει κάποιο πρόβλημα (μηδενικό μέγεθος??)

[gpapargi]

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

[Γιάννης Αναγνωστάκης]

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

Όπου έχει προκύψει ανάγκη για απώθηση, κάνετε αντικατάσταση της τιμής που απωθείται με άλλη (π.χ stack[top]<-- '-', όπως κάνουν στην άσκηση - υπόδειγμα των οδηγιών); Και απο που στην εκφώνηση αυτή των οδηγιών προκύπτει 'ανάγκη' για αντικατάσταση του αριθμού κυκλοφορίας με '-'

Επίσης αν θέλει ένας μαθητής να  εμφανίσει τα περιεχόμενα μίας στοίβας , δεν μπορεί  απλά να κάνει μία επανάληψη απο 1 μέχρι top (ή αντίστροφα); Γιατί πρέπει να εφαρμόσει τον αλγόριθμο της απώθησης;

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


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

[pstasinos]

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

Όπου έχει προκύψει ανάγκη για απώθηση, κάνετε αντικατάσταση της τιμής που απωθείται με άλλη (π.χ stack[top]<-- '-', όπως κάνουν στην άσκηση - υπόδειγμα των οδηγιών); Και απο που στην εκφώνηση αυτή των οδηγιών προκύπτει 'ανάγκη' για αντικατάσταση του αριθμού κυκλοφορίας με '-'

Επίσης αν θέλει ένας μαθητής να  εμφανίσει τα περιεχόμενα μίας στοίβας , δεν μπορεί  απλά να κάνει μία επανάληψη απο 1 μέχρι top (ή αντίστροφα); Γιατί πρέπει να εφαρμόσει τον αλγόριθμο της απώθησης;

Σωστή παρατήρηση. Προσωπικά το θέμα το έχω συζητήσει αρκετά με τους μαθητές μου. Αν η άσκηση που έχουν να αντιμετωπίσουν , αρχικά γεμίζει μια στοίβα και θέλοντας να υπολογίσουν κάτι απλά την αδειάζουν , και εκεί να τελειώνει η άσκηση , τότε απλά τους έχω πει το top <- top -1 . Αλλιώς θέλει προσοχή όπως αναφέρεις.
Συμφωνώ πως απλά με μία επανάληψη , εμφανίζει κάποιος τις τιμές . Δεν έχει νόημα ο αλγόριθμος της απώθησης.
Σε ποιο υπόδειγμα οδηγιών αναφέρει την αντικατάσταση του stack[top] ; Ευχαριστώ

[dski]

Επίσης αν θέλει ένας μαθητής να  εμφανίσει τα περιεχόμενα μίας στοίβας , δεν μπορεί  απλά να κάνει μία επανάληψη απο 1 μέχρι top (ή αντίστροφα); Γιατί πρέπει να εφαρμόσει τον αλγόριθμο της απώθησης;

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

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

Το θέμα αυτό έχει ξανατεθεί στο Στέκι πριν λίγο καιρό. Δείτε τη σχετική συζήτηση εδώ.

[Γιάννης Αναγνωστάκης]

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

Το θέμα αυτό έχει ξανατεθεί στο Στέκι πριν λίγο καιρό. Δείτε τη σχετική συζήτηση εδώ.

Συμφωνώ μαζί σου, απλά παιδαγωγικά και διδακτικά η όλη ιστόρια 'μπάζει'...

[Γιάννης Αναγνωστάκης]

Σωστή παρατήρηση. Προσωπικά το θέμα το έχω συζητήσει αρκετά με τους μαθητές μου. Αν η άσκηση που έχουν να αντιμετωπίσουν , αρχικά γεμίζει μια στοίβα και θέλοντας να υπολογίσουν κάτι απλά την αδειάζουν , και εκεί να τελειώνει η άσκηση , τότε απλά τους έχω πει το top <- top -1 . Αλλιώς θέλει προσοχή όπως αναφέρεις.
Συμφωνώ πως απλά με μία επανάληψη , εμφανίζει κάποιος τις τιμές . Δεν έχει νόημα ο αλγόριθμος της απώθησης.
Σε ποιο υπόδειγμα οδηγιών αναφέρει την αντικατάσταση του stack[top] ; Ευχαριστώ

Στο παράδειγμα που υπάρχει στις επίσημες οδηγίες, στην άσκηση  με το οχηματαγωγό πλοίο

[petrosp13]

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

ΥΓ. Για τις '-' Γιάννη, ασχολίαστο..

[xara_pap]

Εφόσον γίνεται υλόποίηση με πίνακα δεν θα σου έβγαζε σφάλμα να εμφανίσεις από 1 μεχρι Top. Όμως η λογική της στοίβας είναι ότι έχουμε προσβαση μόνο στο κορυφαίο στοιχείο της στοίβας. Άρα για να τα προσπελάσεις πρέπει να κάνεις απώθηση. Ακόμη εγώ είπα στα παιδιά για παράδειγμα σε μία άσκηση που έχει ο κυριος Καρκαμάνης με ηλεκτρονικό κατάστημα που βάζει προιόντα στο καλάθι και βγάζει κι εν τέλει ρωτάει τι λεφτα θα πληρώσει ο πελάτης, όποιος πάει να το βρεί το άθροισμα αφού τελειώσει η επανάληψη ότι πρέπει να φάινεται ξεκάθαρα ότι ο top μειώνεται σε κάθε επανάληψη κατά ένα και οχι απλως να προσθέσουν ανάποδα όλα τα στοιχεία. Μέχρι να έχουμε παραπάνω πληροφορίες καλύτερα να είμαστε όσο πιο αναλυτικοί γίνεται. Όσο για την αντικατάσταση με την παύλα γνώμη μου είναι ότι είναι βλακεία και δεν το είπα στα παιδιά μιας και στις οδηγίες έχει υλοποίηση ώθησης απώθησης και δεν την βάζει την παύλα αρα στηρίχθηκα πάνω σε αυτό παρόλο που στο ferry boat το βάζει. Τους είπα να το βάλουν μόνο αν λέει η άσκηση να αντικαταστήσεις το στοιχείο με πάυλα ή οτιδήποτε άλλο.
Αν και πιστεύω ότι φέτος μόνο θεωρητικές ασκήσεις θα βάλουν και το πολύ να κάνουμε μία ώθηση και απώθηση σε πρώτο δεύτερο θέμα πολύ απλή.