Diskussion:Feld (Datentyp)

Auf dieser Seite werden Abschnitte ab Überschriftebene 2 automatisch archiviert, die seit 14 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Die Archivübersicht befindet sich unter Archiv.

Indizes

Mir faellt auf, dass bei der allgemeinen Formel die Indizes nicht definiert sind. Das ist formal falsch und sorgt erstmal fuer Verwirrung!

Realisierung in Programmiersprachen

Ein Kapitel über die Realisierung wäre m. E. sinnvoll. In Pascal z. B. gibt es das Array als (auch mehrdimensonalen) Datentyp, in Java einen ganzen Zoo von Collection-Typen; in Python kann man Arrays als Tupel realisieren, wobei diese auch Elemente gemischter Typen enthalten können. Ach ja, und eine Matrix kann durchaus mehr als zwei Dimensionen haben... --Tobias 12:54, 3. Aug. 2007 (CEST)

Assoziatives „Array“

Das sogenannte „Assoziative Array“ (besch...ener, aber leider mangels eines griffigen deutschen Worts üblicher Name; Zuordnungstabelle?) ist kein Array und hat m. E. in diesem Artikel nur als einmaliger Querverweis etwas verloren. Die ständige Verwendung von „(Standard-) Array“ ist einfach nur krampfig.

Nach meiner Auffassung hat ein Array außerdem immer eine feste Größe, im Gegensatz etwa zu Listen, Stacks, Queues usw., die oft als verkettete Listen realisiert werden. Zu letzteren bildet das Array den Gegensatz. Widerspruch, Zustimmung, Präzisierungen? --Tobias 13:04, 3. Aug. 2007 (CEST)

"Einheitlicher Datentyp"

Mal abgesehen davon, dass nicht der Datentyp einheitlich ist, sondern das Feld einheitlich Exemplare desselben Typs haben, stimmt das mal wieder nicht. Cocoa-Arrays etwa können heterogen sein. Entscheidend ist vielmehr, dass eine geordnete Sammlung von Exemplaren ist.

84.44.148.85 23:07, 26. Dez. 2007 (CET)

Dann hat Cocoa (und Ruby?) offensichtlich eine etwas abweichende Auffassung, was Arrays sind; das wäre m.E. ein Sonderfall. Siehe unten unter Definition. --Tobias 12:00, 19. Jan. 2011 (CET)

Arrays können Daten eines einheitlichen Datentyps....

zitat:

Mit Hilfe eines Arrays können Daten eines einheitlichen Datentyps geordnet so im Speicher eines Computers abgelegt werden, dass ein Zugriff auf die Daten über einen Index möglich wird. Das (Standard-)Array verwendet im Gegensatz zum assoziativen Array einen ganzzahligen Index zur Adressierung.

....

der datentyp der elemente muss nicht in allen prog.sprachen gleich sein bsp. Ruby

Handelt es sich dabei in Ruby wirklich um Arrays oder eher um Listen? Listen können auch in Python heterogen sein; sie sind aber von ihrer (z. B. in der Größe veränderlichen) Natur her etwas völlig anderes als Arrays.

In jedem Fall würde ich sagen, daß zu den typischen Eigenschaften eines Arrays gehört, daß es Elemente eines einzigen Typs enthält. Abweichungen könnten dann ja entsprechend in einem speziellen Abschnitt erwähnt werden. --Tobias 12:00, 19. Jan. 2011 (CET)

Naja, also in Java kannst Du auch ein Array vom Typ Object[] deklarieren und dann aufgrund der Vererbung alles mögliche als Elemente speichern und zwar bunt gemischt... Matrizen können in Java unterschiedlich lange Zeilen haben...

Auch die aufeinanderfolge Speicherung der Elemente (gar noch bei mehreren Dimensionen...) ist nicht zwingend in allen Programmiersprachen und die Indexrechnung schon gar nicht...

Sollten wir das Array nicht als abstrakten Datentyp sehen? (feste Anzahl Elemente, random access über Index zum Lesen und Schreiben der Elemente, möglicherweise noch Iterieren über die Elemente und Zuweisen und Kopieren des ganzen Arrays als Operationen?

Danach kann ja auch beschrieben werden, wie verschiedene Sprachen das umsetzen. Ein bisschen Historie (erste Datenstrukur überhaupt) fände ich auch nicht schlecht und die Analogie zur Hardware (Speicher = Array)...--Graf Alge 02:02, 2. Mai 2011 (CEST)

Die Anregung mit den nicht so festgelegten Array-Inhalten habe ich versucht umzusetzen. Aber zur Historie weiß ich da zuwenig, kannst Du das nicht formulieren? - Ich halte weniger davon, nach Mathematikerart erstmal ganz allgemein von irgendeinem abstrakten Datentyp namens Array auszugehen und dann die reale Anwendung planmäßig aus dem Auge zu verlieren. Lieber ist mir ein Ansatz wie jetzt, wo man vom Speziellen zum immer mehr Allgemeinen fortschreitet, die assoziative Variante hatten wir ja sogar schon drin. --PeterFrankfurt 03:40, 2. Mai 2011 (CEST)

Ne, so stimmt das eigentlich auch nicht. Ehrlich gesagt, hab ich es bewusst nicht in den Artikel sondern hier in die Diskussion geschrieben, weil ich weiss, dass es nicht so einfach zu korrigieren ist. Ein Java-Array sieht eben im Quelltext (fast) genauso wie eins in C oder C++ aus - ist aber völlig anders realisiert. Insbesondere werden die Elemente eben nicht linear nebeneinander gespeichert (was in C++ ja streng genommen auch schon so ist). Ich hab leider nicht genug Zeit hier wirklich eine gute Lösung zu formulieren. Sorry. Die assoziativen Arrays (= Map in Java) würde ich hier auch ganz rausnehmen wollen...--Graf Alge 15:25, 2. Mai 2011 (CEST)

Und wenn Du hier mal eine Formulierung in Kladde vorschlägst? Und wieso sollen die assoziativen Arrays dann gleich ganz raus? Ist ja eigentlich eine konsequente Weitertreibung der Abstrahierung über das Maß bei Java hinaus. --PeterFrankfurt 02:59, 3. Mai 2011 (CEST)

Zu den assoziativen Arrays s. die Abschnitte Diskussion:Feld (Datentyp)#Assoziatives „Array“ und Diskussion:Feld (Datentyp)#Definition - ich stimme Tobias diesbezüglich voll zu.

Zur Formulierung: Ich halte das ganze Sammelsurium von Artikeln in Wikipedia zu Datenstrukturen für stark und grundsätzlich überarbeitsbedürftig (wie offenbar auch viele andere Leute) und sehe daher wenig Nutzen in lokalen kleinen Verbesserungen. Meine Zeitressourcen sind beschränkt - mehr als kleine Änderungen schaffe ich einfach nicht - mach ich daher vor allem dort, wo ich eine etwas längere Halbwertszeit meiner Texte erwarten kann. Vielleicht hat ja irgendwann irgendwer mehr Zeit für dieses Thema - dann beteilige ich mich gern.

Allerdings: Das Thema "Datenstrukturen" erfordert wohl - nicht nur in Wikipedia - eine neue Phase der Theoriebildung - die meisten Lehrbücher sind immernoch pascalgeprägt - also von der Praxis längst überholt - für neue schlüssige Systematisierungen, die auch für modere Programmierkonzepte passen, fehlen schlicht auch Quellen. Und auch die Fachleute sind wohl noch nicht einig. Müssen wir wohl noch Geduld haben. --Graf Alge 11:02, 3. Mai 2011 (CEST)

Tja, dann wird das nie was, nach meiner Erfahrung. Der ganz große Rundschlag gelingt nicht mehr, weil schon so viel Masse da ist, die man nicht auf einmal neu erschaffen kann. Und im Ernstfall wird sie von den jeweiligen Vor-Autoren auch mit Zähnen und Klauen verteidigt. Es geht nur über inkrementelle Schritte. Nur als naheliegendes Analogon: Der ganze Komplex Prozessor, Hauptprozessor, Zentraleinheit, Computer etc. ist irrsinnig wirr und undurchschaubar aufgeteilt, da kommt seit Jahren niemand mehr gegen an. --PeterFrankfurt 03:00, 4. Mai 2011 (CEST)

Ja, so ist es halt. Wikipedia und das Leben. Es gibt Realitäten und Wünsche. Manche gehen manchmal in Erfüllung ;-) --Graf Alge 11:02, 4. Mai 2011 (CEST)

Jagged Array

Einige Sprachen bieten auch sogenannte "jagged arrays" an. Sollte das auch erwähnt werden, und wenn ja wo? Welche deutsche Bezeichnung ist geläufig? -- bsdev 15:54, 23. Nov. 2008 (CET)

Tja. Was ist das denn? Ein schneller Blick auf en:Jagged array hat mir da nicht wirklich geholfen... --Tobias 12:00, 19. Jan. 2011 (CET)

Die spielen bei mehrdimensionalen Arrays / Tensoren eine Rolle, wenn man erlaubt, dass die Unter-Arrays verschiedene Größen haben können. Also bei einem 2D-Array kann man es sich als eine Matrix vorstellen wo die Zeilen verschieden lang sein können. Daher kommen die Zacken (ragged), wenn man es sich bildlich vorstellt. Bei TensorFlow gibt es dafür zum Beispiel die RaggedTensor Datenstruktur und ich persönlich bin mit dem awkwardarray package für Python vertraut, welches auf NumPy aufbauend Jagged Arrays implementiert, weil die für bestimmte Arten von Datensätzen eine wichtige Rolle spielen.

--Elimik31 (Diskussion) 23:02, 21. Okt. 2020 (CEST)

Definition

Ich finde, wir sollten uns hier auf echte Arrays beschränken (meine Vorstellung davon ist von Pascal geprägt, wenn auch die Indizierung ansonsten üblicherweise mit 0 beginnt):

• Ein Array ist ein geordnetes Feld unveränderlicher Größe; man kann sich (bei 2 Dimensionen) einen rechteckigen Acker (Feld) wie beim Kuhfladen-Bingo vorstellen
• Der Zugriff auf ein Array-Element ist sehr schnell, weil die Speicheradresse auf einfache Weise aus den Indices berechnet werden kann
• Demzufolge enthält ein Array stets Elemente eines einheitlichen Typs und einheitlicher Größe (im Sinne von Speicherplatzbedarf)
• Ein Array ist niemals als verkettete Liste o.ä. implementiert.

Wir sollten nicht so tun, als wären „assoziative Arrays“ eine Art Array. Sie gehören einmalig erwähnt, weil der Name nun mal eingeführt ist; die Verwandschaft ist aber eher linguistischer Natur. Der entsprechende Abschnitt hier gehört entfernt oder zumindest im Sinne einer klaren Abgrenzung umgestaltet. --Tobias 12:00, 19. Jan. 2011 (CET)

Jein, ein bisschen anders sehe ich das schon:

• Ich würde immer mit einem eindimensionalen Array anfangen, z. B. einer Messreihe mit Werten gefüllt.
• Erst in einem zweiten Schritt dann die mehrdimensionalen einführen, und da gern mit so einem Beispiel einsteigen. Bei der Speicherabbildungsfunktion habe ich ja so in der Art formuliert.
• Schneller Zugriff: Das Problem ist aber gerade, dass man da nicht schludern darf, sonst ist man Größenordnungen langsamer als möglich. Und die Schnelligkeit ist in meinen Augen auch nicht der Kernaspekt, warum man Arrays verwendet, sie werden eben einfach benötigt, wenn man mehrere gleichartige Elemente vorliegen hat, auf die man per Indexnummer zugreifen will, entfernt vergleichbar einem RAM (mit random access) im Gegensatz zu sequentiellem Zugriff.
• Ansonsten durchaus d'accord. --PeterFrankfurt 00:33, 20. Jan. 2011 (CET)

gudn tach!

der begriff "array" wird nun mal nicht einheitlich verwendet, deswegen sollten wir auch nicht von "echten" arrays sprechen, wenn es keine einheitlichen (programmiersprachenuebergreifenden) konventionen dazu gibt. -- seth 22:53, 4. Mär. 2013 (CET)

Jedenfalls ist hier ein 'Array' beschrieben, obwohl das Lemma 'Feld' heißt. Das kommt m.E. aus einer Form der englischen Übersetzung, erscheint mir aber für deutsch inkorrekt. Feld und Array (Tabelle ...) sind zwei unterschiedliche Dinge und sollten deshalb zwei getrennte Lemmas sein. --VÖRBY (Diskussion) 18:59, 7. Mai 2013 (CEST)

Ich habe mich durch Literatur und Onlinequellen durchgeschmökert und herausgefunden, dass 'Feld' in der Programmierung zwei Hauptbedeutungen hat: Die aus engl. 'Array' abgeleitete und die i.S. Variable, Datenfeld o.ä. Ich habe den Artikel deshalb ergänzt und die abweichende Bedeutung herausgestellt und belegt.

Dass es innerhalb der 'Array'-Bedeutung mehrere Varianten gibt, ist wohl Tatsache - wie auch weitere diesbezügliche Unterscheidungen in einzelnen Sprachen. Performance-Diskussionen sind hier, wenn überhaupt, nur am Rande zweckmäßig.

Zu Feld i.S. Array bin ich der Meinung, dass hier eine unglückliche Übersetzung ins Deutsche vorliegt - die es aber nun mal gibt. Siehe dazu auch die Links im Artikel. Möglicherweise wurde die Übersetzung 'Feld' (für Array) tatsächlich aus der Bedeutung 'zweidimensionales Flächenobjekt (ähnlich 'Acker') gewählt; das könnte 'array' sinngemäß entsprechen, scheint mir aber i.S. 'Variable' kaum vermittelbar. So haben wir (wieder mal) einen Ausdruck mit mehreren Bedeutungen. Und das muss das Lemma zeigen. M.E. also ERLEDIGT. --VÖRBY (Diskussion) 11:03, 13. Mai 2013 (CEST)

Allgemeingültig / sprachspezifisch

Der Artikel ist vor Allem in seinen ursprünglichen Teilen m.E. in erheblichem Maß sprachspezifisch formuliert. Ich denke, das sollte geändert werden; der Leser sollte Allgemeingültiges und Sprachspezifisches unterscheiden können. Das zeigen auch mehrere der alten Diskussionen.

Zur Lemmabezeichnung (ebenfalls sehr kontrovers diskutiert): Das Lemma heißt 'Feld (Datentyp)' und gilt als Übersetzung von 'array'. Der Englisch-Verweis zeigt auch nach en:array und en:array zeigt hierher. Soweit ok, denn die andere, wohl allgemeinere Bedeutung von 'Feld' ist zwischenzeitlich im Artikel erwähnt und erläutert.

