Diskussion:Hashtabelle

message: dieser begriff und algorithmus fehlem im deutschen wiki komplett, sind aber eine entscheidend neuerung (nicht signierter Beitrag von 87.155.74.7 (Diskussion | Beiträge) 20:44, 14. Apr. 2009 (CEST)
thread_title:  linear hashing 

message: Habe die ersten zwei Punkte entfernt. Meiner Ansicht nach sind sie so wie sie da standen unsinnig. Ich würde vorschlagen die Trennung zwischen Vor- und Nachteilen aufzuheben. Letztendlich beschreibt man Eigenschaften einer Datenstruktur. Was nachteilig für eine Anwendung ist, ist für eine andere einfach nur unwichtig oder sogar Vorteilhaft. Auch der letzte Punkt bei Nachteilen erscheint mir recht Zweifelhaft. Die Darstellung von Extremfällen (z.B. Überfüllung der Datenstruktur) ist recht schwer Pauschal zu beschreiben, weil das Verhalten stark von der Implementierung abhängt. Mocy 02:11, 5. Mär. 2008 (CET)
thread_title:  Nachteile 

message: Divisionsrestmethode, Hashfunktion, Hashtabelle, Hashverfahren schreibt man im Deuschen nicht mit Bindestrich sondern zusammen! Mittelquadmethode schreibt ihr ja auch zusammen. Schwierig wird es bei Hash-Algorithmus, weil Hash eine englisches Wort ist. Aber wenn man Hashverfahren zusammen schreibt, sollt man Hashalgorithmus auch zusammen schrieben. Wenn man das sieht dreht sich wohl einem der Magen um.
Hashwert, ....
: So strikt ist das nicht geregelt. Da "Hash" englisch ist, jedes andere Wort, mit dem du es zusammensetzt, aber deutsch, ist es durchaus statthaft, durch einen Bindestrich den "Sprachwechsel" zu kennzeichnen. Was aber wichtig ist, wenn man sich für eine Schreibung enschieden hat, dass man die dann auch konsequent verwendet. --Sixot 13:53, 31. Jan. 2007 (CET)
thread_title:  Rechtschreibung 

message: Also ich verstehe bei den ersten Zeilen nur Bahnhof. Vielleicht sollte wenigstens mal auf Hashfunktion verlinkt werden, um das Verständnis etwas zu verbessern. Bei den ganzen Begriffen, die als Lemmata markiert wurden, habe ich außerdem das Gefühl, dass man die Thematik lieber in mehrere Artikel aufspalten sollte... --Trainspotter 17:03, 10. Apr 2006 (CEST)
replies: text: Habe den Quatsch aufgeraeumt. Die verbliebenen Begriffe sind synonyme, bzw Hashverfahren ist die Art und Weise eine Hashtablle zu verwalten und somit nicht vom Lemma zu trennen. Gruss -- sparti 19:56, 10. Apr 2006 (CEST)
thread_title: Verständnisprobleme im Lemmabereich

message: Unter Kollisionen steht Da Hash-Funktionen im Allgemeinen nicht eindeutig (injektiv) sind. Müsste es nicht genauer heißen ... nicht eineindeutig (injektiv) ...? Denn eindeutig sind sie ja sehr wohl (sonst wären es keine Funktionen)? Schlage vor, das entweder zu ersetzen oder das Wort eindeutig ganz zu entfernen und nur zu schreiben ... nicht injektiv sind .... Mag kleinkariert klingen, wäre dann aber korrekt. --Matzedi 10:57, 14. Apr 2006 (CEST)
replies: text: injektiv = eineindeutig --Quelokee ? talk ! 04:16, 16. Apr 2006 (CEST)
replies: text:  Also, wenn ich mir das hier durchlese: Injektivität, dann heisst eineindeutig auch surjektiv. Das ist aber hier nicht gemeint. Insbesondere scheint das eineindeutig auch nicht einheitlich verwendet zu werden (siehe Diskussion). Ausser, dass der Text jetzt unverstaendlicher geworden ist, hat das also nicht wirklich zur Klaerung beigetragen. Gruss -- sparti 23:49, 25. Jun 2006 (CEST)
thread_title:  kleine Ungenauigkeit 

message: > Der Geschwindigkeitsvorteil bleibt eigentlich immer gleich unabhängig vom Füllgrad.
Bleibt er jetzt gleich oder nicht? Kann also das "eigentlich immer" gelöscht werden?
:Ich habe die IP-Zusätze wieder entfernt. Sie sind viel zu unpräzise und stimmen nicht bei allen Varianten. Auch Ratschläge, zumal ohne Kontext, geben wir nicht. --Revvar (D RT) 19:40, 27. Jul 2006 (CEST)
thread_title:  Geschwindigkeitsvorteil 

message: "Dieser Index stellt im Idealfall die genaue Position des gesuchten Elementes in der Tabelle dar. Dieser Idealfall ist nicht immer gegeben, darum kann es auch zu Kollisionen kommen."
Diese Formulierung ist nicht ganz klar, oder? JaK 13:18, 20. Mär. 2007 (CET)
replies: text: Ich habe es etwas erweitert. Ist es so besser? -- sparti 13:34, 20. Mär. 2007 (CET)
thread_title:  Einleitung 

message: Ich gebe jetzt doch mal meinen Senf dazu.  Ich habe nichts gegen die Verwendung des Worts "Bucket", nur erklärt sollte es doch mal werden.  Ja, auch Nachschauen bei einem anderen Artikel wäre zumutbar, wenn es denn einen guten gäbe und er auch verlinkt wäre.  Ist er aber seit dem 2. Juni nicht mehr: 
Also bitte wenigstens einen kurzen Satz zur Erläuterung :-) --Rubik-wuerfel 17:45, 16. Jul. 2007 (CEST)
thread_title:  Bucket-Senf 

