Θέμα: Θεμα Γ χρηση πινακων απολυτα σωστη !!!

[Λαμπράκης Μανώλης]

συνάδελφοι να πω και εγώ την γνώμη μου...

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

[freedomst]

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

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

[itt]

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

Δεν νομίζω ότι αντιλαμβάνομαι το "προγραμματίζω τον αλγόριθμο". Μπορώ να υλοποιήσω τον αλγόριθμο σε μια γλώσσα προγραμματισμού, το να προγραμματίσω τον αλγόριθμο δεν μου φαίνεται να βγάζει νόημα.

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

Όχι απαραίτητα, μπορείς να γράψεις έναν αλγόριθμο χωρίς να περιγράφεις το control flow που θα απαιτούσε μια μηχανή turing πχ.

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

Γενικά το κεφάλαιο 3 πάσχει. Στην 3.3 ταυτίζει την "στιγμή του προγραμματισμοὐ" με την "στιγμἠ της μεταφράσης". Προσωπικά δεν καταλαβαίνω τι είναι η στιγμή της μετάφρασης και γενικότερα τι ακριβώς ερμηνεύουν αυτοί που έγραψαν το βιβλίο ως μετάφραση.

Θα έπρεπε να υπάρχουν συγκεκριμένοι κανόνες στην ψευδογλώσσα, ένας αυστηρός ορισμός, π.χ. επιτρέπεται αυτό δεν επιτρέπεται το άλλο.

Ή απλούστατα να ζητήται πρόγραμμα, κάτι που έχει πολύ συγκεκριμένους κανόνες.

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

Δεν είναι το ίδιο. Ο πίνακας σου προσφέρει O(1) access με ακέραιο index, το map είναι εντελώς διαφορετική ιστορία. Δεν είναι θέμα μνήμης, μπορείς να γράφεις και στατικό map. Απλούστατα τα semantics του map δεν διδάσκονται.

ΥΓ. Για την ακρίβεια, θέλω επισημάνω κάτι. Δες πώς μιλάς για map, χωρίς να σε απασχολεί η υλοποίηση. Για σένα το map δεν είναι ένα rb-tree είναι ἐνα interface που σου προσφέρει κάποιες λειτουργίες.

[freedomst]

Για

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

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

[evry]

Δεν νομίζω ότι αντιλαμβάνομαι το "προγραμματίζω τον αλγόριθμο". Μπορώ να υλοποιήσω τον αλγόριθμο σε μια γλώσσα προγραμματισμού, το να προγραμματίσω τον αλγόριθμο δεν μου φαίνεται να βγάζει νόημα.

Έχεις δίκιο ότι είναι λίγο άκυρο, αλλά εγώ το "προγραμματίζω" τον αλγόριθμο το αντιλαμβάνομαι ως "γράφω τον αλγόριθμο". Αλλιώς γιατί να τα λέει όλα αυτά στο κεφ. 3 όταν δεν έχει μιλήσει για πρόγραμμα ακόμα? Δεν θα έπρεπε να τα λέει στο 9?

Όχι απαραίτητα, μπορείς να γράψεις έναν αλγόριθμο χωρίς να περιγράφεις το control flow που θα απαιτούσε μια μηχανή turing πχ.

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

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

Δεν είναι το ίδιο. Ο πίνακας σου προσφέρει O(1) access με ακέραιο index, το map είναι εντελώς διαφορετική ιστορία. Δεν είναι θέμα μνήμης, μπορείς να γράφεις και στατικό map. Απλούστατα τα semantics του map δεν διδάσκονται.

ΥΓ. Για την ακρίβεια, θέλω επισημάνω κάτι. Δες πώς μιλάς για map, χωρίς να σε απασχολεί η υλοποίηση. Για σένα το map δεν είναι ένα rb-tree είναι ἐνα interface που σου προσφέρει κάποιες λειτουργίες.

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

[itt]

Έχεις δίκιο ότι είναι λίγο άκυρο, αλλά εγώ το "προγραμματίζω" τον αλγόριθμο το αντιλαμβάνομαι ως "γράφω τον αλγόριθμο". Αλλιώς γιατί να τα λέει όλα αυτά στο κεφ. 3 όταν δεν έχει μιλήσει για πρόγραμμα ακόμα? Δεν θα έπρεπε να τα λέει στο 9?

