C++ και υποστήριξη πινάκων

[Timonkaipumpa]

 

 

Το εξήγησα αποπάνε στο post μου, αλλά ας δόσω ένα ΥΠΟΤΙΘΕΜΕΝΟ παράδειγμα:

 

>
int array1[10], array2[23];

array1 += array2;  //πρόταση 1

 

Ξέρω πως αύτη στιγμή ότι η πρόταση 1 είναι pointer arithmetic (άλλος ένας λόγος για τον οποίο δεν γίνεται η C++ να υποστηρίξει πράξεις μεταξύ arrays). Φαντάσου όμως να έκανε αλγεβρική πράξη μεταξύ των πινάκων. Ο compiler θα έπρεπε

να κάνει ένα διάολο bound checkings, κάτι το οποίο είναι ανεπίτρεπτο για C/C++.

 

 

Erevis

 

Και μετά το edit σου... (thnx για το pm, θα σου κάνω και εγώ για αυτό το edit )

 

ΟΚ. Πρέπει να κάνει ένα σωρό bound checks, και εάν έχει πίνακες διαφορετικών διαστάσεων θα γίνει της Μελπομένης!

 

Μαζί σου!

 

Αλλά, δεν μπορεί κάποιος να φτιάξει μία βιβλιοθήκη που να τα κάνει όλα αυτά;

 

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

 

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

 

Έτσι, και μη λαμβάνοντας υπόψη την ταχύτητα και την δυσκολία υλοποίησης (και το πόσο επιρρεπής σε λάθη είναι η διαδικασία) δεν μπορούν να γίνουν ΟΛΕΣ οι αλγεβρικές πράξεις μεταξύ πινάκων σε C++;

 

Συνεπώς... πώς ορίζεται η υποστήριξη;

 

Τίθεται ζήτημα, τελικώς, υποστήριξης ή δυνατότητας υλοποίησης;

[V.I.Smirnov]

@Εrevis

 

Προφανώς αυτό που λες για το διδακτικό μέρος ισχύει.

Τα βασικά πρέπει να μαθαίνονται.

 

Αλλά δεν πρόκειται μόνον για ασκήσεις.

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

 

 

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

Σε μια τέτοια περίπτωση δεν βλέπω γιατί θα πρέπει να γίνονται bound checkings.

Αυτό θα μπορούσε να ενεργοποιείται ή όχι από τον compiler (και ναι, αυτό αλλού μπορείς να το κάνεις).

Όπως και το να κάνεις πράξεις που έχουν απειρίες (INF) ή διαίρεση με 0 :

o compiler δίνει INF (συμοβλική τιμή) και συνεχίζει τις πράξεις μ' αυτό, ακολουθώντας τις συμβάσεις για το άπειρο.

Αλλά αν δεν θέλεις, ρυθμίζεις κάποιο flag να σταματά το πρόγραμμα με error. Πάντα σε release έκδοση (όχι debug).

To ίδιο και με τα bound chekings, μπορεί να αφεθούν είτε στον compiler είτε στον προγραμματιστή.

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

δικαιολογία..

 

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

 

-

[Erevis]

Eννοείται ότι θα μπορούσε κάποιος να γράψει βιβλιοθήκη που να τα κάνει όλα αυτά. Επίσης πιστεύω ότι γίνονται τα ΠΑΝΤΑ άμα έχει κάποιος όρεξη.

Μάλλον δε καταλαβαίνεις ποιο είναι το point μου.

Θα το ξαναπώ,

 

αν αυτό

 

array1 += array2;

 

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

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

[Evgenios1]

@.....

Αντι να κραζεις το κοσμο, κατσε και φτιαξε μια βιβλιοθηκη που να σου κανει αυτη τη δουλεια.

Παρε κανα καλο compiler και δες τα templates, inlinig etc..

Ωριστε μια προσθεση

>namespace Array{
template < class T, unsigned int S >
__inline void Add( T (&arr)[s], T obj )
{
for(unsigned int i = 0 ; i < S ; ++i)
	arr[i] += obj;
}
template < class T, unsigned int S, unsigned int S1 > 
__inline void Add(T (&arr1)[s],T (&arr2)[s1])
{
T min = S < S1 ? S : S1;
for(unsigned int i = 0; i < min ; ++i)
	arr1[i] += arr2[i];
}

template < class T, unsigned int S,class exp >
__inline void Do(T (&arr)[s],exp e)
{
for(unsigned int i = 0 ; i < S  ; ++i)
	e(arr[i]);
}

}


int main(int argc, char *argv[])
{
float ar1[] = {0.123f,0.16f,0.7f,0.883f,0.000000001f};
float ar2[] = {0.04f,0.00002f,0.3f,0.2f};
Array::Add(ar1,-0.2f);
Array::Add(ar1,ar2);
#if _HAS_CPP0X
Array::Do(ar1,[](float &obj) { std::cout<<obj<<std::endl;});
#else
#error Βρες ενα τροπο να εκτυποσεις...
#endif
   return 0;
}

