Diskussion:Feld (Datentyp)/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Feld (Datentyp)/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung auVorlage:SSerhalb der Wikipedia

https://de.wikiup.org/wiki/Diskussion:Feld_(Datentyp)/Archiv/1#Thema_1

(alt:) assoziatives Array

Das ist nicht ganz richtig. Später mehr... schrieb Benutzer:141.19.7.3 zum assoziativen array -- ∂ 14:32, 2. Mai 2005 (CEST):

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 11:15, 30. Mär. 2015 (CEST)

Bezeichnung

Ist ein Array nicht einfach nur ein Feld bzw. der englische Begriff für das deutsche Feld? Wo liegt da der Unterschied? Ggf. sollten wir es dorthin verschieben. Stern 01:35, 27. Jan 2006 (CET)

Das stimmt zwar, und der Artikel wurde entsprechend verschoben. Aber benutzt wirklich irgendjemand den deutschen Begriff?! Spätestens beim „assoziativen Feld“ kommen mir massive Zweifel.

(Schon das „assoziative Array“ ist eine ärgerliche, wenn auch eingeführte Bezeichnung; man muß sie nicht auch noch eindeutschen, sondern sollte dann m. E. eher etwas wie „Zuordnungstabelle“ verwenden.) --Tobias 12:00, 19. Jan. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 11:15, 30. Mär. 2015 (CEST)

In was für ein Programm kann dies genutzt werden

Lernt man das in Java, in Derive, oder sonst irgendwo. Oder einfach überall, wo kann man so ein Array programmieren, bzw. nutzen.

mfg

magigstar

Die meisten Programmiersprachen unterstützen Arrays. Diese sind normalerweise in der Form variable[index] aufgebaut. Du kannst ein Array zum Beispiel mit PHP "programmieren" mit folgender Syntax: $variablenname = array('element1', 'element2', 'element3', usw..);

Das Array wird dann so aufgerufen: $variablenname[0] oder $variablenname[1], je nach dem, wieviele Elemente sich im Array befinden.

--Rotschi 12:49, 30. Mai 2006 (CEST)

Kann man das auch in Java programmieren?

mfg magigstar

klar... aber ich denke, du solltest dich zuerst einmal mit java befassen, dort sind arrays noch das einfachste, was du wissen musst :)

--Rotschi 08:04, 7. Jun 2006 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 11:15, 30. Mär. 2015 (CEST)

\array

Hallo, in <math> wird gar nicht \array unterstützt! Was kann man machen?

Zunächst einmal die Frage präziser stellen, sodaß man sie auch versteht. Aber hier ist sicher nicht der Ort, die Nachprogrammierung von Arrays in verschiedenen Programmiersprachen zu erörtern. --Tobias 12:00, 19. Jan. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 11:15, 30. Mär. 2015 (CEST)

Neutrinodetektor unter "Siehe auch"!?

Warum findet sich unter "Siehe auch" im Array-Artikel der Stichpunkt Neutrinodetektor!? Kann keinen Zusammenhang erkennen. --maststef 19:19, 21. Jan. 2008 (CET)

Ich sehe gerade, Strahlungssensor wird als Beispiel genannt. Aber das ist doch schon etwas weit hergeholt oder? Ich meine, man kann auch Kühlschränke oder Papierschnippsel als Array anordnen...

Deswegen erscheint mir der Link zu Neutrinodetektor arg willkührlich. Ich wäre für entfernen, da das nur Verwirrung stiftet. Meinungen? --maststef 19:23, 21. Jan. 2008 (CET)

Hat sich wohl inzwischen erledigt. --Tobias 12:00, 19. Jan. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 11:15, 30. Mär. 2015 (CEST)

Eigener Artikel "Index"?

Nur mal in den Raum gefragt, wäre es wünschenswert, zum Begriff "Index", wie er im Zusammenhang mit Feldern verwendet wird, einen eigenen Artikel zu haben? In der BKL Index finde ich momentan nichts Passendes, und dabei ist diese Art von Index doch eine der elementarsten und wichtigsten in der Informatik. Beim Lemma wäre ich schmerzfrei, vielleicht Feldindex? --Neitram ✉ 14:01, 27. Dez. 2016 (CET)