message: Guten Tag
Der Link auf die konkrete Implementation in C++ ist zwar eine feine Sache, aber vielleicht sollte man drüber nachdenken aus Höflichkeit erstmal auf die Website des Besitzers anstatt direkt auf das File zu linken.
: Auf der Webseite gibt es keinen Link auf die Datei. Ich habe den Link daher entfernt. -- sparti 14:40, 3. Dez. 2007 (CET)
thread_title:  Implementierungslink? 

message: 3 Dinge von mir (sorry, wenn ich das falsch mache, bin Wikineuling):
* ich fände es sinnvoll, wenn man gleich im Einleitungssatz erwähnt, dass der englische Begriff hier auch Hashmap wäre
* außerdem wird erst bei Kollisionen erwähnt, was genau ein  Bucket ist und wozu es benutzt wird. Aber schon vorher wird auf Buckets im Text eingegangen, was verwirrend sein kann.
* vor allem im Datenbankbereich ist ein großer Nachteil von Hashmaps, dass keine Bereichsanfragen möglich sind. Bei Bereichsanfragen sind daher bspw. B-Bäume klar vorzuziehen, wogegen Hashmaps riesige Vorteile bei Anfragen einzelner Werte haben.  (Der vorstehende, nicht signierte Beitrag stammt von 92.229.211.111 (Diskussion • Beiträge) 18:24, 26. Jul. 2008) (Diskussionsbeiträge bitte mit vier Tilden unterschreiben ~~~~)
:Hallo, danke für deine Vorschläg zur Verbesserung des Artikels. Meine Meinung dazu: 
:* Erwähnung von Hashmap finde ich nicht so arg sinnvoll, wenn es jemanden interessiert, wie der Begriff im Englischen heisst, so kann er ja auch über den interwikilink auf der linken Seite zum englischen Artikel gelangen, wo er die üblichen englischen Begriffe nachschlagen kann. Sinnvoll fände ich allerdings eine Weiterleitung von Hashmap zu diesen Artikel, so dass bei der Eingabe von Hashmap in das Suchfeld hierher geleitet wird (werds gleich mal erledigen). Bei den anderen zwei Punkten, gebe ich dir recht.
:* dort, wo die Buckets das erste mal auftauchen, werden sie eigentlich auch gleich implizit erklärt: als Stellen in der Tabelle, welche die Datenobjekte aufnehmen. Man könnte den Klammerzusatz "(Bucket genannt)" auch etwas abändern bspw. in "(Bucket genannt, englisch für ‘Eimer’, siehe auch Bucketsort)" oder gar aus dem Klammerzusatz einen weiteren ganzen Satz machen: "Diese Speicherorte werden Buckets genannt ..."
:* im dritten Punkt, stimme ich dir natürlich zu, die Erwähnung der Nachteile bei den Datenbanken kann im Abschnitt Anwendung erfolgen. Ansonsten kann ich nur sagen: sei mutig :-)  Viele Grüße -- Meph666  → post 20:15, 26. Jul. 2008 (CEST)
replies: text: Wenn Hashmap hierhin weiterleitet, dann muss das Wort „Hashmap“ auch im Text definiert werden. Anderenfalls erzeugst du nichts als Verwirrung bei unseren Lesern. --j ?! 20:41, 30. Jul. 2008 (CEST)
thread_title:  Hashmap 