Εντάξει το να απαντήσω ότι δεν τα λέει επειδή το βιβλίο είναι ένας αχταρμάς καντάει understatement.

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

Απλά το έγραψα γιατί το "υπολογιστική μηχανή" είναι λίγο παραπλανητικό. Ο λογισμός-λ είναι ισοδύναμος με μηχανή turing αλλά το πώς σκέφτεσαι όταν τον χρησιμοποιείς είναι εντελώς διαφορετικό. Ι.e, όταν γράφεις δηλωτικά δεν μπορώ να πω ότι έχεις στο μυαλό σου κάποια "μηχανἠ". Αντιλαμβάνομαι αυτό που λες και δεν διαφωνώ, απλούστατα όμως πουθενά στο βιβλίο δεν ορίζεται αυτό το abstract machine που απευθύνονται οι αλγόριθμοι (εκτός άμα ορίζεται και δεν το θυμάμαι).  Πώς θα συμφωνήσουμε στο πώς γίνεται ο υπολογισμός όταν αυτό δεν προκύπτει de facto από πουθενά;

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

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

Έχεις στο μυαλό σου το interface της δομής που χρησιμοποιείς, ή αν προτιμάς, έχεις ένα abstract data type. Ουσιαστικά έτσι είναι και με τον πίνακα, διδάσκονται οι λειτουργίες του, το interface του, όχι ότι ο πίνακας είναι θέσεις μνήμης και μια άλγεβρα. Ο ψευδοκώδικας όπως το βλέπω, σου δίνει την ελευθερία να πεις, ότι οκ, εγώ χρησιμοποιώ μια δομή που μπορώ να της δώσω ένα index και σε σταθερό χρόνο να κάνει access. Μπορεί η δομή να είναι πίνακας, μπορεί να είναι και unordered_map με κλειδί το index. Δεν με ενδιαφέρει αρχικά, όσο αυτά τα δύο είναι interchangeable αλγοριθμικά.

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

[evry]

Απλά το έγραψα γιατί το "υπολογιστική μηχανή" είναι λίγο παραπλανητικό.

Το χρησιμοποιώ γιατί το θεώρησα πιο εύπεπτο από το να μιλάω για μηχανή Turing

Αντιλαμβάνομαι αυτό που λες και δεν διαφωνώ, απλούστατα όμως πουθενά στο βιβλίο δεν ορίζεται αυτό το abstract machine που απευθύνονται οι αλγόριθμοι (εκτός άμα ορίζεται και δεν το θυμάμαι).  Πώς θα συμφωνήσουμε στο πώς γίνεται ο υπολογισμός όταν αυτό δεν προκύπτει de facto από πουθενά;

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

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

Το σημείο στο οποίο διαφωνούμε είναι ότι εσύ λες ότι δυναμικός και στατικός πίνακας έχουν το ίδιο Interface. Εδώ διαφωνώ. Αν είχαν το ίδιο interface τότε θα έπρεπε να έχουν και ακριβώς την ίδια χρήση και να μην μας ενδιαφέρει η υλοποίηση. Δεν την έχουν όμως.
Δηλαδή θα έπρεπε όταν σου δώσω το interface να λύσεις το πρόβλημα ανεξάρτητα από το αν από πίσω κρύβεται στατικός ή δυναμικός πίνακας. Αυτό δεν ισχύει όμως. Άρα ουσιαστικά από θέμα σύνταξης έχουν το ίδιο Interface αλλά από θέμα σημασιολογίας δεν το έχουν.
Η ρίζα του πρόβληματος είναι ότι το βιβλίο μιλάει για στατικούς πίνακες στην ψευδογλώσσα και δεν δίνει κάποιου είδους δήλωση ώστε να ξέρουμε πότε δημιουργούνται και τι μέγεθος έχουν. Για αυτό στο πρόγραμμα τα πράγματα είναι ξεκάθαρα

Το παράδειγμα που δίνεις πάντως με το VLA είναι πολύ καλό και αντιπροσωπευτικό της δική μας περίπτωσης αλλά δεν δουλεύει σε όλες τις εκδόσεις της C και ούτε στη C++ αφού εκεί έχεις το new. Είναι μόνο για τη νοητή μηχανή της C99 και ίσως της C++11.