πω πω !! τι κωδικα εγραψα παλι

 

[Timonkaipumpa]

Eννοείται ότι θα μπορούσε κάποιος να γράψει βιβλιοθήκη που να τα κάνει όλα αυτά. Επίσης πιστεύω ότι γίνονται τα ΠΑΝΤΑ άμα έχει κάποιος όρεξη.

Μάλλον δε καταλαβαίνεις πιο είναι το point μου.

Θα σε ξαναρωτήσω,

 

αν αυτό

 

array1 += array2;

 

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

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

 

 

Καταλαβαίνω τι λες...

 

Το θέμα είναι...

 

 

Πως η αλγεβρική πρόσθεση πινάκων (ή και ο πολλαπλασιασμός εάν θες) είναι κάτι που είναι πρωτογενές; Δηλαδή... μέσα στο μηχάνημα (όπως το bit shift) γίνεται αλγεβρική πρόσθεση πινάκων ή γίνεται ανάκληση τιμών από μπλοκ μνήμης και επεξεργασία των τιμών τους;

 

(προφανώς το 2ο)

 

Έτσι... εφόσον το πρωτογενές είναι η ανάκληση τιμών και η επεξεργασία τους... αυτό θα κάνουν "όλοι". Είτε είναι MATLAB είτε είναι C++. Το πώς θα το αναπαραστήσουμε ή το τι "ελευθερία" θα δοθεί στον προγραμματιστή έχει σημασία στο εάν μπορεί να γίνει αυτή η συγκεκριμένη πράξη;

 

Ή μήπως το MATLAB έχει κάποιο μαγικό τρόπο να αποθηκεύει σε ένα μπλοκ μνήμης όλα τα στοιχεία ενός πίνακα και έτσι είναι (κάτι σαν) έναν απλό int;

 

Δεν νομίζω (Τάκη, δεν το βλέπω.. που λέει και η διαφήμιση).

 

Έτσι... είναι ζήτημα υποστήριξης; Πώς ορίζεται η υποστήριξη; Μήπως είναι ζήτημα δυνατότητας υλοποίησης και από εκεί και έπειτα ζήτημα επιδόσεων και ευκολίας γραψίματος του κώδικα;

[V.I.Smirnov]

@Evgenios1

 

Μα κάτι τέτοιο είπα :

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

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

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

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

 

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

Αλλά πού...μόνον εξυπνάδες χορτάσαμε.

Όποιος ξέρει κάποια καλή βιβλιοθήκη πινάκων (πέραν των lapack και scalapack και gnu scientific ας μας πει).

 

 

Για μένα το θέμα έκλεισε και δεν θα ξαναγράψω.

 

-

[Timonkaipumpa]

Βρε Smirnoφούλη...

 

Το ότι δεν μπορείς να χωνέψεις ακόμα τις πατάτες που είπες... δεν σημαίνει ότι εγώ δεν χρησιμοποιώ MATLAB όταν θέλω να κάνω ΜΑΘΗΜΑΤΙΚΟΥΣ υπολογισμούς και προσομοιώσεις...

 

Την ευκολία μου θα κοιτάξω...

 

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

 

εν ολίγης...

 

Θα μπορούσες να πεις ένα "ΟΚ. Είπα λαλακία" και να σωθείς από τον εαυτό σου για τα υπόλοιπα που έκανες...

 

 

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

 

No offense...

 

ούτως ή άλλως.. σπεύδεις να με επιβεβαιώσεις.

 

C ya!

[dop]

Η φιλοσοφία του C++ standards committee είναι να ΜΗΝ προσθέτουν κάτι στο συντακτικό της γλώσσας, εκτός και αν είναι απολύτως απαραίτητο. Εξ ου και η έλλειψη εγγενούς υποστήριξης matrices. Και δεν έχουν και άδικο: εγώ σπανίως χρησιμοποιώ πίνακες και αν χρησιμοποιώ το πολύ πολύ να θέλω μια πρόσθεση και μια αφαίρεση. Οι συνάδελφοί μου θέλουν LU decomposition και υπολογισμό eigenvectors. Και αύριο πρέπει να γράψω μια λύση για conjugate gradient - που ακριβώς θα σταματούσε η γλώσσα;

 

Και εν τέλει πρέπει μια γλώσσα να υποστηρίζει το μακρύ και το κοντό του καθενός, δημιουργώντας έτσι ένα τεράστιο API; Η C++ δεν το χρειάζεται αυτό - είναι μια generic programming language (σε αντίθεση με το MATLAB που είναι μια Domain Specific Language) και είναι μια γλώσσα που θέλει να υποστήριξει από close-to-the-metal μέχρι και functional programming (η Fortran φτιάχτηκε ΑΠΟΚΛΕΙΣΤΙΚΑ για scientific programming). Άρα ουδεμία σύγκριση. Έκαστος στο είδος του.

 