message: Hallo Jpp,
wenn mich mein Sprachgefuehl nicht voellig taeuscht, dann ist
... durch den Hashwert festgelegte Stelle ...
die korrekte Schreibweise. Gruss -- sparti 17:21, 30. Nov. 2008 (CET)
replies: text: Schau dir mal mehr Text an: „wird an einer durch den Hashwert festgelegten Stelle … in der Tabelle gespeichert“. Ich denke also, dass dein Sprachgefühl dich hier völlig täuscht. :-) --j ?! 21:46, 30. Nov. 2008 (CET)
replies: text:  Ja, da hast du wohl doch recht :) -- sparti 00:04, 1. Dez. 2008 (CET)
thread_title:  Grammatik 

message: Hallo,
mein Professor verwendet statt den Begriff "Hashverfahren" den Begriff "Hashingverfahren". Bei der Suche habe ich den zweiten Begriff verwendet und hatte somit keine erfolgreiche Suche.
Könnt ihr vielleicht eine Weiterleitung für den zweiten Begriff "Hashingverfahren" einrichten? Wenn das nicht geht, dann bitte zumindest einen Verweis auf den richtigen Artikel der in der Suchanfrage erscheinen soll.
Vielen Dank im Voraus.
Gruß Alex
--Alex Kuhn 20:09, 26. Nov. 2009 (CET)
thread_title:  Suchbegriff - Weiterleitung 

message: Aktuell wird die Sondierung so definiert:
h_i(x) = \left(h(x) + (-1)^{i+1} \cdot \left\lceil\frac{i}{2}\right\rceil^2\right) \bmod~m
Einfacher könnte man dieses i+1 aber auch weglassen, ist imho etwas verwirrend, oder hab ich den Sinn dahinter übersehen? Zumindest liefert folgende Definition die gleichen Ergebnisse afaik:
h_i(x) = \left(h(x) + (-1)^{i} \cdot \left\lceil\frac{i}{2}\right\rceil^2\right) \bmod~m
-- DustyDingo 14:50, 13. Jan. 2010 (CET)
replies: text: der unterschied ist, dass es zurzeit ab i=1 mit nem positiven sprung anfängt... das dürfte performance-mäßig ohne belang aber didaktisch klüger sein... --Heimschützenzentrum (?) 09:41, 8. Mär. 2010 (CET)
thread_title:  Quadratische Sondierung 

message: Ich habe dieses Beispiel auskommentiert. Ein Telefonbuch ist das Paradebeispiel einer geordneten Liste. Das zu intepretieren als Hashtable mit 26 (+ einige Sonderzeichen) Werten in der Hasfunktion Left(Name,1) und erst danach einer Linear Geordneten Liste zur Kollisionsauflösung innerhalb des Anfangsbuchstabens ist mMn völlig unrealistisch und verwirrt den Leser nur. Insbesondere, da innerhalb des Artikels mehrfach auf den Nachteil der Hashtable (keine Ordnungsrelation auf den Daten) hingewiesen wird (und genau diese ist beim Telefonbuch gegeben). Wenn ein Beispiel gewünscht ist, wie wäre es dann mit "Liste von Absolventen nach Abschlussjahr". --LungFalang 07:08, 7. Mär. 2010 (CET)
thread_title:  Unpassendes Beispiel (Telefonbuch) 

message: Es gibt  ja auch Verfahren zum ordnungserhaltenden hashing. z.B. MOLPHE (Multidimensional order preserving linear hashing with partial expansions) .
Ich glaube die ursprüngliche Publikation ist "A Dynamic Hash File for Random and Sequential Accessing", Jack A. Orenstein, 
Diese Verfahren würden ja einen der größten Nachteile von Hashtabellen aufheben. Natürlich haben sie auch Nachteile, ich glaube sie erwarten dass man eben vorher weiß in welchem Wertebereich die Daten liegen, und dass sie dort wirklich etwa gleich verteilt sind. Dadurch sind sie halt für viele typische Anwendungen (z.B. Objekt IDs die durchnummeriert werden) letztlich doch nicht praktisch sinnvoll? Oder sind sie nur als on-disk-hashtables sinnvoll? Irgend so eine Einschränkung gibt es da schon, sonst würde man sie ja immer hernehmen ... --Chire 20:39, 7. Mai 2010 (CEST)
replies: text: wenn man die ordnung erhalten will, nimmt man da nich lieber b-trees, so dass die "ordnungserhaltenden Hash maps" vllt nicht so relevant oder nur theoretisch interessant sind? die b-trees sind im aufwand wohl auch nich schlimmer als "Ordnungserhaltendes Hashing"... <-- nur geraten... :-) // ansonsten mal in der WP:AU fragen? oder im Portal:informatik? --Heimschützenzentrum (?) 21:12, 7. Mai 2010 (CEST)
replies: text:  Weil suche in einem B-Baum halt trotzdem O(log n) ist, und nicht O(1) wie in einem Hash? Das gilt auch für ordnungserhaltende hashes - zumindest wenn entsprechende Voraussetzungen erfüllt sind. Sprich: wenn man diese Voraussetzungen schaffen kann (z.B. auf statischen Daten durch Anwendung eines Quantilverfahrens), ist das durchaus attraktiv. --Chire 23:41, 7. Mai 2010 (CEST)
replies: text:  ja schon... aber wenn diese Voraussetzungen nicht erfüllt sind, dann wirds wohl recht schlimm mit der komplexitätsklasse (linear oder schlimmer, könnte ich mir denken)... vom speicheraufwand gar nicht zu reden... --Heimschützenzentrum (?) 00:42, 8. Mai 2010 (CEST)