[itt]

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

Το interface είναι indexed access σε Ο(1) χρόνο. Το ζήτημα με τη μνήμη είναι θέμα υλοποίησης. Εγώ ξεκινάω υποθέτωντας ότι μπορώ να ορίσω έναν πίνακα(χωρίς να γράψω το μέγεθός του)  και να κάνω access το i στοιχείο του πχ. Αυτός που τον υλοποιεί  όταν ζητάω access σε κάποια θέση , που έστω ότι είναι μεγαλύτερη από το μέγεθος που έχει εκείνη τη στιγμή ο πίνακας, μπορεί να επιλέξει διάφορες στατηγικές για να το αντιμετωπίσει. Εμένα δεν με απασχολεί εφόσον δεν επηρρεάζει αυτό που κάνω. Η ουσία είναι ότι θα πρέπει να έχει ακριβώς ίδια semantics με το στατικό πίνακα.
Αυτό είναι πρόβλημα του vendor όχι του client. Ο vendor σε εμάς αν είναι η Γλώσσα δεν μπορεί να το υλοποιήσει, οπότε θα πρέπει να επανασχεδιάσω τον αλγόριθμό μου. Αν υπάρχει στο βιβλίο κάπου η οδηγία ότι σε ψευδοκώδικα δεν μπορώ να κάνω τέτοιες παραδοχές , τότε συμφωνώ ότι δεν έχει νόημα να το συζητάμε , αλλά βέβαια τότε αυτό δεν είναι ψευδοκώδικας.

Επίσης ένα παράδειγμα σε αυτό που λες. Το framework της microsoft παρέχει ένα interface , το IDictionary. Μόνο μία από τις δομές που το υλοποιηούν είναι thread-safe. Σημασιολογικά και συντακτικά είναι όλες Dictionaries. . Όταν εγώ θέλω access με index σε σταθερό χρόνο, το αν είναι στατικός ή μη ο πίνακας δεν με απασχολεί θεωρητικά. Είτε ειναι στατικός είτε δεν είναι αυτό πρέπει να παραμένει invariant. Αν δεν μπορεί να παραμείνει, δεν είναι πίνακας.

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

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

Το παράδειγμα που δίνεις πάντως με το VLA είναι πολύ καλό και αντιπροσωπευτικό της δική μας περίπτωσης αλλά δεν δουλεύει σε όλες τις εκδόσεις της C και ούτε στη C++ αφού εκεί έχεις το new. Είναι μόνο για τη νοητή μηχανή της C99 και ίσως της C++11.

Kαι αυτό είναι ένα άλλο ενδιαφέρον κομμάτι. Ο αλγόριθμος που αδιαφορεί για την υλοποίηση του πίνακα μπορεί να δουλέξει στην C++ αλλά όχι στη Γλώσσα. Στον ψευδοκώδικά μου όμως δεν θα γράψω πουθενά για std::vector, έγραφα ένα interface, που στη C++ τυχαίνει να έχει το std::vector. Αυτή είναι η ουσία.

[pgrontas]

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

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

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

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

[Mathitis14]

Συμφωνω με αυτο που λες οτι επρεπε να εχει εισαχθει στην διδασκαλια αλλα η εκφωνηση της ασκησης δεν απαγορευει τον πινακα . Πρεπει να γινει κατανοητο οτι δεν υπαρχει κανονας που να λεει προσπαθησε να λυσεις την ασκηση χωρις πινακα και αν δεν σου βγει πηγαινε με πινακα .
Τον πινακα τον χρησιμοποιεις γιατι τα δεδομενα ειναι πολλα ( πιθανον ) και πρεπει να συντηρηθουν μεχρι το τελος . Ουσιαστικα η φασαρια γινεται επειδη ο πινακας εκανε την ασκηση πιο ευκολη . Αν ειναι να κοπουν μορια ας ειναι 1-2 .

[evry]

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

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

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

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

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

[Λαμπράκης Μανώλης]

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

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

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

[Άρης Κεσογλίδης]

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

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

Δηλαδή αν δεν θέλουν να χρησιμοποιηθεί πίνακας δεν μπορεί να μπει διευκρίνηση, και να πει "δεν επιτρέπεται η χρήση πίνακα";
Ή να γίνει ο διαχωρισμός, και να πούνε:
"η λύση χωρίς πίνακα παίρνει όλες τις μονάδες, ενώ αν χρησιμοποιήσετε πίνακα θα πάρετε το πολύ 17 από τις 20 μονάδες του θέματος".

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