Was Arrays betrifft:

• es ist kein Datentyp, sondern eine Datenstruktur)
• ja, was bisher im Artikel gesagt wird, ist hochgradig sprachspezifisch
• Mit einem array kann man multiple, ggf. zwei- oder mehrdimensionale Daten verarbeiten.
• Entsprechende Datenkonstrukte kann man in allen Programmiersprachen anlegen - und natürlich auch verarbeiten.
• Sprachspezifisch gibt es dazu aber erhebliche Unterschiede (siehe auch Artikel), die sich sowohl beim Deklarieren als auch beim Ansprechen solcher Daten, zum Teil auch durch spezielle Begriffs- und Wortbildungen darstellen. Dies muss im Artikel berücksichtigt werden.
• So zum Beispiel dürfte es nicht allgemeingültig, evtl. sogar falsch sein, dass bei assoz. Arrays kein Index vorhanden ist. Anscheinend gibt es aber in bestimmten Sprachen Unterstützung zur Adressierung einer bestimmten 'Zeile' anhand einer 'assoziierten' Variable. Das würde man in anderen Sprachen z.B. mit 'Search' vorbereiten - wodurch eine 'Position' (Index ...) geliefert wird. In Arrays ist also - begriffsimmanent! - immer eine Art von 'Positionierung' von Bedeutung. Dieser Wert wird zur Berechnung der realen Adresse verwendet, wodurch letztlich unter Anwendung einer passenden Adressierungsart bei der Befehlsausführung die richtige Datenzelle adressiert wird. Sogar bei ASS-Programmen ist das so; dort bildet man (nach irgendeinem Algorithmus) einen positionsabhängigen 'Distanzwert' zum ersten Index (der z.B. in einem Indexregister abgelegt wird).
• Die unter 'Standardfeld' beschriebenen Einschränkungen und Besonderheiten sind wohl auch in vielen Sprachen nicht relevant - oder diese Unterscheidung gibt es dort nicht. Alleiniges Kriterium für Standardfeld müsste sein: Die Position (Index) der relevanten Daten im Array kann direkt aus einer anderweitig vorhandenen Variable 'bezogen' (ermittelt) werden.

Wer ist meiner Meinung? Dass in den Aussagen klar sein muss, ob etwas immer so ist oder ob es in bestimmten Sprachen ´(evtl. welchen) so ist. Oder weitere Vorschläge. Bitte Feedback. --VÖRBY (Diskussion) 10:22, 15. Mai 2013 (CEST); erweitert: --VÖRBY (Diskussion) 11:24, 18. Mai 2013 (CEST)

Textentwurf

Unterschiede je Programmiersprache _{(später == Überschrift)}

In einzelnen Programmiersprachen wird die Deklaration und Verarbeitung von Arrays unterschiedlich unterstützt. Nachfolgend werden wesentliche sprachspezifisch Besonderheiten erläutert:

Assembler IBM 360/390

Keine explizite Sprachunterstützung und Terminologie für Arrays: Deklaration von Feldern wie bei normalen Variablen. Manuelles Reservieren des Arbeitsspeichers für weitere multiple Felder. Initwerte durch manuelle Befehle setzen. Ermitteln der Array-Position über programmierte Algorithmen (Schleifen etc.). Adressierung von Elementen z. B. durch vorgeschaltete Multiplikationen (Felddistanz + ((Index - 1) * Gesamtlänge der Arrayfelder)), deren Ergebnis in einem Indexregister bereitgestellt wird.

Cobol

Beispiele siehe . Arrays werden einheitlich 'Tabelle' genannt. Deklaration über die OCCURS-Klausel (bei Datengruppen und/oder elementaren Feldern möglich). Je nach Cobol-Version 3 bis 16 Dimensionen (hierarchische Stufen). Beliebig viele Felder/Attribute möglich. Elemente können alle Datentypen aufweisen. Keine explizite Unterscheidung zwischen Standardfeld und assoziativem Array. Einfache Initialize-Funktionalität. Adressierung über 3 Methoden: Subskript (der Adressversatz eines Befehlsziels wird je Befehl aus einem gegebenen numerischen Wert berechnet); Indizierung (Adressversatz wird über programmierten Set-Befehl eingestellt und gilt bis zum zeitlich nächsten 'Set'); Direktindex (Adresse wird vom Compiler berechnet und im Befehl direkt eingesetzt). SEARCH-Befehl zum Positionieren des Index bei assoziativen Arrays nutzbar. Mit dem Depending-On-Zusatz können Datenstrukturen variabler Länge behandelt werden.

C / C++

'Array' wird nur eine Struktur mit Elementen gleichen Typs genannt; ungleiche Datentypen werden 'Struktur' genannt. Weiteres noch ergänzen ....

weitere Sprachen noch ergänzen

<text>

Einzelnachweis: (hier temporär)

Diskussion zum Entwurf

Eine Frage wäre, ob die Unterscheidung Standardfeld / assoz. Array sprachspezifisch ist oder allgemeingültig. Jedenfalls unterscheiden dies nicht alle Sprachen, z.B. mit eigenen Sprachkonstrukten.--VÖRBY (Diskussion) 13:00, 21. Mai 2013 (CEST)

Verschieben

Darüberhinaus ist der Klammerzusatz hier falsch: Unter Datentyp findet sich zum Beispiel keine Ausprägung, die 'Array' oder 'Feld' heißen würde. DT wird als Typisierung eines Elements verstanden. Richtig wäre 'Datenstruktur'. Eine "Verschiebung" wäre also dringend erforderlich. --VÖRBY (Diskussion) 08:32, 18. Mai 2013 (CEST)

Das war ein Irrtum: Unter Datentyp gibt es bei den 'Zusammengesetzten Datentypen' diese Begriffe. Sorry. Erledigt. --VÖRBY (Diskussion) 10:37, 5. Jul. 2013 (CEST)

Beispiele, '…' oder „“ für Strings

hierher verschoben von Benutzer Diskussion:Arilou#Anführungszeichen (bei 'Feld)' ; --arilou (Diskussion) 09:32, 18. Nov. 2014 (CET)

Hallo, in welcher Programmiersprache werden Literale mit typografische Zeichen (öffnendes Zeichen unten, schließendes Zeihen oben) formuliert? Es sind m.E. immer gleiche Zeichen, zB einfache oder doppelte Anführungszeichen. Dein Revert [5] wäre also nicht ok. --VÖRBY (Diskussion) 18:05, 17. Nov. 2014 (CET)

In den meisten Programmiersprachen werden Zeichenketten in den US-typografische Zeichen ("") eingeschlossen, die auch im (englischen) Fließtext für wörtliche Rede verwendet werden, analog zu den deutschen „“. Nur in wenigen Programmiersprachen können Strings auch in Apostrophe (') eingeschlossen werden, in manchen Sprachen werden (') anderweitig verwendet, z.B. um Symbole anzugeben.

Im konkreten Artikel-Abschnitt Feld (Datentyp)#Beispiele wird Pseudocode verwendet; dieser sollte dem Leser möglichst deutlich zeigen, was gemeint ist. Die Beispiel-Werte vom Typ "String" sind imo deutlich besser als „Zeichenkette“ gekennzeichnet mit „“ als mit '…' .

--arilou (Diskussion) 09:32, 18. Nov. 2014 (CET)

Ja, in den meisten Programmiersprachen werden Zeichenketten in doppelte Anführungszeichen eingeschlossen. Allerdings sind das aus gewichtigen technikgeschichtlichen Gründen die auf jedem klassischen Fernschreibterminal vorhandenen typewriter double quotes (" "). Die im englischen Fließtext gebräuchlichen typografischen Anführungszeichen (“ ”) finden aus denselben Gründen bislang fast nirgends Verwendung (Ausnahme: Visual Basic .NET) – die einfachen Anführungszeichen der Fernschreibertastatur (' ') dagegen viel häufiger. Siehe: en:Quotation mark und en:String literal.

Typografische Anführungszeichen bieten zwar für die Programmierung durchaus Vorteile, da sie das vordere und das hintere Ende eines Strings eindeutig kennzeichnen, was Syntaxanalyse und Debugging vereinfachen kann. Aber erst seit wir Unicode (und Unicode-fähige Software) haben, lassen sich für diese Zeichen überhaupt eindeutige digitale Codes vereinbaren. Bis dahin waren sie zwar auf einigen regionalen und herstellerspezifischen Codepages verfügbar, aber auf unterschiedlichen Plätzen. Siehe: en:Code page. Man hätte zu jedem Programm in einem Headereintrag angeben müssen, mit welcher Codepage es zu editieren und zu kompilieren ist. Das scheint niemandem im Ernst eingefallen zu sein.

Da der hier gezeigte Pseudocode durch seinen Zuweisungsoperator (:=) eine Verwandtschaft mit Pascal erkennen läßt, hatte ich auch die in Pascal verwendeten typewriter single quotes (' ') eingesetzt. Allerdings stammen Pascal und sein Zuweisungsoperator von ALGOL ab, wo die double quotes (" ") verwendet wurden. Diese passen also ebensogut in den Kontext. Üblicher sind sie, wie Du ja sagtest, auf jeden Fall. Mit ihnen wäre ich einverstanden.

Dein Anliegen, arilou, dem Leser möglichst deutlich zu zeigen, was gemeint ist, teile ich hundertprozentig. Mit typografischen Anführungszeichen wird man diesem Anliegen aber mMn nicht gerecht, denn sie zeigen etwas anderes als das, was realistischerweise gemeint sein sollte. Ich habe als Ausbilder mitbekommen, wie junge Kollegen ihre Programme mit Office-Software zu schreiben versuchten und sich wunderten, daß ihre typografisch sauber getippten Programme nicht funktionierten. Haaresträubend, aber in einer Welt, in der schon Schulkinder zu MS-Word-Benutzern erzogen werden, kein Wunder. Darum halte ich Programmcode-Beispiele, die Stringliterale in typografische Anführungszeichen setzen, für nicht hilfreich. Falls zukünftige Versionen der üblichen Programmiersprachen die typografischen Anführungszeichen erlauben, werde ich meinen Standpunkt gern revidieren.

Gruß--Liberatus (Diskussion) 12:33, 19. Nov. 2014 (CET)

Auch meine Meinung. Wenn das kein sprachspezifisches Beispiel sein soll, könnte man auf Anführungszeichen auch ganz verzichten. Ich halte '' oder "" aber für besser. Kompromissvorschlag: Notation einer konkreten Programmiersprache verwenden und diese im Einleitungstext auch nennen.

Siehe auch meinen Beitrag in Diskussion:Anführungszeichen. zuletzt: --VÖRBY (Diskussion) 16:08, 19. Nov. 2014 (CET)

Datenfeld v.s. Feld

Der Eintrag für Datenfeld ist eindeutig den Datenbanken zugeordnet und ist mit Field_(computer_science) verknüpft. Es wird im Artikel Feld (Datentyp) aber nicht angegeben, dass man zum Feld auch Datenfeld sagt. Interessanterweise ist aber ein associative array ein assoziatives Datenfeld. Passt irgendwie nicht zusammen.--Sae1962 (Diskussion) 12:23, 27. Mär. 2015 (CET)

Bei 'Synonyme' steht, dass man zu Feld (iS Array) auch 'Datenfeld' sagt. Bei #Abweichende Bedeutung ist beschrieben, dass dieser Ausdruck auch für 'normale Datenfelder' verwendet wird und es wird auch dorthin verlinkt. Also in beiden Fällen sind die anderen Ausdrücke erwähnt. --VÖRBY (Diskussion) 17:39, 27. Mär. 2015 (CET)

Dimension

@VÖRBY: Man sollte den Begriff Dimension ein bisschen erklären und zumindest darauf verlinken können. Die exakte Erklärung kann auch u.U. später kommen. --Nomen4Omen (Diskussion) 12:04, 31. Mär. 2015 (CEST)

Seh' ich auch so, und hab' mal einen kurzen Abschnitt eingefügt;

außerdem war das letzte Beispiel didaktisch nicht sehr schön.

--arilou (Diskussion) 15:56, 31. Mär. 2015 (CEST)

Hallo, ich glaube, da liegt ein Missverständnis vor: Mit Dimensionen wird bezeichnet, wie oft in einem Array (= auch Tabelle genannt) "geschachtelt" werden kann (Tabelle in Tabelle, beides auch mit mehreren Elementarfeldern). Das ist ein Unterschied zu einer Zeilen-/Spalten-Sicht (= "Matrix"). Oder liege ich da falsch?

Dann: Vielleicht sollte die Erläuterung zu Dimension nicht bei 'Standardfeld' stehen, denn dort gibt es immer nur 1 Dimension. ::Gelöschtes Beispiel: Es beschrieb aber den einfachen Fall 'Standardfeld' weniger kompliziert als das jetzige Beispiel. --VÖRBY (Diskussion) 17:45, 31. Mär. 2015 (CEST)

"Oder liege ich da falsch?" ~ (Eher 'Ja, du liegst falsch':) "[...] bei 'Standardfeld' [...] gibt es immer nur 1 Dimension." - das ist nun ganz sicher falsch. Ein "Standardfeld" (in der Bedeutung von "Standard" wie im Artikel) kann 1D, 2D, n-dimensional sein. "Standard" unterscheidet es von "assoziativ" und hat keine Aussage über die Dimensionsanzahl.

"Wie oft 'geschachtelt' werden kann" _ist_ die Anzahl der Dimensionen.

Ein "Standard-Array" kann mehrdimensional sein - so ist ja dann auch der gesamte Abschnitt "Adressierung" aufgebaut (oder was glaubst du, warum die Formeln darin so kompliziert sind *g* ...)

'Liste' (1D) und 'Matrix' (2D) sind die häufigsten 'Standardarrays', aber n-Dimensional ist eine simple Abstahierung davon - innerhalb einer Programmiersprache gibt's keinen Unterschied.

--arilou (Diskussion) 10:40, 1. Apr. 2015 (CEST)

Danke für die Hinweise. Passt. Mir schien nur das 2D-Beispiel Zeile/Spalte zu einfach und deshalb potentiell unrichtig. Ich denke, es kommt (bzgl. des Begriffs 'Dimension') nicht darauf an, ob mit einem beliebigen (zB dem zweiten) Index ein Einzelfeld (Spalte) oder eine Datengruppe (bzw. ein Feld in dieser Datengruppe) adressiert wird. Innerhalb einer solchen Datengruppe könnte als 3. Dimension nochmal eine solche auftreten. Diesen Aspekt sollte man unter 'Dimension' auch finden.