Ja, in der BKS könnte auf dieses Konstrukt klarer hingewiesen werden. Ich denke aber, ein Link auf einen Absatz HIER im Lemma würde genügen. Zum Beispiel mit dem Text:

• Index: In der Programmierung eine Wertangabe (als Teil eines Befehls), mit der bei mehrdimensionalen Daten eine bestimmte Dimension adressiert wird; siehe Feld (Datentyp). --VÖRBY (Diskussion) 14:30, 27. Dez. 2016 (CET)

Ja, das ginge natürlich auch. Ich habe es mal so formuliert hinzugefügt. Übrigens, gibt es Sprachen, in denen Feldindizes nicht-assoziativer Arrays auch negativ sein können? --Neitram ✉ 09:38, 28. Dez. 2016 (CET)

Das mag passen. Der kurze Abschnitt 'Index' steht allerdings sehr 'frei in der Landschaft'; er sollte vielleicht doch bei 'Dimensionen' eingegliedert werden - oder in der Einleitung ergänzt, ggf. mit 'Anker'. --VÖRBY (Diskussion) 09:52, 28. Dez. 2016 (CET)

Ich habe den Begriff jetzt in der Einleitung genannt und per Anker verlinkt. Ich finde, dass er sinnvollerweise erläutert wird, bevor die Abschnitte "Sprachspezifische Unterschiede", "Feldvarianten" und "Dimensionen" kommen, weil alle drei auf ihn Bezug nehmen. --Neitram ✉ 15:01, 28. Dez. 2016 (CET)

[negative Indizes]: Klar gibt's da Sprachen: zumindest von Fortran, Modula, Ada kenn' ich das. Heißt für den Compiler halt, dass er bei z.B. myArray[-100 .. 200] bei jedem Zugriff immer +100 zum Index dazuaddieren muss, dann ist's wieder wie [0..300] ~ recht einfach zu bewerkstelligen.

--arilou (Diskussion) 15:25, 10. Jan. 2017 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: VÖRBY (Diskussion) 13:18, 11. Jan. 2017 (CET)

Effizienz, Programmierer-Einfluss

hierher verschoben von meiner Benutzer-Disku. --arilou (Diskussion) 09:13, 13. Jan. 2017 (CET)

Hallo, zu Deiner Änderung [2]: Der Programmierer kann die Effizienz nicht nur durch die "Wahl der Reihenfolge der Dimensionen" beeinflussen, sondern auch durch andere Mittel. Beispiele sind bereits unten im übernächsten Absatz beschrieben.
Vielleicht sollte man diese Möglichkeiten (zB durch eine Aufzählungsliste) klarer darstellen. Und erwähnen, dass das immer sehr von den Sprachen abhängig ist. Insofern stimmt auch der erste Satz ("nur sehr eingeschränkt") nicht mehr. Ansonsten Danke für Deine Überarbeitungen. --VÖRBY (Diskussion) 16:59, 12. Jan. 2017 (CET)

Die aufgeführten Beispiele:

1. "Berechnungen zur Adressierung": Erledigt in jeder höheren Sprache der Compiler, ohne Eingriffsmöglichkeit für den Programmierer. Bereits berechnete Werte nicht nochmal erneut zu berechnen ist eine übliche automatische Optimierung so ziemlich aller halbwegs moderner Compiler, da kann der Programmierer auch nichts mehr verbessern.
2. "Literal als Index -> AOT-Berechnung": Ebenfalls keine Einflussmöglichkeit für den Programmierer.
   Heutige Compiler verfolgen auch, ob ein Variableninhalt sich bereits zur Compilezeit bestimmen lässt, und behandeln - falls 'ja' - das Ergebnis dann auch wie ein Literal.
3. "Zugriffe auf Feld-Elemente mit gleichem Index": Auch dieses bemerkt ein moderner Compiler, und macht das "Auslagern" intern. Wiederrum keine Einfluss-/Verbesserungsmöglichkeit für den Programmierer.