text: Naja, es wird als Nachteil aufgeführt das Hashtabellen nicht ordnungserhaltend sind. Aber offenbar gibt es halt auch ordnungserhaltende. Der Artikel sollte in der Richtung ergänz werden. Aber ich bin selbst gerade nicht in dem Thema so weit drin, dass ich das gut machen könnte. --Chire 01:43, 8. Mai 2010 (CEST)

text: hab es aber noch mal angepasst, das war etwas zu persönlich/wertend IMHO: "wenn man keinen B-Baum mag" bei Hashfunktion ist eine nicht gerade in Wikipedia passende Formulierung ... P.S. in Datenbanken verwendet man auch keinen B-Baum, sondern eben meist eher einen B+-Baum, und siehe da, was er im Wesentlichen verbessert ist der sortierte Zugriff. Und ich vermute fast, dass du eigentlich einen Binärer Suchbaum gemeint hattest. Das wäre für in-memory durchaus eine passende Alternative (mit eben O(log n) statt O(1) bei lookups) --Chire 18:56, 8. Mai 2010 (CEST)
thread_title:  Ordnungserhaltendes Hashing 

message: Vielleicht als kleine Inspiration:
Anmerkungen zum Abschnitt "Hashverfahren"
Bisschen irreführend. Es ist nicht sofort klar, dass mit Objekt, Datenobjekt und Zielobjekt das Gleiche gemeint ist. Und später wird nur noch von Zieldaten gesprochen. Vielleicht kann man das etwas vereinheitlichen?
Anmerkungen zum Abschnitt "Der Algorithmus"
Da steht:
Beim Hashverfahren werden die Zieldaten (Was sind Zieldaten? Objekte, Datenobjekte oder ist damit das Zielobjekt gemeint?) in einer Hashtabelle (Wie sieht das aus?) gespeichert. Eine Hashfunktion berechnet zu jedem Datenobjekt einen Hashwert, der als Index in der Tabelle verwendet wird (und somit die Position des Objektes innerhalb der Tabelle angibt). Zum Berechnen dieses Hashwertes wird ein Schlüssel benötigt (Was für ein Schlüssel? Wo kommt der her? Wird der extra erstellt?), der dieses Objekt eindeutig identifiziert. Dieser Schlüssel wird von der Hashfunktion zum Berechnen des Hashwertes verwendet. Das Datenobjekt wird an einer durch den Hashwert festgelegten Stelle (Bucket genannt) in der Tabelle gespeichert. (Den Teil "(Bucket genannt)" würde ich hinter das Wort "Tabelle" setzen) vg (nicht signierter Beitrag von 95.116.183.58 (Diskussion) 07:34, 7. Jan. 2011 (CET)
thread_title:  Sonstiges 

message: Habe den Baustein 'Belege fehlen' entfernt, da inzwischen ja ordentlich Literatur angegeben ist und ich keine Stellen finden konnten, die Einzelnachweise benötigen. Falls jemand noch etwas finden sollte, bitte den Baustein nur wieder reinsetzen, wenn er hier konkret begründet wird. Oder am besten direkt nachtragen ... --Gms 14:17, 22. Jan. 2012 (CET)
thread_title:  Belege 

message: In dem Artikel wird zwar mehrfach erwähnt daß, aber nicht erklärt, warum ein Objekt einer Hashtabelle schneller zu finden ist, als in einer Tabelle mit gleichförmit aufsteigenden Werten/Zahlen. --Katzili (Diskussion) 01:04, 6. Okt. 2012 (CEST)
replies: text: ziemlich am Anfang: Hashtabelle#Hashverfahren („Dadurch erübrigt sich das Durchsuchen vieler Datenobjekte [...].“)... reicht doch, oda? --Heimschützenzentrum (?) 07:48, 6. Okt. 2012 (CEST)
thread_title:  Geschwindigkeitsvorteil II 

message: Was versteht man genau unter sondieren? Der Begriff wird benutzt, ohne ihn zu definieren. Die Wikipedia Seite zu Sondieren sagt nur "in der Informatik: Funktion im Zusammenhang mit Hashtabellen" --Bomberzocker (Diskussion) 22:17, 9. Okt. 2017 (CEST)
thread_title:  Sondieren