Noch ein redaktioneller Hinweis: Die Beispiele bitte nicht zu sehr auf Programmierer ausrichten, die diese Sprache kennen, sondern eher auf die OMA. --VÖRBY (Diskussion) 11:11, 1. Apr. 2015 (CEST)

"Mir schien nur das 2D-Beispiel Zeile/Spalte zu einfach und deshalb potentiell unrichtig."
Es ist recht üblich, ein 2dim. Feld mit "Zeile" und "Spalte" zu veranschaulichen; aber du hast Recht, dass

• das nur bis 2D funktioniert;
• eine solche Einteilung sehr auf eine 'grafische Form' des Arrays abzielt anstatt z.B. auf inhaltliche Gliederung;
• es technisch kein Fehler darstellt, nicht [zeile][spalte] sondern [spalte][zeile] zu adressieren - geht auch;
• es bei z.B. Zeilen/Spalten in Excel möglich ist, statt einer "ganzen Zeile" eine "ganze Spalte" auszuwählen; bei einem 2D-Array feld[zeile][spalte] kann zwar mit feld[zeile] mitunter eine ganze Zeile ausgewählt werden, aber nur bei wenigen Sprachen kann man z.B. mit feld[][spalte] eine "ganze Spalte" auswählen ~ d.h. meist ist ein "späterer Index" den vorigen "untergeordnet" statt echt-gleichwertig...
• ein Index muss auch nicht zwingend eine Ganzzahl sein - in manchen Sprachen genügt es, wenn die "Indexgröße" sich auf eine Ganzzahl abbilden lässt (z.B. eine Enumeration als Index).

Bzgl. der "Sprache" - ist das denn eine konkrete? Ich dachte, das sei einfach irgend ein Pseudocode?

--arilou (Diskussion) 15:52, 1. Apr. 2015 (CEST)

Dass die zweite und weitere Dimensionen Datengruppen sein können, sollte man im Text finden, vlt auch bei den Beispielen.

Ich halte es auch nicht für zweckmäßig, die Adressierung so umfassend auf 'Zeile/Spalte' festzulegen; es sind einfach die Indizes mit ihren Ausprägungen, auch bei 2D (zB Name Index1 = 'Abteilung', Name Index2 = 'Adressdaten' (bis zu 4mal, Datengruppe).

Zu Sprache: Sorry, ich bezog das eher auf die Diskussionstexte, nicht auf den Artikeltext. Also ok.

Das solls aber nun von mir gewesen sein. --VÖRBY (Diskussion) 17:43, 1. Apr. 2015 (CEST)

@arilou Ich bin (fast) einverstanden mit deinen Edits. Insbesondere das Beispiel 1 bringst du besser heraus. (Nur das freien bei den freien Plätzen ist überflüssig.) Aber oben mit Intervallgröße bin ich nicht einverstanden. Mein Ziel war eigentlich, herauszuarbeiten, dass der Dimensionsbegriff auf 2 verschiedenen Ebenen benutzt wird, und Leute, die mal was von einem 3-dimensionalen Vektor oder was von der 4. Dimension gehört haben, darauf aufmerksam zu machen, dass ein 3-dimensionaler Vektor des ℝ³ in den Programmiersprachen den Datentyp float[3] hat, was in den Programmiersprachen als 1-dimensionaler Vektor angesehen wird. M.a.W.: Im programmiersprachlich 1-dimensionalen Vektor des Datentyps float[n] lassen sich n-dimensionale Vektoren aus dem ℝⁿ unterbringen. --Nomen4Omen (Diskussion) 10:14, 1. Apr. 2015 (CEST)

"dass ein 3-dimensionaler Vektor des ℝ³ in den Programmiersprachen den Datentyp float[3] hat"

Und damit bist du genau in die Falle getappt, die ich (als Edit-Kommentar) mit "Missverständlich" meinte.

Man kann nämlich die Dimensionen eines Vektorraums entweder

1. bei der Beschreibung eines Vektors selbst betrachten (so wie du es machst):
   "Ich will einen Vektor abspeichern, der braucht 3 Koordinaten, dafür brauche ich eine Liste mit 3 Einträgen."
2. oder den Raum erfassen wollen, den die Dimensionen aufspannen (wie z.B. im Beispiel 3). Dann fallen die Raum-Dimensionen (x;y;z) mit den (Orts-)Vektor-Dimensionen (x;y;z) aber zusammen, und plötzlich ist das Array gar nicht mehr so unterschiedlich zu einem (Vektor-)Raum.

Deswegen sollten wir den Bezug/die Abgrenzung zu den Vektor-Koordinaten lieber weglassen; man sieht's dann in den Beispielen 1 und 3.

--arilou (Diskussion) 10:28, 1. Apr. 2015 (CEST)

OK, ohne Frage war es das Ziel, Missverständnisse auszuräumen oder sie gar nicht erst aufkommen zu lassen. Und zugegeben, beim Beispiel kommt es gut raus. Die Frage ist: Was ist das Vorverständnis von 3-dimensional ? Vektor oder Vektorraum. In der Physik gibt's da keine Probleme, da macht's der Kontext. Aber beim Datentyp ? Und auf die Idee mit der Intervallgröße wäre ich nicht gekommen. (Das ist doch recht weit hergeholt?) --Nomen4Omen (Diskussion) 11:24, 1. Apr. 2015 (CEST)

Bzgl. "Vorverständnis" muss ich mich leider enthalten, da bin ich zu weit vom "Durchschnittsleser" weg. Ich konnte schon programmieren und dabei mit Arrays umgehen, bevor wir in der Schule Vektoren in Mathe hatten oder Englisch gelernt haben. Das dürfte für die meisten WP-Leser (wenn überhaupt dann) eher anders herum zutreffen.

Bei "Intervallgröße" hab' ich auch etwas -hm- geholpert. Kannst' auch auf "Indexbereich" ändern, oder dir fällt noch was besseres ein, das man gut von "Anzahl der Indizes" unterscheiden kann...

--arilou (Diskussion) 15:52, 1. Apr. 2015 (CEST)

'freie Plätze'

(Standardfeld, Beispiel 1)

Ich möchte andeuten, dass jetzt Platz für genau 3 Elemente ist; diese sind aber undefiniert/nicht initialisiert/'frei'.

Wenn jemand anders einen besseren Ausdruck weis - nur zu!

--arilou (Diskussion) 10:48, 1. Apr. 2015 (CEST)

OK, ist legitim. Vllt aber etwas oberlehrerhaft an dieser Stelle, da die Initialisierung nicht zum Thema gehört. --Nomen4Omen (Diskussion)

Hm, dass die Deklaration eines Arrays Speicher reserviert, gehört eigentlich schon zum Artikelthema.

Und dass dieser erst mal entweder un-initialisiert oder durch die Sprache mit einem Standardwert initialisiert wird, eigentlich auch, oder?

--arilou (Diskussion) 15:52, 1. Apr. 2015 (CEST)

Nochmal Details zu 'Dimension'

1.) Wenn/da es 'Dimensionen' auch bei assoziativen Feldern gibt, ist die Einordnung des Abschnitts 'Dimension' bei 'Standardfeeld nicht angebracht.
2.) Excel: Die Analogie zu Excel (als 2-dimensional) ist zumindest irreführend. Denn die Spalten in Excel entsprechen in der Regel verschiedenen Elementarfeldern (zB auch mit unterschiedlichen Formatierungen) einer 1-dimensionalen Tabelle - die nicht über einen zweiten Index angesprochen werden. Nur wenn multiple Spalteninhalte vorlägen (wie im Schachbeispiel), könnte man sowas als 2-dimensional bezeichnen.
3.) Anzahl Indizes = Anzahl Dimensionen: Das ist nicht korrekt, denn es geht tatsächlich um die Schachtelung von Arrays. Bspw kann ein Array (neben beliebigen Elementarfeldern der 1. Dimension) zwei und mehr weitere Arrays hintereinander enthalten, die aber jeweils immer nur eine 2. Dimension bilden. Dreidimensional wird es erst dann, wenn ein Array innerhalb des 2. Arrays definiert wird (wie beim Brennraum-Beispiel). Siehe u.a. Beispiele.
4.) Insofern macht es nur bedingt Sinn, den Sachverhalt Array in Beispielen räumlich darzustellen. Tatsächlich liegen die Daten auch bei Arrays hintereinander im Speicher (wie Datensätze), meist mit mehreren Elementarfeldern (A, B usw), ggf. mit multiplen Elementarfeldern oder multiplen Feldgruppen.

Beispiel mit allen Varianten:

|A|B|C1.C2.C3...|D1.E1.F1.D2.E2.F2...|G|H|I|J1.K11.K12.K13|J2.Knn...|J3.Knn.....|  <<Datenfelder (Namen) iZ mit Arrays
 111 22--------- 22222222------------ 11111 22 333-------- 2--3----- 2--3-------   << Schachtelungstiefe --- = Index=2ff
|A|B.....  (Daten zu Index1 + 1)                                                     1-n = Indexausprägung   
A+B = Elementarfelder zum Index1 (erste Dimension)
Cx = erstmals zweite Dimension (hier nur multiple Einzelfelder)
Dx-Fx = das zweite Mal zweite Dimension, hier Feldgruppe D-F als Feld
G-I = weitere Einzelfelder zum Index1
Jx = drittes Mal zweite Dimension, Feldgruppe mit neuem Unter-Array
Kx = dritte Dimension weil innerhalb J, = multiple Einzelfelder

Zu 1: Bitte, an dieser Stelle nicht so kompliziert. Einen Abschnitt Feld (Datentyp)#Assoziatives Feld gibt es schon.

Zu 3: Bitte, an dieser Stelle nicht so kompliziert. Lieber einen extra Abschnitt für quasi-beliebig Geschachteltes Assoziatives.

Zu 4: Bitte, an dieser Stelle nicht so kompliziert. Man sollte schon in Beispielen räumlich darstellen. Lieber darauf verzichten, wie die Sachen im Speicher liegen.

Zu 2: Bitte, an dieser Stelle nicht so kompliziert. Lieber einen Verweis auf Spreadsheets.

--Nomen4Omen (Diskussion) 14:44, 2. Apr. 2015 (CEST)

Ich glaube, du hast nicht verstanden, was ich oben geschrieben habe. ZB "Einen Abschnitt Feld (Datentyp)#Assoziatives Feld gibt es schon"; was hat das mit Punkt 1 zu tun? Auch bei AF'n gibt es Dimensionen, der Abschnitt 'Dimensionen' befindet sich aber in 'Standardfeld'. Zum Rest: Lies es bitte nochmal genau durch. --VÖRBY (Diskussion) 10:19, 3. Apr. 2015 (CEST)

Nun, für mein Dafürhalten ist 'Standardfeld' wichtig als simpelste Ausprägung. Dort muss was über Dimension gesagt werden.

Man kann ja bei jeder Ausprägung einen Unterabschnitt Dimension haben.

--Nomen4Omen (Diskussion) 10:45, 3. Apr. 2015 (CEST)

Weil 'Dimensionen' ein Grundsachverhalt von Array sind (egal welcher Art), gehören diese Aussagen nicht in nur eine dieser Arten, sondern in einen getrennten Abschnitt. Darauf zielte meine Frage Nr. 1.) und auch die anderen - in erster Linie an Benutzer:Arilou, der diese Texte einstellte. --VÖRBY (Diskussion) 11:58, 3. Apr. 2015 (CEST)

(Jetzt mal mein Senf:)

zu 1): Hm, richtig, auch ein assoziatives Array kann mehrdimensional sein. Eine Behandlung des Themas "Dimensionen" sollte daher (zumindest teilweise) in übergeordnetem Kontext stattfinden, da gebe ich dir Recht. (Aber besser 'nur bei Standard-Arrays erklärt' als 'gar nicht erwähnt'...)

zu 2): "Excel": Gemeint war: Ein Excel-Arbeitsblatt ist (blanko) erst mal eine 2D-Fläche aus Zellen. Dass man darin dann auch 0D- oder 1D-Daten verwenden kann (oder auch Pseudo-3D-Erweiterungen implementieren kann, z.B. Pivot-Tabellen, oder Verweise auf andere Tabellen derselben Mappe), ist richtig. Ein besseres Beispiel ist stets willkommen.
"Denn die Spalten in Excel entsprechen in der Regel verschiedenen Elementarfeldern (zB auch mit unterschiedlichen Formatierungen) einer 1-dimensionalen Tabelle - die nicht über einen zweiten Index angesprochen werden." ~ du meinst ein 1D-Array über einem Zusammengesetzten Datentyp. Dennoch ist zumindest die Darstellung in Excel 2D, und somit Excel selbst durchaus auch in solch einem Fall immernoch ein Beispiel für 2D. Hm; man könnte im Artikel statt einfach 'Excel' etwas präzisieren. (Aber ich habe auch nichts gegen ein besseres Beispiel.)

zu 3): *denk*

• "Anzahl Indizes = Anzahl Dimensionen: Das ist nicht korrekt" - für Standard-Arrays ist es so (und genau und nur so).

Nein - wenn im Standardfeld (1. Dimension) zwei Unter-Arrays hintereinander, nicht "ineinander" definiert werden, bleibt das 2-dimensional. Ergibt sich aus der Definition (siehe Beleg) von "mehrdimensional".--VÖRBY (Diskussion) 17:16, 7. Apr. 2015 (CEST)

Ich weis ja nicht, wo du deine Definition her hast, was ein "Standard-Array" sei... Im Artikel wird als Abgrenzung "Standard"-vs.-"Assoziativ" verwendet.

a) Ein Standard-Array kann mehrdimensional sein - und zwar "in sich", ohne dass es dazu weitere "geschachtelte" Arrays brauchen würde. Man kann die "tieferen Dimensionen" als "Unter-Arrays" betrachten, das entspricht aber bei vielen Programmiersprachen nicht der tatsächlichen Implementierung.

b) Dass ein 1D-Array als Elemente (evtl.) wiederum Arrays enthält, macht es nicht zwangsweise "mehrdimensional". In dynamisch typisierten Sprachen (insbesondere in denen, die überhaupt nur assoz.Arrays kennen) mag das sein, in statisch typisierenden Sprachen bleibt das äußere Array jedoch trotzdem "1-dimensional".

c) Speziell dein "Beleg" ist eine Programmiereinführung in C und erklärt so manches eher "anschaulich" denn formal korrekt (und außerdem sehr C-spezifisch, anstatt ein "allgemeiner Beleg" zu sein).

--arilou (Diskussion) 10:58, 9. Apr. 2015 (CEST)