Ωραία...και στο βιβλίο επίσης λέει (αλλά κυρίως το λέει η ΛΟΓΙΚΗ) ότι μαθαίνουμε να χρησιμοποιούμε πίνακες για να έχουμε τα δεδομένα αποθηκευμένα και να τα ξαναχρησιμοποιήσουμε όποτε θέλουμε.
Δηλαδή πόσο πιθανό είναι να κάνατε μία εφαρμογή για να κρατάτε στατιστικά στοιχεία και με το που εισάγατε τα στοιχεία μετά την εκτέλεση χάνονταν;; ΚΑΘΟΛΟΥ ΠΙΘΑΝΟ.

Όπως και το 2010 μιλούσαμε για σχολικούς αγώνες, ΚΛΑΣΣΙΚΗ περίπτωση για να κρατήσεις τα στοιχεία, γιατί όποιος έχει να κάνει το πρόγραμμα για σχολικούς αγώνες θα ξέρει από την αρχή πόσοι θα συμμετέχουν.
Όπως και εδώ με την αγορά των προϊόντων δεν θα πάρει κανένας ούτε 1000 προϊόντα ούτε 10000 και τέτοια...

Αν λοιπόν θέλουμε να μην χρησιμοποιούνται πίνακες θα πρέπει να ξεκαθαριστεί το ζήτημα και τουλάχιστον με ΓΛΩΣΣΑ.
Κι εγώ διδάσκω στους μαθητές μου να μην χρησιμοποιούν πίνακα σε τέτοιες περιπτώσεις γιατί μπορεί να υπάρχουν (κακή ώρα, όπως τώρα...και όπως και το 2010 και το 2011) και να τους κόψουν.

Όπως επίσης για αναζήτηση, αν γίνει με ΟΣΟ ή με ΓΙΑ.

Δηλαδή αν θέλει να κάνει ένας μαθητής αναζήτηση και γράψει:

done ←  Ψευδής
ΓΙΑ  i  ΑΠΟ  1  ΜΕΧΡΙ  ν
      ΑΝ  Α[ i ] = Κey  ΤΟΤΕ
            done ← Αληθής
      ΤΕΛΟΣ_ΑΝ
ΤΕΛΟΣ_ΕΠΑΝΑΛΗΨΗΣ
ΑΠΟΤΕΛΕΣΜΑΤΑ //done//

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

Εγώ προσωπικά και πάλι λέω στους μαθητές μου να ΜΗΝ το κάνουν έτσι, αλλά με την ΟΣΟ.

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

Να βγει μια ανακοίνωση από το Παιδαγωγικό Ινστιτούτο, και να μοιράζεται σε όλους τους μαθητές, για τα 2 τουλάχιστον αυτά βασικά θέματα και να λέει ότι δεν επιτρέπεται η χρήση πίνακα σε άγνωστο πλήθος επαναλήψεων ακόμα κι αν είναι λογικό να γίνει με πίνακα στον πραγματικό κόσμο, και η αναζήτηση να γίνεται με ΟΣΟ και να σταματάει ΑΜΕΣΩΣ μόλις εντοπιστεί αυτό που θέλουμε.

Και τότε θα ανοίξει μία συζήτηση για να χρησιμοποιούμε μόνο την "έξυπνη φυσαλίδα" για να σταματάει αμέσως, ή αν θέλουμε μόνο τα 5 μικρότερα στοιχεία ενός πίνακα 20 στοιχείων να λέμε
"ΓΙΑ Ι ΑΠΟ 2 ΜΕΧΡΙ 6" στη φυσαλίδα και πάει λέγοντας..........

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

[Άρης Κεσογλίδης]

 Ωχ...τόσο πολλά έγραψα; Συγγνώμη,  μου ξέφυγε...αλλά πώς να τα χωρίσω;!... 

ΥΓ: Γιατί όταν βάζω αγκύλες για δείκτη πίνακα δεν εμφανίζεται εδώ ο δείκτης; 

[petrosp13]

λαμβάνεται ως html code και τα μετατρέπει σε italics