Και για να τελειώνει το FUD, υπάρχουν βιβλιοθήκες για matrix manipulation: armadillo (http://arma.sourceforge.net/), Blitz++ (http://www.oonumerics.org/blitz/'>http://www.oonumerics.org/blitz/), newmat (http://www.robertnz.net/nm_intro.htm), MTL4 (http://www.simunova.com/en/node/24), Boost.uBLAS (http://www.boost.org/doc/libs/1_45_0/libs/numeric/ublas/doc/index.htm). Και αν δεν αρέσει σε κάποιον που υπάρχουν τόσες πολλές (άραγε πόσες φορές θα ακούσω κόσμο να παραπονιέται επειδή υπάρχουν πολλές λύσεις), ένα thin abstraction layer στην C++ δεν κοστίζει τίποτα, εκτός από λίγο χρόνο του προγραμματιστή. Αλλά αυτό το κάνεις μία φορά.

 

Στα πιο τεχνικά, ΟΛΑ τα optimizations που μπορούν να γίνουν σε μία γλώσσα μπορούν να γίνουν και σε μία άλλη - για αυτό και ο GCC έχει κοινό backend για παραγωγή κώδικα. Από την άλλη κάποιες γλώσσες επιτρέπουν στον compiler πιο εύκολα το να βρίσκει data dependencies (ή πολύ απλά αναγκάζουν τον προγραμματιστή να τις αποφεύγει όπως οι functional γλώσσες). Η Fortran έχει το καλό ότι δεν επιτρέπει aliasing (πχ pointers). Από την άλλη η C++ το επιτρέπει για να είναι συμβατή με την C. Μαντέψτε: χρησιμοποιώντας σωστά const και references αφήνετε τον compiler να καταλάβει ακριβώς που υπάρχουν dependencies και που όχι και να παράξει κώδικα αντίστοιχο μιας Fortran υλοποίησης.

 

Τα τελευταία χρόνια, η υποστήριξη της C++ γίνεται καλύτερη με κάθε compiler release. Μερικά (παλιά) αποτελέσματα για παράδειγμα από το Blitz++ (http://www.oonumerics.org/blitz/) : http://www.oonumerics.org/blitz/benchmarks/acoustic.html , http://www.oonumerics.org/blitz/benchmarks/acou3d.html (τα τελευταία δύο χρόνια η απόδοση είναι η ίδια). Πάει και αυτό...

 

Και κλείνω με κάτι που το έχω αναφέρει ξανά: όλα τα μεγάλα national labs στις ΗΠΑ μεταγράφουν τον Fortran κώδικα σε C++ ή αναπτύσσουν τις καινούριες βιβλιοθήκες σε C++. Και μιλάμε για προγράμματα που κοστίζουν εκατομμύρια και χρειάστηκαν χρόνια ανάπτυξης. Για να το επιλέγουν αυτοί (που το 70%-80% έχει PhD και αναρίθμητες ώρες έρευνας) κάτι θα ξέρουν.

[Timonkaipumpa]

 

Και κλείνω με κάτι που το έχω αναφέρει ξανά: όλα τα μεγάλα national labs στις ΗΠΑ μεταγράφουν τον Fortran κώδικα σε C++ ή αναπτύσσουν τις καινούριες βιβλιοθήκες σε C++. Και μιλάμε για προγράμματα που κοστίζουν εκατομμύρια και χρειάστηκαν χρόνια ανάπτυξης. Για να το επιλέγουν αυτοί (που το 70%-80% έχει PhD και αναρίθμητες ώρες έρευνας) κάτι θα ξέρουν.

 

 

Μπα, δεν νομίζω Τάκη.. δεν το βλέπω. Δεν ξέρουν ότι η C++ δεν υποστηρίζει πίνακες και κάνουν λαλακίες. Δεν πα να 'χουν 5κ PhD; Αφού η C++ δεν υποστηρίζει πίνακες! Τι ξέρουν δαύτοι;

 

 

Το πρόβλημα είναι ότι η C/C++ δεν υποστηρίζει πίνακες !

-

 

:D

[jstark]

>#include <boost/numeric/ublas/matrix.hpp>
#include <boost/numeric/ublas/io.hpp>

int main ()
{
       using namespace boost::numeric::ublas;

       int N = 4, M = 10;
       matrix<double> m (N, M);
       for (unsigned i = 0; i < m.size1 (); ++ i)
               for (unsigned j = 0; j < m.size2 (); ++ j)
                       m (i, j) = 3 * i + j;
       std::cout << m << std::endl;
       return 0;
}

 

Smirnov τι ακριβως απο το παραπάνω παράδειγμα δε σε βολευει ;