• "Schachtelung von Arrays": Ein assoziatives (1D-)Array kann als Inhalt neben "primitiven Werten" auch wiederum Einträge enthalten, die n-dim. Arrays sind. Hm, wenn die entsprechende Sprache erlaubt, dass man auf das Feld dann
  myValue := array[ index1 ][ index2 ][ index3 ]
  zugreift, dann sieht zumindest der Zugriff genauso aus, als ob es von Anfang an ein "totales" 3D-Array gewesen sei. Allerdings kann der Zugriff schief gehen, wenn hinter [index1] eben kein 2D-Array (oder Array mit 1D-Array an Stelle index2) steht.
  So manche Skriptsprache (oder dynamisch typisierendes) lässt sowas bei assoziativen Arrays wohl zu.

Vielleicht ist es angebracht, sowohl übergeordnet auf "Dimension" einzugehen, als auch für 'Standard-Array' und 'assoz. Array'. Begrifflich: Bei Standard-Arrays redet allerdings niemand von "Schachtelung von Arrays", sondern die Dinger heißen dann einfach "mehrdimensional".

Habe 'Schachtelung' nur in der Disk, nicht im Text verwendet - sondern "Array im Array". Allerdings findet man auch in der Literatur den Terminus "nested". Der Punkt ist aber erledigt. --VÖRBY (Diskussion) 17:16, 7. Apr. 2015 (CEST)

--arilou (Diskussion) 10:00, 7. Apr. 2015 (CEST)

Ich habe 'Dimensionen' als eigenständigen Abschnitt umgestaltet, da er für Standard- als auch für assoziative Felder gleichermaßen relevant ist. Auch die anderen Punkte von 1.) bis 4.) habe ich zum Teil erledigt. Bitte nochmal kontrollieren. Auch habe ich die Reihenfolge anderer Texte dabei geändert. --VÖRBY (Diskussion) 09:57, 7. Apr. 2015 (CEST)

Werd's mir anschauen.

--arilou (Diskussion) 10:00, 7. Apr. 2015 (CEST)

Ich denke, dass es zum Begriff 'Dimensionen' kein Unterschied ist, ob sie bei Standard- oder assoz. Arrays auftreten. Der Unterschied zwischen beiden ist lediglich, dass anders adressiert wird (bei Std über einen vorbesetzten Index, bei Assoz. über einen festgelegten Schlüssel).--VÖRBY (Diskussion) 17:19, 7. Apr. 2015 (CEST)

Hm, schwierig. Insbesondere, wenn du dann auch noch statisch und dynamisch typisierte Sprachen mitrein mischst.

Bei einer statisch typisierenden Sprache muss man auch die Dimension(en) eines assoz. Arrays vorher festlegen - sonst bleibt es 1D, auch wenn man in ihm als Element ein (Unter-)Array ablegt.

--arilou (Diskussion) 10:58, 9. Apr. 2015 (CEST)

Hi, deine Aktualisierungen nehme ich mit Bauchgrummeln zur Kenntnis: Ich denke, wenn man hier von Array / Feld spricht, dann sollte man das möglichst sprachneutral tun. Du (nicht ich) mischst jetzt aber noch unterschiedliche Sprachtypen mit rein, und kannst natürlich trotzdem nicht vollständig sein. Kann sowas nicht bei 'Sprachunterschiede' behandelt werden? Denn das Ganze soll ja auch noch verstanden werden.

Die neue Gliederung gefällt mir immer noch nicht: Neben den beiden Grundformen 'Standardfeld' und 'assoz. Feld' (ja, das sehe ich auch so, im Text wird das aber wg der == Gliederungen nicht klar, wir sollten diese beiden mit === formatieren) erscheint jetzt plötzlich zusätzlich ein 'Element-Datentyp', dessen Beschreibung mir wirr erscheint: "Elemente eines einzelnen Datentyps" lässt doch alle Varianten zu, zB auch eine "Datenstruktur"; nur wäre es eben innerhalb des Felds nur ein Datentyp.

Die einzige Definition, die ich für 'mehrdimensional' fand, ist/war die belegte. Und die erscheint mir schlüssig. Du nennst in deinen Beispielen jetzt mehrfach '1D-Feld', das ist ein weißer Schimmel, denn ein Feld ist per Definition multipel, die Dimensionen ergeben sich aus der Schachtelung (sorry, steht nur hier, als Ersatz für 'Array in Array'), und n Arrray hintereinander (nicht ineinander) bewirken somit keine zusätzliche Dimension.

2D wie Excel: Du willst einfach bei deiner Ansicht "2D = wie Excel" bleiben, dabei ist das i.Z. mit 'Array' (in der Regel) ganz normal 1D mit verschiedenen Einzelfeldern, die bei Excel lediglich keinen Namen haben, sondern über die Spalte angesprochen werden. Das ist aber nicht 2D i.S. von 'Feld'!

Schau dir bitte diese Notizen und deinen Text nochmal an. Ich möchte jetzt in dieser Angelegenheit keine weitere Energie mehr investieren, mögen die Ergebnisse andere beurteilen. --VÖRBY (Diskussion) 19:40, 9. Apr. 2015 (CEST)

• [Ich würde ein Problemfeld "unterschiedliche Sprachtypen" noch hineinmischen]
  Aus meiner Sicht springst du in deiner Argumentation munter zwischen verschiedenen Sprachtypen hin und her (mit starker Betonung der Array-Eingeschaften, wie sie bei dynamisch typisierenden Sprachen auftreten - mitunter habe ich den Eindruck, dass du evtl. andere kaum kennst?), ohne das (dem Leser) klar zu machen. Mal als 'analoges' Beispiel: Wenn ich jemandem die "Lade- und Transportfähigkeit eines Automobils" erklären möchte, sollte ich nicht von 'Gepäckbox' über 'Kofferraum' zur 'hydraulischen Ladeklappe' argumentieren, ohne dem Leser erst mal mitzuteilen, dass das etwas damit zu tun hat, ob ich ein Motorrad, ein Auto oder einen LKW vor mir habe. Du meinst "bring' nicht den Fahrzeugtyp als weiteres Problemfeld in den Artikel"...
• [Gliederung] ~ ist wohl noch nicht optimal, ja.
• [Beleg "C-Einführung"] ~ Es gibt bestimmt deutlich bessere Belege als eine "Einführung für Anfänger in C", in der stark vereinfachte Aussagen (beinahe schon falsche) v.a. zum Anschaulich-Machen stehen. Im Beleg ging es nur um die Definition von 'mehrdimensional'. VÖRBY
• Was du mit "n Array hintereinander" meinst, verstehe ich nicht. Wenn ich in ein 1D-Feld (als Elemente) n (1D-)Felder hintereinander ablege, ist das Gesamtkonstrukt durchaus auf 2D gewachsen? Ja, aber unabhängig von der Anzahl der zusätzlichen Felder bleibt es 2D. VÖRBY
• [" '1D-Feld', das ist ein weißer Schimmel,"] ??? Ein Feld kann mehrdimensional sein: 1D-Feld, 2D-Feld, 3D-Feld, n-dim.-Feld. Das ist mitnichten ein "weißer Schimmel". In vielen Sprachen gibt es keine "Schachtelung", sondern ein (Standard-)Feld ist in-sich mehrdimensional. Die 'Betrachtungweise' "Array in Array" ist dort nur eine Veranschaulichung, die jedoch in der Sprache so nicht implementiert ist. Trotzdem bleibt mehrdimensional 'Array in Array'; das gilt unabhängig von der Sprachunterstützung; schließlich ist ein Array zB auch in Assembler ein Array, obwohl es dort idR überhaupt nicht unterstützt wird. VÖRBY

Die Erklärung/Sichtweise "Array in Array" ist eine mögliche Sichtweise; sie unterstellt, dass ein Array "in-sich" immer nur 1-dimensional sei. Es gibt aber auch die Sichtweise, dass ein Array "in-sich" mehrdimensional sein kann - und dann kann man natürlich nicht mehr mit der "Array-in-Array"-Erklärungsweise kommen - denn dann stimmt diese "ein Array ist immer 1-dimensional"-Annahme nicht mehr. Man kann eben nicht während man mit Sichtweise_2 erklärt auf Sichtweise_1 "umspringen". // arilou

Sind die "in-sich-mehrdimensionalen" nicht nur Varianten, bei denen die äußeren Arrays einfach nur keine eigenen Daten haben, sondern lediglich weitere Arrays (zB 8,8,8 integer)? Wenn nein, wenn dies also als eigenständige, alternative Variante von Arrays gilt, sollten die beiden Möglichkeiten im Artikel und in jedem Fall bei den Beispielen deutlich(er) gezeigt werden (auch bei 2D und 3D die 'andere Form'). // VÖRBY

Ich bin mal so frei, und mach' weiter unten dazu einen neuen Disku-Punkt auf, da das hier langsam "eng" wird. // arilou

• [Excel] Herrje, hast du noch nie Excel einfach mal 'blanko' geöffnet, ohne Daten darin? Ein 'leeres' Arbeitsblatt ist in-sich 2D, mit den beiden Indizes [Zeile] und [Spalte]. Was/ob man darin dann für Daten eingibt, ist wurscht - das Arbeitsblatt selbst bleibt (intern im Programm 'Excel') ein 2D-Array aus 'Zellen'. Ja, das Arbeitblatt ist aus der Sicht von Excel 2D, ein Benutzer sieht es aber idR als 1D und die Spalten als Elementarfelder, nicht als 2. Dimension. Schlechtes Beispiel, zumal quasi definierend. VÖRBY

Hm, du unterstellst aber, dass "ein Benutzer" in Excel im Allgemeinen 1D-Daten aus Verbund-Objekten betrachtet. Andere Benutzer haben vielleicht häufig 2D-Daten zum Anschauen-in-Excel. Deshalb steht im Artikel ja mittlerweile "z.B. ein (leeres) Excel-Arbeitsblatt, adressiert über [Zeile] und [Spalte]", womit der Leser dann ja wohl versteht, dass er sich als Beispiel ein leeres Excel-Blatt ansehen soll... // --arilou (Diskussion) 13:14, 13. Apr. 2015 (CEST)

--arilou (Diskussion) 10:12, 10. Apr. 2015 (CEST)

"in-sich-mehrdimensional" vs. "array-in-array"

Fortsetzung einer Diskussion aus Abschnitt "Nochmal Details zu 'Dimension'"

Anhand zweier Beispiele; 1. Java (für Array-in-Array), 2. C (für in-sich-mehrdim.)

Java ist ein Beispiel für "Array-in-Array":

private static void myMethod() {
  int[][]   ar_zahl ;
  ar_zahl = new int[3];      // aeussere Dimension = 3
  ar_zahl[0] = new int[77] ; // Unter-Array an Pos=0 hat die Elemente [0..76]
  ar_zahl[1] = null ;        // tja, hier is 'leer'
  ar_zahl[2] = new int[4] ;  // und hier ein Unter-Array mit 4 Elementen

  // ...mit irgendwelchen Zahlen befuellen... z.B.:
  ar_zahl[2][2] = -7 ;
  ar_zahl[0][71] = 20 ;
  // ...jetzt sei alles befuellt...

  for( int pos=0 ; pos < 3 ; pos++ ) {
    show_intList( ar_zahl[ pos ] );
  }

  // Unter-Array kann nachtraeglich problemlos geaendert werden:
  ar_zahl[ 0 ] = new int[ 999 ] ;
  // genauso geht's auch "rechteckig":
  ar_zahl = new int[ 5 ][ 3 ];
  ar_zahl[4] = new int[ 99 ]; // jetzt haben die Zeilen 0..3 jeweils ein Unter-Array
  // mit Elementen 0..2, die Zeile 4 hat ein Unter-Array mit Elementen 0..98
}

private static void show_intList( int[] ar_ints ) {
  if( ar_ints != null )
    for( int i = 0 ; i < ar_ints.length ; i++ )
      System.out.print( " " + Integer.toString( ar_int[ i ] ) );
    // end for
  // end if
}

Anders z.B. in C:

void showList( char list[7] ) {
  int j ;
  for( j=0 ; j<7 ; j++ ) {
    printf( " %c" , list[j] );
  } // end for
}
void showList2( char[] list ) {
  int j , maxJ ;
  maxJ = ?        // tja, woher?
  for( j=0 ; j<maxJ ; j++ ) {
    printf( " %c" , list[j] );
  } // end for
}
void showList3( int count, char* list ) {
  int j ;
  for( j=0 ; j<count ; j++ ) {
    printf( " %c" , list[j] );
  } // end for
}
int main() {
  char myChars[ 3 ][ 7 ];
  int k , j ;

  for( k = 0 ; k < 3 ; k++ ) {
    for( j = 0 ; j < 7 ; j++ ) {
      myChars[k][j] = (char) ('a' + (k*7) + j) ;
    }
  }

  showList( myChars[1] );    // kein Problem
  showList2( myChars[1] );   // nicht moeglich
  showList3( 7 , myChars[1] );    // workaround ueber pointer
  // gar nicht moeglich:
  myChars[k] = (char[]) malloc( sizeof(char) * 99 );

  return 0 ;
}

Hier funktioniert der 'showList'-Aufruf, man kann (so etwas wie) Unter-Arrays also "übergeben". Aber die Array-in-Array -Erklärung unterstellt, dass ein 'inneres Array' ein ganz normales Array sei; dann müsste es dem Compiler/laufenden Programm möglich sein, den jew. Indexbereich eines "Unter-Arrays" zu wissen. In Java geht das, in C nicht (mit Array-Mitteln). Erst ein Workaround über Pointer macht es showList3 moeglich. Ein "Umsetzen" eines "Unter-Arrays" durch ein anderes (z.B. mit anderer Elementanzahl) ist gar nicht möglich.

Was in Java außerdem geht:

void method1() {
  Object[]  myObjList ;
  Double    zahl1 ;

  myObjList = new Object[ 2 ];
  myObjList[ 0 ] = new Float( 1.7 );
  myObjList[ 1 ] = new Double[ 100 ];
  // D.h. myObjList[1] enthält jetzt ein 1D-Array aus Objekten der Klasse 'Double'.
  // Trotzdem ist es nicht 2-dimensional - folgendes geht naemlich _nicht_:
  zahl1 = myObjList[ 1 ][ 17 ];
  // sondern man muss erst das 'Ding' in myObjList[1] auslesen, Java mitteilen (typecast) "das ist ein array of Double",
  // und dann erst darf man darauf indiziert zugreifen:
  zahl1 = ((Double[]) (myObjList[ 1 ])) [ 17 ];
}

--arilou (Diskussion) 14:01, 15. Apr. 2015 (CEST)