Damit bleibt von den 3 Beispielen nicht ein einziges, bei dem der Programmierer etwas Positives für die Effizienz bewirken kann.

Es gibt bereits Compiler, die zumindest eine Warnung ausgeben, wenn in n verschachtelten Schleifen (n ≥ Arraydimension) die innerste Schleife nicht auf die 'innerste' Arraydimension zugreift.

Fazit: Die "Folge der Dimensionen" ist (in höheren Programmiersprachen) so ziemlich die einzige sinnvolle Effizienz-Maßnahme, die einem Programmierer offensteht.

(Es mag noch kleinere Feinheiten hier und da geben, aber im Allgemeinen...)

--arilou (Diskussion) 09:13, 13. Jan. 2017 (CET)

Hallo, Du behandelst immer wieder nur "moderne Compiler". Wir beschreiben aber hier Arrays - die in praktisch allen Sprachen inkl. ASS anwendbar sind. Dabei muss, kann oder sollte der Programmierer im Aspekt Effizienz je nach Sprache in allen Beispielen optimierend verfahren, manchmal ist es halt nicht nötig. In diesem Sinn sollte das rüberkommen, sonst sind wir hier einseitig oder unvollständig.

Beispiele: 1) Wenn ein Programmierer einer Index-Variablen vor der Benutzung Ihren Wert per Literal zuweist ("Index = n"), ist das vielleicht stilistisch gut gemeint, aber effizienzbezogen kontraproduktiv. 2) Viele Compiler/Übersetzer wenden keine Auslagerungstechnik an, sondern der Programmierer muss das schon selbst tun. 3a) Index-Variablen sollten in einem Format deklariert werden, die bei der Adressberechnung möglichst keine Formatkonvertierung erfordern; 3b) ebenso trifft das auch für die Feldvariablen selbst (wie für Datenfelder im Allgemeinen) zu. 4) Move von Datengruppen (Index) anstatt vieler elementarer Variablen.

Fazit: Allgemeingültig texten! --VÖRBY (Diskussion) 11:05, 13. Jan. 2017 (CET); weitere Beispiele: --VÖRBY (Diskussion) 10:14, 15. Jan. 2017 (CET)

Ich würde den Abschnitt wie folgt texten:

Die Verarbeitung von Daten innerhalb eines Felds erfordert – im Gegensatz zu ohne Index adressierbaren Datenfeldern – zusätzlichen Aufwand zur Berechnung der tatsächlichen Speicheradresse von Feldkomponenten. Deren Effizienz kann der Programmierer zum Teil beeinflussen, moderne Compiler erzeugen dagegen diesbezüglich oft automatisch optimierten Code. Die folgenden Beispiele nennen Details, deren Anwendung zu effizienterem Code führen kann, weitere Beispiele siehe .

• 3Bei Literalen als Index berechnet der Compiler die Adresse zur Compilezeit. Manche Compiler stellen fest, ob der Index von Variablen abhängt, deren Stand zur Compilezeit bereits bestimmt werden kann.
• 2Verwenden von internen Datenformaten für die Indexvariable, die zur Adressierung keine Formatkonvertierung erfordern.
• 4Wiederverwenden bereits berechneter Zugriffsadressen, anstatt sie für jeden Befehl erneut zu berechnen. Je nach Compiler können dazu geeignete Adressierungsmethoden gewählt werden, zum Teil stellen Compiler diese Wiederverwendung fest und erzeugen automatisch optimierten Code.
• 1Eine geeignete Wahl der Reihenfolge der Dimensionen: Wenn in einem Computer ein Feld im RAM gehalten wird, erfolgen Zugriffe auf Feldelemente in der Regel am schnellsten, wenn direkt aufeinander folgende Adressen abgerufen werden (Lokalität ermöglicht Caching). Der Programmierer ist also gehalten, die Reihenfolge der Indizes im Feld so festzulegen, dass dies in der innersten Schleife ebenso erfolgt. Da die Speicherabbildungsfunktion vom Compiler abhängt, sollte sich der Programmierer über diese Details informieren und dann im Programm den in der innersten Schleife durchlaufenen Index so definieren, dass er im Ram aufeinanderfolgenden Elementen entspricht.
• 5Auslagern von ‚Feld‘-Inhalten bei (ort-/zeitlokal) mehreren/vielen Zugriffen mit gleichem Index in einen eigenen, direkt adressierbaren Speicherbereich.
• Übergeordnete Verbundstruktur ansprechen anstatt vieler elementarer Datenfelder: Zum Beispiel beim Verschieben von Array-Einträgen, etwa beim Sortieren von Array-Inhalten, findet die Adressberechnung bei Bezug auf einen Verbund (Verbund(to-Index) = Verbund(from-Index)) nur einmal je Verbund statt - dagegen bei Bezug auf einzelne Elemente des Verbunds (Feld1(Ind), Feld2(Ind), ...) je Verbund-Element.