Hi, hast dir ne Menge Arbeit gemacht. Aber lass mich mal rekapitulieren: Wir wollten anfangs lediglich ergänzen, was mit Dimension gemeint ist. Anhand deiner Beispiele haben wir festgestellt, dass es möglicherweise zwei Varianten zur Dimensionierung gibt: a) wo das Array lediglich 1 (elem.) Datenfeld enthält, das in der innersten "Schachtelung" (bei n-dimensional) liegt ("in-sich-n-dimensional", Bsp 2 und 3, für Vektor- oder Matrizendefinitionen?) und b) wo ein Array einen Verbund (= Datengruppe) enthält - der im Falle mehrdimensional - wiederum ein (nD-) Array enthält usw. ("Array-in-Array")
Ich denke, wir sollten und können bei diesen relativ einfachen Erklärungen auf Details aus bestimmten Programmiersprachen verzichten, oder evtl. vorhandene, wichtige Unterschiede im Abschnitt '~Sprachspezifisches' unterbringen.
Auf die Programmierbeispiele oben will ich kaum eingehen, nur soviel:

• ganz klar ist das letzte davon (myObjList) ein 1D-Array, wieso sollte es 2D sein?
• Zu "Ein "Umsetzen" eines "Unter-Arrays" durch ein anderes (z.B. mit anderer Elementanzahl) ist gar nicht möglich." Das verstehe ich wiederum nicht: Was heißt 'Umsetzen'? Warum sollte das "Unter-Array" (= inneres?) nicht eine andere Elementzahl aufweisen können als das äußere? Das ist doch 'stinknormal': 1. Dim = Kunde (1000), inkl einige Attribute, +weiteres Array (= 2. Dim = Telefonnummer (3)). Nachtrag 16.4.: Du meinst wahrscheinlich "Umsetzen = Ändern der Elementzahl eines (Unter)arrays". Das hat aber nichts mit unserer Disk zu tun, sondern nur damit, dass Arrays in bestimmten Sprachen anders unterstützt werden (können), hier durch änderbare Elementanzahl. // VÖRBY
• Ein Unterscheiden von Array(Datentyp) und Array(Datenstruktur) halte ich für nicht notwendig - klar kann ein Array-Datentyp eine Struktur haben. Dazu ist ja das Erklären von 'Dimension' ein Teilaspekt.

Mit unseren 'Ausflügen' sind wir also nach meiner Meinung 'ganz schön im Wald'. Mein Vorschlag also: Die Beispiele (auf die zwei Varianten) aktualisieren und ggf. den einen oder anderen Textteil (zB auch 'Excel') anpassen. Sollte minimalen Aufwand bedeuten und korrekt sein. Gruß von --VÖRBY (Diskussion) 17:57, 15. Apr. 2015 (CEST)

Habe nochmal mit "Array" und "mehrdimensional" gesucht und festgestellt:

• In den gefundenen Beiträgen werden zu 'mehrdimensional' überwiegend Konstrukte wie Bsp 2 und 3 vorgestellt, bei denen also (wie in [6] auch explizit beschrieben) "nur die letzte Dimension dann die Elemente beinhaltet." Praktisch also eine räumliche Darstellung (2D=Fläche, 3D=Würfel), bei der jede 'Einzelinformation' ALLEN Dimensionen (Breite, Höhe, Tiefe) gleichermaßen zuzurechnen ist; Zugriff immer über alle Indices.
• Die Form "Array-in-Array" wird in einigen Beiträgen zusätzlich erwähnt - und wird dort auch "verzweigtes Array" genannt. Bsp. siehe [7] und [8].
• Vor allem die "verzweigten" Arrays können Informationen in Form einer Verbund-/Recordstruktur enthalten und verwalten, anzusprechen mit 'AttrName1 (i)' für Einzelfelder im äußeren und mit 'AttrName2 (i,j) im inneren Array. Diese Form ist zumindest im kommerziellen Bereich (im Ggs zu Mathematik, Geometrie, Technik) ein Normalfall. Jede gespeicherte Einzelinformation "gehört" in dieser Version nur zu GENAU EINER Dimension (bzw. einem ihrer Objekte), entweder dem 1D-Objekt, Hauptobjekt (1 Index beim Zugriff erforderlich) ODER zur 2. Dimension (bzw. einem ihrer Objekte), also zu genau einem untergeordneten Objekt, 2 Indices erforderlich - usw. 'Mehrdimensional' bezieht sich hier auf die Gesamtheit aller im Array (hierarchisch, baumartig = verzweigt) gespeicherten Informationen, nicht auf jedes einzelne Element.

Wir sollten diese beiden Varianten deshalb auch im Artikel und bei den Beispielen unterscheiden und erläutern. Ob die beiden Varianten kombiniert auftreten können, wäre ein weiteres Detail, das sicher 'sprachspezifisch' ist. --VÖRBY (Diskussion) 10:06, 17. Apr. 2015 (CEST)

Arrays not analogous to vectors or matrices

Das fand ich noch und will es noch posten: Siehe diesen Diskussionsbeitrag in der Englischen Wikipedia.

Die bisher HIER verwendeten Beispiele zeigen (bis auf Bsp 1D(2) nur Fälle, in denen mit einem Array nur 1 elementares Datenfeld in der inneren Dimension definiert werden. Das ist aber nur die einfachste Form einer Array-Verwendung. Die Grundform lt. Lemma lautet "innerhalb des Arrays können viele (besser: mehrere) gleichartig strukturierte Daten" verarbeitet werden. Das schließt vor Allem auch Datengruppen ein, und so werden Arrays wohl auch überwiegend benutzt, egal ob ein- oder mehrdimensional. Die BEISPIELE und auch die erläuternden TEXTE gehen aber davon aus, dass lediglich im innersten Array ein (1) elementares Datenfeld existiert.--VÖRBY (Diskussion) 13:15, 13. Apr. 2015 (CEST)

Ich bin nicht sicher, ob ich das komplett verstanden habe.

Deine Probleme mit 'elementares Datenfeld' versteh' ich nicht. Es ist für ein Array in den meisten Sprachen komplett egal, ob der Datentyp, über dem es definiert ist, ein 'elementarer' ist, oder ein Verbund. Im Abschnitt "Element-Datentyp" darf der Datentyp der Array-Elemente durchaus auch ein Verbund-Typ sein, wie im Abschnitt 1D(2) ('Produkt').

Allenfalls in dyn. typisierenden Sprachen, die überhaupt nur assoz. Arrays anbieten, gibt es mitunter keinen speziellen "Verbund-Typ", sondern das wird dann auch per assoz. Array abgedeckt. Dort wäre ein "Array über Verbunde" dann (automatisch) 2D.

"Datengruppen" - neuer Begriff, gemeinte Bedeutung mir erst mal nicht klar.

"und so werden Arrays wohl auch überwiegend benutzt, egal ob ein- oder mehrdimensional." - kommt drauf an, ob man sich in einer dyn. typ. Sprache bewegt (die nur assoz. Arrays bietet), oder in statisch typ.
In Java kommt praktisch nie vor, dass man ein Array bräuchte, das (z.B. mittels Polymorphie) beliebige Inhalte aufnehmen kann. In Gegenteil: Wenn sowas (ähnliches)(selten) mal vorkommt, ist man stets bemüht, den Typ so stark als möglich einzuschränken.

"dass lediglich im innersten Array ein (1) [elementares] Datenfeld existiert"
Ich ignoriere mal 'elementar' (da auch 'Verbund' erlaubt wäre). In statisch typ. Sprachen ist es üblicherweise so, dass erst mit einem kompletten Indizes-Satz ein Datenfeld des Array- Basis-Datentyps adressiert ist.
Und nur so ist ja auch der ganze Artikel-Abschnitt mit der (mehrdimensionalen) Adressrechnung stimmig ("Adressierung eines Feldes")

• jedes Array-Element muss exakt gleichviel Ram belegen;
• das Array muss rechteckig sein;
• das Gesamtarray hat genau so viele Einträge wie die Ausmultiplizierung der Indexbereiche.

--arilou (Diskussion) 14:26, 15. Apr. 2015 (CEST)

Nachtrag:

Die engl. WP unterscheidet (2 Artikel!) zwischen "en:array data structure" und "en:array data type". In "en:array data structure" werden ausschließlich die in-sich-mehrdimensionalen, nur-im-tiefsten-Array-Elemente-besitzenden Array beschrieben. "Assoziative Arrays" (oder mit 'beliebigen Inhalten') haben eigene Artikel Hashmap, Verkettete Liste, ...

Wär' vielleicht auch eine Idee für die de-WP, nicht alle Formen in nur 1 Artikel Feld (Datentyp) abhandeln zu wollen.

--arilou (Diskussion) 14:39, 15. Apr. 2015 (CEST)

Neuer Entwurf

Analog zu den letzten Disk-Beiträgen, z.T. nicht beantwortet, verfasse ich nachfolgend den Abschnitt "Dimensionen" neu. Kleinere Korrekturen bitte darin selbst vornehmen, größere bitte anschließend diskutieren.

(== Dimensionen ==)

In den meisten Programmiersprachen kann ein Feld und damit die darin gespeicherten Informationen mehrdimensional sein. Zum Begriff der Dimension können die nachfolgenden Varianten unterschieden werden. In den Beispielen wird ein symbolischer Beispielcode verwendet (der Startindex sei 1).

(=== Eindimensionale Felder ===)

Feldelemente werden wie in einer Liste als elementares Datenfeld oder als Verbund mit mehreren Einzelfeldern geführt.

Beispiele

1.   eindimensional (wie eine ‚Liste‘)

 Vektor := array(3) of float  // Deklaration einer 1-dimensionalen Liste namens „Vektor“ mit 3 ‚freien Plätzen‘
 Vektor := (0.5, 1.7, -0.2)   // der Punkt (x=0.5 ; y=1.7 ; z=-0.2) im ℝ³

Vektor[2] liefert so die y-Komponente mit dem Wert 1.7.

2.  eindimensional (mit Verbund-Datentyp):

 Produkt := array(100) of structure{       
    ProdNr := Text[6] ,                    // Text mit max. 6 Stellen 
    Einkaufspreis := FixPunktZahl[4;2]     // Kommazahl mit 4 Stellen vor, 2 Stellen nach dem Komma
    Verkaufspreis := FixPunktZahl[4;2]     // dito
    Lagerbestand  := Integer[6]            // Ganzzahl mit 6 Stellen
 } // end structure

Produkt[Index].ProdNr, Produkt[Index].Einkaufspreis liefern die genannten Werte für das Produkt, auf das der Index zeigt.

(=== Mehrdimensional / direkt im Feld ===)

Mit dieser Variante lassen sich Informationen räumlich darstellen/speichern, d. h. als Elemente einer 2D-Fläche oder eines 3D-Würfels. Dabei „beinhaltet nur die letzte Dimension die Elemente“, jede Einzelinformation ist somit allen Dimensionen (z. B. Breite, Höhe, Tiefe) gleichermaßen zuzurechnen. Der Zugriff erfolgt unter Angabe aller Indices.

Beispiele

1.   zweidimensional (wie eine Matrix oder eine Tabelle):

In einer Matrix werden die waagerechten Einträge (Felder, Zellen) als Zeilen, die Senkrechten als Spalten bezeichnet. Ein einzelnes Element ist also durch Nennung von Zeile und Spalte eindeutig bezeichnet (adressiert). Üblich ist die Adressierung über ein Tupel (0,0) oder A1 für Spalte A, Zeile 1.

 Schachfeld := array(8,8) of String

array deklariert die 8 mal 8 Felder von Schachfeld, of den Typ des Eintrags;

hier: (Zeile,Spalte)

 Schachfeld := (("Turm_W" ,"Springer_W","Läufer_W", … ,"Turm_W"),
                ("Bauer_W","Bauer_W"   ,"Bauer_W" , … ,"Bauer_W"),
                (""       ,""          ,""        , … ,""),
                (""       ,""          ,""        , … ,""),
                (""       ,""          ,""        , … ,""),
                (""       ,""          ,""        , … ,""),
                ("Bauer_S","Bauer_S"   ,"Bauer_S" , … ,"Bauer_S"),
                ("Turm_S" ,"Springer_S","Läufer_S", … ,"Turm_S"))

Die vorstehende Zuweisung legt die Start-Anordnung der Figuren fest, W=weiß, S=schwarz.

Die Beispielanweisungen Schachfeld[3,3]^*1 := Schachfeld[1,2]^*2 und Schachfeld[1,2]^*2 := "" liefern den Eröffnungszug „Weißer Springer auf C3“.

^{*1: oder [NachZeile,NachSpalte] *2: oder [VonZeile,VonSpalte], jeweils vorher mit Werten belegt}

2.   mehrdimensional (hier mit 4 Dimensionen):

Für einen Brennraum (x;y;z) (z. B. eines Motors),

wobei x, y und z in Millimeter jeweils von 1 bis 50 angegeben seien,

sei an jeder Stelle, und über den Zeitraum einer Sekunde für jede Millisekunde, eine Temperaturangabe gespeichert:

 temperatur := array(50,50,50,1000) of float

→ 4-dimensionales Array (x,y,z,zeit)

Wie heiß war es an der Stelle (x=7;y=12;z=48) zum Zeitpunkt t=617 ms?

 = temperatur( 7 , 12 , 48 , 617 )

(=== Mehrdimensional / Feld enthält weiteres Feld ===)

Hierbei enthält ein Feld als Element - neben ggf. anderen Datenfeldern - wiederum ein Feld - und dies ggf. mehrstufig. Diese Variante wird auch „verzweigtes Array“ genannt. Einzelinformationen gehören dabei jeweils zu genau einem Feld, d. h. zu genau einer Indexausprägung dieses Felds. ////Auch hier kann eine 'Einzelinformation' selbst ein Verbundobjekt sein...//// Dementsprechend erfolgt der Zugriff auf Einzelinformationen im äußeren Feld zum Beispiel mit 'ArrayName(i)' und auf Einzelinfos im inneren Feld mit 'ArrayName(i,j)' usw. „Mehrdimensional“ bezieht sich hier auf die Gesamtheit aller im Feld hierarchisch (= baumartig, ‚verzweigt‘) gespeicherten Informationen, nicht auf jedes einzelne Element. Die Anzahl der Dimensionen ergibt sich aus der „Schachtelungstiefe“ des innersten Arrays.

Beispiel

 Lager      := array(10)                   // Es gibt 10 Lager = Feld der 1. Dimension
  LagerNr   := Text(4)                     //  darin: jedes wird mit seiner Nummer geführt
  Produkt   := array(100)                  //  ... und in jedem Lager (max.) 100 Produkte, = Feld der 2. Dimension
   ProdNr   := Text[6]                     // Je Produkt dessen Nummer mit max. 6 Stellen 
   EK_Preis := FixPunktZahl[4;2]           //  ... und dessen Einkaufspreis

'LagerNr (Index1), Produkt.ProdNr[Index1,Index2], Produkt.Einkaufspreis[Index1,Index2] ...' liefert die genannten Werte für das jeweilige Produkt aus dem jeweiligen Lager gemäß dem Inhalt der Indices.

LagerNr (Index1) liefert die Lagernummer, jeweils gemäß Index1

Für den Zugriff sind nur die Indices für die Dimension(en) erforderlich, zu denen die Informationen gehören.

Neues Beispiel statt Lager/Produkt?

Das Beispiel zu 'Mehrdimensional / Feld enthält weiteres Feld' gefällt mir gar nicht.

Ich bau' mal etwas (imo) besseres:

Beispiel

 // Deklarationen
 Regalboden := array(10) ;                 // Ein Regal hat 10 'Boeden' (Speicherplätze), auf die man etwas
                                           // (Typ: (irgendein) Objekt) legen kann.
 Werkzeugbox := array(50) of Werkzeug ;    // eine Werkzeugbox mit Platz fuer 50 Objekte des Typs 'Werkzeug'
 BitKaestchen := array(20) of Bit ;        // Kaestchen fuer 20 Objekte des Typs 'Bit'
 // Initialisierung
 Regalboden(1) = einMonitor ;              // Auf Regalboden 1 wird ein Einzelobjekt vom Typ 'Monitor' abgelegt.
 Regalboden(2) = Werkzeugbox ;             // hier wird 'Regalboden' jetzt 2-dimensional
 Werkzeugbox(1) = einSchraubendreher ;     // an Pos.1 der Werkzeugbox wird ein Schraubendreher abgelegt
 Regalboden(2,2) = einHammer ;             // an Pos.2 der Werkzeugbox wird ein Hammer abgelegt
 Regalboden(2,3) = BitKaestchen ;          // an Pos.3 der Werkzeugbox wird ein Kaestchen abgelegt fuer 20 Bits
                                           // -> hier ist 'Regalboden' nun 3-dimensional
 // Zugriffe
 myBit = Regalboden(2,3,17) ;              // liefert wie erwartet ein Bit.
 myObject = Regalboden(1,1)                // fuehrt zu einer Fehlermeldung, weil das Feld 'Regalboden'
 // auf Boden 1 keine weitere Dimension besitzt - dort liegt einMonitor (Einzelobjekt).

eher so. --arilou (Diskussion) 13:40, 22. Apr. 2015 (CEST)

Hallo, gut finde ich, dass wir jetzt offensichtlich einer Meinung sind, was die beiden m-dimensionalen Varianten angeht. Aber es ist wohl Geschmacksache, welches Beispiel einem "besser gefällt". Von der Verständlichkeit her kann ich da keinen großen Unterschied erkennen. Aber:

• Dein Beispiel wird gleich dreidimensional, ist also komplizierter (zu verstehen).

Na wenn schon, dann richtig ;-) // arilou

• Man erkennt nicht, dass hier ein Array innerhalb (der Datenfelder!) eines übergeordneten Arrays angelegt wird - was der eigentliche Unterschied zwischen 'in-sich-mehrdimensional' und 'Array in array' ist. Die Definitionen sehen (für einen Laien) so ähnlich aus wie bei Brennraum.

Hm. Man könnte die 3 Zeilen

BitKaestchen := array(20) of Bit ;        // Kaestchen fuer 20 'Bit'-Werkzeuge
Regalboden(2,3) = BitKaestchen ;          // an Pos.3 der Werkzeugbox wird ein Kaestchen abgelegt fuer 20 Bits
                                          // -> hier ist 'Regalboden' nun 3-dimensional

ersetzen durch

Regalboden(2,3) := array(20) of Bit ;     // an Pos.3 der Werkzeugbox wird ein 'Kaestchen' fuer 20 'Bit'-Werkzeuge angelegt
                                          // -> hier ist 'Regalboden' nun 3-dimensional

So wäre das 'Bit-Kästchen' nun "im Array 'Regalboden' angelegt" - technisch macht das keinen Unterschied (außer dass man für das Kaestchen keinen Alias mehr hat). // arilou

Woran erkennt der Leser, dass die 3 Arrays eigentlich nur die Bezeichnungen für LG, WB und BK sind, nicht die Objekte selbst? Wie würde zB eine Deklaration für die Dim 2 und 3 aussehen, bei der zusätzlich zur Bezeichnung die Datenfelder 'angelegt am (Datum)' und 'angelegt durch (Name)' enthalten wären?

• Es wurde festgelegt, dass ein "symbolischer Beispielcode" verwendet wird; dieser sollte für jeden einfach verständlich sein. Z.B. wird auch nicht klar, was 'of Werkzeug' und of 'Bit' bedeuten soll. Bitte einfach bleiben!

Hab' die Kommentare etwas erweitert, dass dies Typ-Angaben für Objekte sind. // arilou

• Das Beispiel lässt nicht erkennen, wo die Deklaration endet und wo die Befehle beginnen.

Habe Kommentare zur Abgrenzung eingefügt. // arilou

• "hier wird 'Regalboden' jetzt 2-dimensional": Das sehe ich nicht so, die 2. Dim. ist bereits in der Deklaration festgelegt, die Zuweisung bringt lediglich einen Inhalt - zumindest als Normalfall und in den meisten Sprachen.

In der Deklaration von 'Regalboden' ist selbiger erstmal nur 1D (":= array(10)"); die Mehrdimensionalität kommt erst dadurch, dass darin ein Array-im-Array angelegt/gespeichert wird. Nur so ist es ja möglich, dass verschiedene Elemente von Regalboden "verschieden tief" sind, was das Beispiel ja gerade zeigen will. // arilou

Warum greift man auf Dim 2 (Regalboden(2,2)) mit dem Namen der 1. Dimension zu? Wie sähe das aus, wenn man nur auf ein Detailfeld (zB Bezeichnung & 'angelegt am') zugreifen möchte? Alternativen verwirren möglicherweise

Ich bin also (in dieser Form!) nicht für ein Ersetzen des Beispiels!

Es ist bestimmt noch nicht perfekt, aber dein Beispiel verwendet Einrückung als syntaktisches Element, und das ist eine Scheußlichkeit aus Lochkartenzeiten - da muss der Leser begreifen, dass die Einrückung bedeuten soll, dass eine Definitionszeile "Unter-Array" der vorigen Zeile sein soll. Ich kenne außer Python keine moderne Sprache, die dieses syntaktische Vorgehensweise noch praktiziert.

Dein Revert-Revert: wir wollen 'symbolischen Beispielcode' verwenden. Gem. vieler Quellen werden Daten in einem Array immer mit 'Datenname' plus Zusatz/Klammerausdruck für Index (bzw. Indices) notiert, nicht der Index in jeder einzelnen Datenstufe. Abgesehen davon, dass man im Quellcode normalerweise nur das innerste Datenfeld notiert, der Compiler kennt die übergeordnete Struktur und kann somit eindeutig adressieren. Aber das sind Details, du sollst von mir aus Recht behalten.

Also diese Zugriffsweise Produkt.ProdNr[Index1,Index2] ~ pffff; sobald es ein zweites Array gibt, das ebenfalls als Attribut 'Produkt' mit Unterattribut 'ProdNr' besitzt, will ich mal sehen, woher "der Compiler [dann] weis", welches Array er verwenden soll. Auch solchen Murks macht keine halbwegs moderne Sprache; in Pseudocode mag das mancher Autor noch als akzeptabel empfinden, da der Leser ausreichend Kontextwissen mitbringt, aber didaktisch ist es eine Scheußlichkeit, den WP-Leser an solchen Murks-Pseudocode zu gewöhnen. // --arilou (Diskussion) 11:58, 23. Apr. 2015 (CEST)

--VÖRBY (Diskussion) 17:00, 22. Apr. 2015 (CEST)

Das Beispiel ist immer noch (für Laien) hochgradig unverständlich, oder man setzt voraus, dass jemand eine bestimmte Programmiersprache und deren Syntax kennt. Das ist aber nicht der Sinn in einer Enzyklopädie:

• Da kommt auf einmal eine Typ-Angabe daher; von der ist im ganzen Array-Lemma nicht die Rede
• Was ist hier im Zusammenhang und als Unterbegriff von Werkzeug ein 'Bit'?
• Warum heißt die 3. Dimension 'Bitkästchen' - wenn in der 2. Dim. dinge wie Hammer vorkommen?
• Warum wird die 1. Dimension mit zwei Indizes (Regalboden (2,2)) angesprochen? Weiter unten wird das als Fehler bezeichnet.
• Warum wird der Hammer nicht in 'Werkzeugbox (2,2) abgelegt), sondern in 'Regalboden (2,2)? Bestimmte Programmierssprache möglich, hier aber verwirrend?
• Dass 'Regalboden (2)' durch Anweisungen erst eine Unterdimension bekommt, diese Unterdimensionen also dynamisch sind, versteht ein normaler Beispielbetrachter nicht. Sowas ist auch nirgends beschrieben - außer bei 'Sprachspezifisches' kurz erwähnt.
• Warum wird die 3. Dimension nicht mit 3 Indices angesprochen - entsprechend den "normalen Angaben" zu 'mehrdimensional'? Oder fehlt eine Beispielanweisung?

Fazit: Hier wird die Syntax einer ganz bestimmten Sprache verwendet, und diese sogar mit bisher nicht beschriebenen Aspekten. Das Beispiel ist in dieser Form nach wie vor ungeeignet. Da scheint mir doch die Einrückungs-Syntax das kleinere Übel zu sein - obwohl das im Lager-Beispiel gar nicht der Fall ist, sondern die Reihenfolge die Struktur bestimmt (erst 1D-Array, darunter = darin ein Elementfeld und dann wieder ein = das 2D-Array usw. Fürs Beispiel genügt das und ist eindeutig). Die Einrückung dient lediglich der besseren Lesbarkeit. Was soll an diesem Beispiel eigentlich "gar nicht gefallen"? Siehe auch die geänderten Kommentare.--VÖRBY (Diskussion) 14:22, 23. Apr. 2015 (CEST)

Vielleicht können wir dieses Beispiel als Bsp2 einstellen - um zu zeigen, welche Besonderheiten "in manchen Programmiersprachen" möglich sind. Dann sollte auf diese explizit hingewiesen werden. Bsp1 wäre und bliebe dann ein 'ganz normaler' 2D-Fall. --VÖRBY (Diskussion) 15:52, 23. Apr. 2015 (CEST)

Einige deiner Kritikpunkte kann ich verstehen und wäre auch bereit, sie zu überarbeiten - z.B. dass ich 'Werkzeug' und 'Bit' einführe, das ist ein wenig OOP; und geht ggf. auch ohne.

Manch andere deiner Kritiken/Beispiele sind imo so Murks, dass ich jetzt eine WP:3M anregen muss, da du den (imo) Murks immer wieder in den Artikel zurück-revertest oder -editierst. Natürlich werde ich mich dabei ebenfalls der dann entstehenden (Mehrheits-)Meinung beugen, so sich dies deutlich abweichend von meinen Ansichten ergeben sollte.

--arilou (Diskussion) 13:28, 24. Apr. 2015 (CEST)

Ich dachte, wir seien grundsätzlich mit der Diskussion "durch". Anscheinend nagen bei dir aber immer noch so manche Zweifel - die ich derzeit aber nicht erkenne. Aus meiner Sicht ist lediglich dein Zusatzbeispiel schlecht, weil es kaum klarstellt (und dazu noch in einer speziellen Syntax), was "mehrdimensional / Array-in-Array" ist. Stattdessen enthält es Details, die da nicht hingehören bzw. zur Erklärung nicht erforderlich oder gar hinderlich sind. Schon die Beispiele Regalboden, einHammer, Bit lassen eher auf eine reale, gegenständliche Situation schließen als auf einen programmtechnischen Anwendungsfall, schließlich wird "Array" in diesem Zusammenhang hier behandelt.

Wenn du eine 3M einholen willst, habe ich nichts dagegen. Allerdings müsstest dann DU die Beschreibung dazu liefern - und hierbei befürchte ich wiederum, dass wir beide nicht einig werden, weil wir einfach "anders ticken". Als Alternative schlage ich vor, wir bitten einige uns bekannte andere Autoren um ihren "Senf". Nochmal: Aus meiner Sicht gehts nur darum, dass das neueste Beispiel für dieses Lemma, Teilthema "Array-in-Array", (auch für die OMA) nicht gut geeignet ist. Einige Hinweise dazu enthalten meine obigen Disk-Beiträge, vielleicht sind sie unvollständig, aber in der jetzigen Form passt das einfach nicht. --VÖRBY (Diskussion) 15:34, 24. Apr. 2015 (CEST)

Als zweites Beispiel halte ich eine derartige Form (OOP, dyn. Arrays etc.) grundsätzlich für sinnvoll (s.o.), aber dann müssten ausführlichere Erläuterungen, schon im Einleitungstext zum Beispiel, geliefert werden. Ich könnte es mal versuchen? --VÖRBY (Diskussion) 11:06, 25. Apr. 2015 (CEST)

Vielleicht kann ich eine ganz andere 3. Sicht beisteuern:

Mir scheint es notwendig, früh in der Darstellung den "Index" einzuführen, dann vereinfacht sich die Erklärung. Ein Feld ist durch einen Datentyp und einen Indextyp charakterisiert. Der Datentyp beschreibt die Art der gespeicherten Elemente, während der Indextyp beschreibt, wie man ein gewünschtes Element auswählt. Wenn der Indextyp ein ganzzahliges Intervall ist, dann haben wir es mit dem "klassischen" Feld zu tun. Wenn der Indextyp z.B. eine Zeichenkette, oder ein anderer, "komplexer" Typ ist, dann handelt es sich um ein assoziatives Feld. Ein mehrdimensionales Feld hat ganz einfach mehrere Indices. Die Dimension ist demnach die Anzahl der Indices. --Stefan (Diskussion) 19:15, 25. Apr. 2015 (CEST)

Hm. VÖRBY will unbedingt einbringen, dass es etwas ganz anderes sei, ob ein Array "elementare Daten" enthält, oder "Verbund-Objekte". Und wenn solch ein Verbund-Objekt wiederum ein Array enthalte, werde das "äußere Array" ja mehrdimensional.

Außerdem gäbe es ja auch Arrays, die nicht nur 1 Datentyp hätten, sondern wie eine Baumstruktur pro Ast verschieden tief sein können, und verschiedene Datentypen als Blätter besitzen können.

Wenn ich dann allerdings mal ein solches Beispiel bringe, scheint er's auch nicht wirklich zu verstehen (oder verstehen zu wollen).

Da er das unbedingt alles auch hier abgehandelt haben möchte, wird's etwas komplizierter...