Die Zweckmäßigkeit oder Notwendigkeit derartiger Effizienzmaßnahmen (die aus Gründen der Lesbarkeit eines Programms stets gut dokumentiert sein sollten) hängt von verschiedenen Faktoren ab. Nicht oder weniger relevant sind sie zum Beispiel: Wenn der Compiler entsprechende Optimierungen automatisch vornimmt; das Programm selten ausgeführt wird und/oder jeweils nur kurze Zeit läuft; die Feld-bezogenen Befehle nur einem geringen Teil der Gesamtverarbeitung entsprechen.

Temp-References:

@Arilou, willst Du nochmal checken? Danke. Wie gesagt, der Text gilt allgemein, nicht nur für 'moderne Compiler'. Sogar für ASS.--VÖRBY (Diskussion) 11:28, 24. Jan. 2017 (CET)

@VÖRBY Entschuldigung, wenn ich mich einmische. Ich finde es recht gut – würde aber mit Nr. 3 beginnen, dann 2, 4, 1, schließlich 5. Bei 5 stellt sich die Frage, ob die Adressrechnung in einem Zeiger aufbewahrt werden kann.

Des Weiteren wäre m.E. für "direkt adressierbaren" (kommt zweimal vor) eines besseres Wort zu suchen; es ist oft synonym zu RAM. Evtl. einfach eine Negation von der Adressrechnerei? --Nomen4Omen (Diskussion) 14:18, 24. Jan. 2017 (CET)

Danke. Habe die Reihenfolge geändert und oben 'ohne Index adressierbar' (= direkt) verwendet. Damit ist aber nicht RAM gemeint, sondern einfach nur ein 'Speicherbereich', der kein 'Feld' ist. Zu Deiner Zeigerfrage (5): Der Zeiger wäre dann eigentlich #4 - wie gesagt, je nach Compiler. Zu #5 siehe Kommentar dort.

Ich habe die alten Folgenummern zur besseren Orientierung vorläufig noch drin gelassen. --VÖRBY (Diskussion) 17:06, 24. Jan. 2017 (CET)

Weiteres Beispiel Verbund; Hinweis zur Zweckmäßigkeit von Effizienzüberlegungen im Entwurf ergänzt.--VÖRBY (Diskussion) 09:55, 25. Jan. 2017 (CET); Umformulierung: --VÖRBY (Diskussion) 10:57, 25. Jan. 2017 (CET)

Bei "Zweckmäßigkeit oder Notwendigkeit derartiger ..." darf m.E. die Abwägung mit der Lesbarkeit des Programms nicht fehlen. --Nomen4Omen (Diskussion) 11:13, 25. Jan. 2017 (CET)

Danke, Dein Einwand zeigt Deine praktische Erfahrung in solchen Dingen. Habs ergänzt. --VÖRBY (Diskussion) 13:01, 25. Jan. 2017 (CET)

Disk beendet? Dann würde ich also den Entwurf in Kürze so ~ in den Artikel überführen. --VÖRBY (Diskussion) 16:19, 26. Jan. 2017 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: VÖRBY (Diskussion) 09:53, 29. Jan. 2017 (CET)