--arilou (Diskussion) 13:24, 28. Apr. 2015 (CEST)

@VÖRBY:

Wenn ich mir das Beispiel oben noch mal genauer ansehe - und mit deinen Kommentaren dazu - muss ich sagen:

Beispiel

 Lager      := array(10)                   // Es gibt 10 Lager = Feld der 1. Dimension
  LagerNr   := Text(4)                     //  darin: jedes wird mit seiner Nummer geführt
  Produkt   := array(100)                  //  ... und in jedem Lager (max.) 100 Produkte, = Feld der 2. Dimension
   ProdNr   := Text[6]                     // Je Produkt dessen Nummer mit max. 6 Stellen 
   EK_Preis := FixPunktZahl[4;2]           //  ... und dessen Einkaufspreis

Das ist Schrott. Es ist nämlich kein Beispiel für "mehrdimensional", sondern nur eine verkappte Schreibweise für "1-dimensionales Array über einem Verbund-Datentyp". Dass der Verbund-Datentyp wiederum ein 1-dim. Array (Namens 'Produkt') enthält, macht 'Lager' mitnichten mehrdimensional. (Die Datenstruktur 'als ganzes betrachtet' ist dann (teilweise) mehrdimensional, aber nicht 'Lager'.)

--arilou (Diskussion) 13:34, 28. Apr. 2015 (CEST)

@Arilou. Du hast schon wieder vergessen, dass wir festgestellt haben, es gibt zwei Versionen: 'In-sich-Mehrdimensional' (mit Datenelement(en) nur in der innersten Ebene) und 'Array-in-Array'. Letzteres zeigt mein Beispiel; ja die gesamte Struktur ist hier mehrdimensional, wie es im Text vom (10:06, 17. Apr. 2015) auch beschrieben ist.

Was du Stefan.Heinzmann geantwortet hast, ist einfach falsch. Es geht um Beispiele für die zwei Varianten von Arrays, und um sonst nichts. Der letzte Stand dazu war, dass ich behaupte, dein Beispiel ist nicht geeignet, WP-Lesern (also Laien) die zweite Version von 'mehrdimensional' zu erläutern.

Was Stefan.Heinzmann einbringt, ist auch richtig. Das ist aber etwas anderes. Unsere Diskussion begann damit, dass man den Begriff 'Dimension' erläutern sollte. Ja, das ist immer das, wofür ein Index erforderlich ist, deshalb wird Index und Dimension zum Teil begrifflich auch synonym benutzt (Dimensionsanzahl = Anzahl der BEIM ZUGRIFF erforderlichen Indices). Was für eine Art Index das ist, sollte dabei aber keine Rolle spielen. Auch nicht, was für Datentypen im Array vorkommen. Ja, jedes Array könnte da anders beschaffen sein - woraus sich bei Schachtelung alle möglichen Kombinationen ergebenkönnen. Die Beispiele beziehen sich hier nur auf die beiden Reinformen - die man in der Literatur als 'Arrays unterscheidend' findet.

Mein Vorschlag zur Erweiterung des zweiten Beispiels (falls man das braucht) wäre:

• Im einleitenden Text wird erläutert, dass im Beispiel dynamische Belegung des Array beschrieben wird - die nur in bestimmten Programmiersprachen möglich ist. Und dass unterstellt wird, dass das Array in einer Anwendung 'Lagerführung' verwendet wird (also kein reales, sondern ein datentechnisches Konstrukt).
• Je Regalboden können bis zu x Werkzeugkisten eingestellt werden (besseres Realbeispiel)
• In die Kästchen (= 3. Dimension) können Kleinteile eingelegt werden: Nägel, Schrauben, Muttern, usw., (besseres Beispiel)
• größere Werkzeuge (nur gleiche) können nur in Werkzeugkisten ohne Kästchen eingelegt werden, das Array zählt je WZ-Kiste die WZ-Anzahl. (= dann nur 2D)
• Für jede Indexebene gibt es ein Datenfeld 'Bezeichnung' (zeigt zB die Beschriftung für Lagerböden, Werkzeugkisten, Einzelkästchen)
• Beim Zugriff auf die Daten werden nur Teile aus Unterarrays gelesen (zB Bezeichnung) --VÖRBY (Diskussion) 16:44, 28. Apr. 2015 (CEST)

Habe die Logik des bish Beispiels i.W. beibehalten, nur Zusatzangaben gemacht. Die alternativen Formulierungen (Boden (x,y)) anstatt WZ-Kiste (x,<)) sind sehr sprachspezifisch, gehören nicht zur Erklärung einer 'Array-in-Array'-Struktur und verwirren den Leser nur.--VÖRBY (Diskussion) 19:23, 29. Apr. 2015 (CEST)

Wir wollen doch mit den Beispielen den Unterschied zwischen den zwei Varianten zeigen. Das gelingt aber mMn nur, wenn wir _ein_ Beispiel haben, dass mit den 2 Varianten dargestellt wird. Inzwischen gibt es für mehrdimensionale Felder ganze 3 Fachbereiche, in die sich der Leser eindenken muss (Schachbrett, Brennraumtemperaturen, Lagerirgendwas). Das ist höchst verwirrend und zeigt nicht die Einsatzgebiete, Vor- und Nachteile der Varianten auf. Wir sollten uns daher auf ein Fachgebiet / Beispiel beschränken - am besten eines, das keine Erklärung bedarf (z.B. Schachbrett) --Sebastian.Dietrich ✉ 20:09, 28. Apr. 2015 (CEST)

Danke für das Einmischen. Ein Schachbrett ist aber nur 2D und vom Typ 'in-sich-mehrdimensional'. Damit lässt sich die andere Variante ('Birnen?) nicht vergleichen. Die muss man schon getrennt erläutern, zusätzlich zum beschreibenden Text.--VÖRBY (Diskussion) 09:23, 29. Apr. 2015 (CEST)

Stimmt, bei Schachbrett denkt man eher an Figuren auf einem 2-Dimensionalem Brett als an Figuren in Reihen und Spalten. Es muss ja nicht ein Schachbrett sein. Es gibt sicher Beispiele, wo man nicht von vornherein eindeutig an Birnen _oder_ Äpfel denkt. Wie wärs z.B. mit einem Parkhaus/Tiefgarage. Ist eigentlich ein 3-dimensionaler Raum, ein Auto steht auf A325, aber intuitiv denken wir an Ebene A und dann erst Stellplatz 325 bzw. Reihe 3 Parkplatz 25. Ist also weder Apfel noch Birne und somit (ohne weitere Anforderungen) genausogut als array(5, 8, 50) of Stellplatz wie als array(5) of Parkdeck, array(8) of Parkreihe, array(50) of Stellplatz modellierbar.

Damit kann man auch gut auf die Vor- und Nachteile und somit Einsatzgebiete eingehen (z.B. Speicherverbrauch, unterschiedliche Zugriffsperformance wegen "Pointerarithmetik", unterschiedliche Sub-Dimensionen wenn z.B. das Parkhaus unten breiter ist als oben, ...)

P.S. in [9] ab 35:00 (Java, wo nur 2teres möglich ist) werden einige der Nachteile der 2ten Möglichkeit erwähnt: Performance, v.a. Cache-Misses, die wegen der Object-Identity nicht irgendwie umgangen werden können. --Sebastian.Dietrich ✉ 20:52, 29. Apr. 2015 (CEST)

Gutes Beispiel, das Parkhaus. So wie ich bisher den Unterschied zwischen Variante A und B verstehe, trifft A dann zu, wenn es nur Infos auf der letzten 'Ebene' (= Parkplatz A325) gibt (belegt/frei, evtl. seit ...). Führt das Array auch Infos zu Ebene und zu Reihe, liegen also Arrays (mit Daten belegte!) ineinander, ist dies die 'verzweigte' Variante 'Array-in-Array' (Ebene = Stämme, Reihe = Äste, Parkplatz = Blätter).

Die Vor-/Nachteile sind sicher auch (mal wieder) sprachabhängig. Man kann die hier bei den Dimensions-Beispielen erwähnen, vielleicht auch bei 'Sprachspezifisches'. Die Entscheidung, welche Beispiele verwendet werden (das Disk-Thema hier), macht das sicher nicht einfacher. Das wäre eine neue Sicht - die die Intentionen aus Bsp 2 (dynamische Arrays) vorläufig mal außer Acht ließe. --VÖRBY (Diskussion) 11:18, 30. Apr. 2015 (CEST)

@VÖRBY: Du verstehst anscheinend noch immer nicht den Unterschied zwischen (a) "Array mit gemischten Inhalten (und ggf. verschiedenen 'Tiefen')" und (b) "Array über Verbunddatentyp". Das sind zwei verschiedene Dinge ~ auch wenn sie in manchen Skript-/Makrosprachen auch mal zusammenfallen können. Deine Beispiele sind bisher ausschließlich (b). Das sieht man auch deutlich daran, wie du krampfhaft versuchst, mein (a)-Beispiel (Regalboden/Werkzeugkiste/...) auf ein (b)-Schema umzukrempeln.
Nein, ein Regalboden sei nicht auf 'x Werkzeugkisten' beschränkt, sondern könne beliebige Objekte aufnehmen. Und zwar welche, die entweder weitere Räume bieten (Werkzeugkiste) und damit diesen Array-Ast um eine Dimension erweitern, oder Objekte, die keine weiter Untergliederung erzeugen (z.B. ein Hammer). Gerade das ist der Witz an der Sache. Und nein, es wird nicht bei der Deklaration festgelegt, wo/in welcher Reihenfolge in 'Regalboden' was für Objekt(typen) stehen - das ist dann nämlich eine verkappte Verbundtyp-Deklaration, und 'Reihenfolge' würde dann zu einem (b)-Beispiel. Durch '(a)-Typ' gibt es Zugriffe auf Regalboden, die 1, 2 oder 3 Indizes benötigen - oder auch bei 2 oder 3 Indizes zu einem Fehler führen können.

Was eine Lagerverwaltung mit 'Regalboden', 'Werkzeugkiste' usw. zu einem "Nicht-Realen" Beispiel machen soll verglichen mit einem Beispiel mit "Produkt, Preis, Lagerbestand", das darfst' mir auch mal erklären.

--arilou (Diskussion) 10:47, 4. Mai 2015 (CEST)

--@Arilou: bei dem "Lagerboden"-Array werden offenbar erst bei der Initialisierung, also zur Laufzeit, die (unterschiedlichen) Typen der einzelnen Elemente festgelegt. Welcher Compiler läßt sowas zu ? (ein Beispiel) --RobTorgel 11:43, 4. Mai 2015 (CEST)

Man braucht dynamische Typisierung, das ist v.a. bei Skript-/Interpreter-Sprachen gebräuchlich. Z.B. erlaubt Common Lisp, verschiedentypische Dinge in eine Liste zu packen (String, Ganzzahl, Objekt, Funktion, Symbol, Array(dort:Liste), wild gemischt wenn gewünscht). Mit Python, Perl, PHP, JavaScript, VBScript kenn' ich mich nur sehr eingeschränkt aus, wo dort ein "mehrere-Indizes"-Zugriff erst zur Laufzeit aufgelöst wird (mit ggf. Fehlermeldung, wenn's nicht geht). Diese Skriptsprachen bieten meist generell nur Hashtables als 'Array' an. (VBA wäre noch ein Kandidat.)

--arilou (Diskussion) 14:05, 6. Mai 2015 (CEST)

@Arilou: Dein Beispiel ist eines für eine OOP-Programmiersprache, meins beschreibt dieselbe fachliche Aufgabe, aber ohne dynamische Elemente. Das bietet doch die Chance, beides zu zeigen - aber für die B-Variante!!! Das ist der Unterschied. Ja, meine Beispiele sind B-Beispiele. Und deines auch, nur eben mit Dynamik - aber verstehen sollte man es! Und: Es ist nicht 'in-sich-mehrdimensional', sondern A-i-A.

Was du oben mit a) und b) bezeichnest, haben wir nie diskutiert: Mit a) haben wir immer 'in-sich-mehrdimendional' und mit b 'Array-in-Array' behandelt. Wenn wir jetzt für b) zwei Beispiele bringen würden (so wie auch bei eindimensional), eines für eine statische Array-Definition (zB Cobol, PL/I, VBA) und eines für eine dynamische, dann wäre das doch eine gute Sache. Deshalb änderte ich mein Beispiel, auch auf den Rat von Sebastian.Dietrich nach einheitlichen Beispielen eingehend. Also bitte nicht so tun, als gäbe es nur dynamische Arrays. --VÖRBY (Diskussion) 13:34, 4. Mai 2015 (CEST), ergänzt: --VÖRBY (Diskussion) 18:55, 4. Mai 2015 (CEST)

Dieses Beispiel

 Lager      := array(10)                   // Es gibt 10 Lager = Feld der 1. Dimension
  LagerNr   := Text(4)                     //  darin: jedes wird mit seiner Nummer geführt
  Produkt   := array(100)                  //  ... und in jedem Lager (max.) 100 Produkte, = Feld der 2. Dimension
   ProdNr   := Text[6]                     // Je Produkt dessen Nummer mit max. 6 Stellen 
   EK_Preis := FixPunktZahl[4;2]           //  ... und dessen Einkaufspreis

sollte man zur Klarheit umformulieren in

 Lager      := array(10) of Verbundtyp {
     LagerNr   := Text[4]
     Produkt   := array(100) of Verbundtyp {
         ProdNr   := Text[6]
         EK_Preis := FixPunktZahl[4;2]
       } // Ende abstrakter Verbundtyp 'Produkt_Verbund'
     // Ende Array-Def. 'Produkt'
   } // Ende abstrakter Verbundtyp 'Lager_Verbund'
 // Ende Array-Definition 'Lager'

Denn eine solche verkappte Definition eines Arrays über einem Verbundtyp ist das nämlich. Das hat absolut gar nichts mit einer "Array-in-Array"-Betrachtungsweise eines mehrdimensionalen Arrays zu tun, sondern zeigt nur, dass in einem Verbundtyp wiederum ein Array stecken kann. Dadurch wird das "äußere Array" aber mitnichten mehrdimensional. (Wohl jedoch die 'Gesamt-Struktur'. Zur Verdeutlichung: Man könnte auch eine einfache Variable anlegen, die vom Typ 'Produkt_Verbund' sei - die ist gar kein Array, ihr Inhalts-Objekt enthält aber (intern) ein Array 'Produkt'...)

--arilou (Diskussion) 12:34, 6. Mai 2015 (CEST)

PS: Das Beispiel zeigt auch nicht den Fall

"Array mit verschieden-typigen Inhalten, davon manche wiederum Arrays, und daher 'Baum-Struktur' mit teilweise verschiedener Tiefe"

denn jedes Array (in deinem Beispiel) hat genau 1 Inhalts-Typ: einen (abstrakten, implizit definierten) Verbundtyp - dieser wiederum hat verschiedene Komponenten, nicht jedoch das Array 'Lager' (oder das Array 'Produkt')... //von Arilou

• Es wurde festgelegt, dass in den Beispielen keine konkrete Sprachsyntax verwendet wird, sondern lediglich eine "symbolische". Insofern braucht es keine Angaben wie 'of Verbundtyp', verbunden mit geschweiften Klammern etc. Das Beispiel ist auch in der jetzigen Form eindeutig.
• Wenn ein Array in einem Array definiert ist, dann entspricht das wohl der Betrachtungsweise "Array-in-Array". Was sonst? Dass dabei die Gesamtkonstruktion 'mehrdimensional' wird, ist auch klar. Auch wenn jedes Array für sich nur eindimensional ist; wie sollte es auch sonst sein, wenn es nicht vom Typ A ("in-sich-mehrdimensional" (I-s-m)) ist?
• Außerdem glaube ich, dass es hier - mal wieder - um Gewohnheiten in verschiedenen PrSprachen geht: In einer Entwicklungsumgebung werden derartige Schachtelprodukte als 'mehrdimensional' bezeichnet (Bsp. siehe [10], 'Schuhe' = Verbund), in anderen betrachtet man sie vielleicht jeweils als eindimensional. Allerdings: Wie sollte es dann überhaupt mehrdimensionale Arrays geben - außer bei "I-s-m"? Und: Beim Zugriff braucht man mehrere Indices - in der Literatur oft als Kriterium für 'mehrdimensional' genannt.
• Dein Beispiel 'Produkt-Verbund': Abgesehen davon, dass auch sowas nur in bestimmten Sprachen 'geht', wäre 'Produkt' dann ganz klar ein eindimensionales Array - in seiner Einbettung. Solange es aber innerhalb eines anderen Arrays liegt, liegt (insgesamt) ein zwei-/mehrdimensionales Array vor.
• Dass innerhalb des Arrays ungleiche Typen auftreten können, und auch, dass statt eines (Unter-)arrays ein anderer Datentyp verwendet werden kann, ist nur in bestimmten Sprachen möglich. Mit der grundsätzlichen Definition von 'Array' und 'mehrdimensional' hat das primär nichts zu tun. Ja, mein Beispiel zeigt lediglich die Grundkonstruktion eines 2-dimensionalen Arrays - ohne "Schnick-schnack" in unterschiedlichen Sprachen. Dein Beispiel zusätzlich könnte, wie oben mehrfach vorgeschlagen, derartige Unterschiede/Besonderheiten aufzeigen. --VÖRBY (Diskussion) 12:31, 7. Mai 2015 (CEST); ergänzt: --VÖRBY (Diskussion) 20:19, 7. Mai 2015 (CEST)

Datenfeld

Im Artikel steht: ...wird der hier – mit der Bedeutung ‚Array‘ – beschriebene Begriff ‚Feld‘ mit unterschiedlichen Ausdrücken belegt: Array, Tabelle, Vektor, Reihe, Reihung, Datenfeld, ... Ist Datenfeld und Feld (Datentyp) nun dasselbe oder nicht?? --UvM (Diskussion) 15:39, 10. Apr. 2015 (CEST)

Kontextabhängig: Ja. Und: Nein.

Wie so manche Begriffe in der noch recht jungen Informatik kann der Begriff "Datenfeld" verschiedene Bedeutungen haben:

1. ein Speicherplatz für nur genau 1 Datum;
   Der Artikel Datenfeld geht überwiegend von dieser Bedeutung aus (mit Ausnahme des letzten Satzes).
2. ein Array als "Feld von Daten", also ein Array. Hießiger Artikel geht überwiegend von dieser Bedeutung aus.

--arilou (Diskussion) 15:53, 10. Apr. 2015 (CEST)

Defekte Weblinks

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Die folgenden Weblinks wurden von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieser Fehler finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://www.programmersbase.net/Content/Java/Content/Tutorial/Java/Array.htm
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://www.programmersbase.net/Content/Java/Content/Tutorial/Java/Array.htm
• http://www.mitp.de/imperia/md/content/vmi/0945/0945_kap011.pdfhttp://giftbot.dwl.invalid/http://www.mitp.de/imperia/md/content/vmi/0945/0945_kap011.pdf
  • Artikel mit gleicher URL: Literal (aktuell)
• http://www.aspheute.com/artikel/20000927.htm
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Netzwerk-Fehler (7) andere Artikel, gleiche Domainhttp://giftbot.dwl.invalid/http://www.aspheute.com/artikel/20000927.htm

– GiftBot (Diskussion) 21:42, 26. Nov. 2015 (CET)

Adressierung eines Feldes

@VÖRBY:: Lass uns bitte über deinen Revert bzw. meinen Edit sprechen. Zunächst möchte ich festhalten, dass dieser sich in drei Teile teilen lässt:

1. Rechtschreibfehler (mittlerweile durch folgenden Edit bereits wiederhergestellt)
2. Vermeidung von Link auf Begriffserklärungsseite (Assemblersprache statt Assembler). Btw. unter Einstellungen gibt es das Helferlein "Begriffsklärungs-Check"
3. In meinen Augen Verbesserung des Beispiels. Ersten worauf wir uns hoffentlich einigen können ist, dass es mit Einrückungen der "Gleichungen" übersichtlicher wird. Zweitens bereichert es den Artikel, meiner Meinung nach, die korrekten Einheiten zu verwenden und macht es auch deutlicher. Und drittens finde ich auch es anschaulicher - wenn es sich um ein 2D-Array/Feld handelt - auch eine Repräsentierung in Form von einer Matrix zu zeigen. Vllt. ist das etwas "zu mathematisch" (war das dein Einwand bzgl. Sprachneutralität?), aber die Notation von 1..4 ist mir hingegen nicht ausreichend und habe ich bislang nur bei Bash gesehen; noch nie aber bei anderen (ausformulierten) Texten. In letztgenannten Detail könnnten wir uns vllt auf eine Ausformulierung einigen: von 1 bis 4? --Nobelium (Diskussion) 18:12, 3. Apr. 2018 (CEST)

Servus Nobelium. Bei Punkt 1 und zwei hast Du Recht, ich wollte nur das von Dir eingebrachte 'Lösungsbeispiel' rückgängig machen und hatte die beiden anderen Aspekte übersehen; sorry. Zum Dritten: Der fragliche Abschnitt will/soll beschreiben, wie bei Befehlen mit Indizes die Zielfelder berechnet werden. Das sollte so formuliert sein, dass es JEDER versteht, unabhängig von einer bestimmten Sprachsyntax. Das ist mit Deiner Notation nicht der Fall. Ob man den Fließtext 'übersichtlicher' machen könnte, sei dahingestellt. Jedenfalls erklärt er einfachstmöglich, wie bei Programmbefehlen für ein 2D-Feld die tatsächliche Adresse gefunden/berechnet wird. --VÖRBY (Diskussion) 18:43, 3. Apr. 2018 (CEST)

Danke für deine Antwort und für deinen Dank meines partial Revert-Reverts. Einiges habe ich aber noch nicht verstanden:

„(…) unabhängig von einer bestimmten Sprachsyntax“: Was für eine Sprachsyntax habe ich denn verwendet? Ich habe eine Matrix-Repräsentation verwendet. Das finde ich jetzt nicht unverständlicher; eher im Gegenteil sogar anschauchlicher.

Es tut mir immer weh, wenn ich Gleichungen mit Einheiten sehe, die auf beiden Seiten des Gleichheitszeichen nicht passen. Deswegen habe ich das ordentlich/korrekter formuliert. --Nobelium (Diskussion) 21:49, 4. Apr. 2018 (CEST)

Ähm, lieber Nobelium, du hast auch einen erheblichen Fehler eingebaut:
Deine 'Matrix' ist nicht 4 x 7, sondern 7 x 7 Elemente groß! ...Und passt damit nicht mehr zum Fließtext.

Ansonsten finde ich deine "grafische Darstellung als Matrix" aber gut.

Das mit den "Einheiten in den Gleichungen" ließe sich ähnlich elegant beheben, indem man

[...]
2 (Zeilen) * 7 (Elemente pro Zeile) * 4 (Byte pro Element) = 56 (zu überspringende Bytes)
[...] also sind weitere 5 Elemente zu „überspringen“:
5 (Elemente) * 4 (Byte pro Element) = 20 (zu überspringende Bytes)
[...]

ergänzt. Das fügt sich auch optisch besser in den Fließtext ein.

--arilou (Diskussion) 09:16, 5. Apr. 2018 (CEST)

Huch! Ja da hat sich tatsächlich ein Fehler in der Matrix eingeschlichen. Da ich gerade mit quadratischen Matrizen arbeite muss ich das geistesabwesend quadratisch gemacht haben. Sorry.

Ok, das könnte ich auch akzeptieren. Die Einheiten passen jetzt zumindest wieder. Auch wenn ich den Bruchstrich als schöner empfinde --Nobelium (Diskussion) 12:18, 5. Apr. 2018 (CEST)

@Nobelium: Nicht alle Leser konnten deine 'Formeln' lesen / verstehen. Die wohl mathematisch-korrekte Formulierung in Bruchform (das meinte ich mit "Syntax") überfordert Nicht-Mathematikern möglicherweise. Der Sachverhalt kann rein textlich ebenso vermittelt werden. Arilou hat (durch erläuternde Klammerausdrücke) noch verständlicher gemacht. --VÖRBY (Diskussion) 09:28, 5. Apr. 2018 (CEST)

Ähm, Vörby: In der Mathematik ist 'pro' gleichbedeutend mit 'Bruchstrich'; daher

• ist "meine 'rein textlich(e)'" Formulierung genauso mathematisch (Einheiten-)korrekt wie Nobeliums Version;
• im Umkehrschluss ist Nobeliums Variante auch nicht "schlechter" als meine.

Ich sehe den (einzigen) Unterschied in der visuellen Gestaltung - Nobeliums Variante hebt sich mehr vom Fließtext ab. Die Frage ist, ob das gewünscht ist.

--arilou (Diskussion) 09:59, 5. Apr. 2018 (CEST)

"In der Mathematik": Es soll auch Nicht-Mathematiker geben, Leute, die einen Bruch als Zähler und Nenner verstehen - und darin eine Division vermuten. --VÖRBY (Diskussion) 11:18, 5. Apr. 2018 (CEST)

Aber man hat doch schon von "km/h" gehört/gelesen oder "Kilometer pro Stunde" gehört!!! Unverständnis meinerseits das nicht zu verstehen und ich wäre wohl nicht darauf gekommen, dass nicht verstehen zu können. Solange die Einheiten stimmen soll mir das aber egal sein.

Bleibt nur noch die Frage nach der (korrekten) Matrix. (Lasst uns mit Handzeichen abstimmen. Seht ihr alle meine Hand? ;-) ) --Nobelium (Diskussion) 12:18, 5. Apr. 2018 (CEST)

Mehrdimensional / assoziativ / dynamisch

Hi Arilou, der Satz "Derartige Arrays sind meist nur in dynamisch typisierenden Sprachen mittels assoziativer Arrays umsetzbar; in statisch typisierenden Sprachen wird eine derartige Struktur mittels Verbund-Datentypen abgebildet und behandelt." ist an dieser Stelle unpassend: Dort werden einfach nur mehrdimensionale Arrays beschrieben. Ob diese assoziative Arrays sind oder über direkt einen numerischen Index adressiert werden, ist dabei unerheblich und beides möglich. Auch ist HIER nicht behandelt, ob das Array dynamisch ist oder statisch. Dass solche Arrays nur über assoziative Arrays umsetzbar sind, ist also falsch. Welchen Lösungsbeitrag dazu der Verbund-Datentyp liefern sollte, ist mir auch nicht klar. M.E. könnte dieser Satz einfach raus - oder er sollte klarer beschreiben, was gemeint ist. Ich grüße Dich: --VÖRBY (Diskussion) 11:27, 4. Jun. 2019 (CEST)

Ich bin nicht sicher, ob ich darüber nochmal mit dir streiten will.

Schon deine Aussage "Ob diese assoziative Arrays sind oder über direkt einen numerischen Index adressiert werden, ist dabei unerheblich und beides möglich." zeigt Verständnis-Probleme. Ein assoziatives Array kann durchaus mittels Index befüllt und auch wieder abgefragt werden. Das macht es aber nicht zu einem "normalen" Array.

Ich halte den Satz a) für richtig und b) für an dieser Stelle sinnvoll.

"dieser Satz [...] sollte klarer beschreiben, was gemeint ist." - ich denke, das liegt an einem Verständnis-Problem deinerseits, was assoziative Arrays genau sind. (Der WP-Artikel zu ihnen ist aber auch nicht wirklich gut.)

--arilou (Diskussion) 13:15, 5. Jun. 2019 (CEST)

Hi! Also "Assoziatives Datenfeld" ist - als dessen charakterisierende Besonderheit - so beschrieben, dass es "- anders als ein gewöhnliches Feld (engl. array) – nichtnumerische (oder nicht fortlaufende) Schlüssel (zumeist Zeichenketten) verwendet, um die enthaltenen Elemente zu adressieren." Man kann damit also nicht einfach einen Index zur Adressrechnung Adresse = (X-1) * Länge(Feld)) verwenden, sondern muss (oft als Teil der Compilerfunktionalität) ein eigenes Suchverfahren ("Bäume oder Hashtqabellen") 'vorschalten'. Auf diese Definition beziehe ich "assoziativ" - etwas anderes kenne ich nicht. Ganz eindeutig beschreibt das auch [11]: "Assoziative Arrays unterscheiden sich von normalen Arrays in nur einem Punkt: Anstelle von Zahlen-Indizes haben assoziative Arrays Namen als Index-Wert."

Außerdem und nochmal: Der Abschnitt beschreibt mehrdimensionale Arrays, da ist das Adressierungsverfahren egal - und auch, ob das Array eine dynamische oder statische Größe aufweist. Sorry! --VÖRBY (Diskussion) 16:26, 5. Jun. 2019 (CEST); Quelle PHP: --VÖRBY (Diskussion) 16:45, 5. Jun. 2019 (CEST); präzisiert, typo: --VÖRBY (Diskussion) 18:20, 18. Jun. 2019 (CEST)

Keine Antwort mehr; ich habe den fraglichen Satz vorläufig mal entfernt. Ggf. sollte er dort eingefügt werden, wo er passt. ERLEDIGT: --VÖRBY (Diskussion) 18:20, 18. Jun. 2019 (CEST)