Search (8 results, page 1 of 1)

  • × theme_ss:"Retrievalalgorithmen"
  • × language_ss:"d"
  1. Fuhr, N.: Ranking-Experimente mit gewichteter Indexierung (1986) 0.02 
    0.018705536 = product of:
  0.03741107 = sum of:
    0.03741107 = product of:
      0.07482214 = sum of:
        0.07482214 = weight(_text_:22 in 58) [ClassicSimilarity], result of:
          0.07482214 = score(doc=58,freq=2.0), product of:
            0.1611569 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.04602077 = queryNorm
            0.46428138 = fieldWeight in 58, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.09375 = fieldNorm(doc=58)
      0.5 = coord(1/2)
  0.5 = coord(1/2)
    Date
    14. 6.2015 22:12:44
  2. Fuhr, N.: Rankingexperimente mit gewichteter Indexierung (1986) 0.02 
    0.018705536 = product of:
  0.03741107 = sum of:
    0.03741107 = product of:
      0.07482214 = sum of:
        0.07482214 = weight(_text_:22 in 2051) [ClassicSimilarity], result of:
          0.07482214 = score(doc=2051,freq=2.0), product of:
            0.1611569 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.04602077 = queryNorm
            0.46428138 = fieldWeight in 2051, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.09375 = fieldNorm(doc=2051)
      0.5 = coord(1/2)
  0.5 = coord(1/2)
    Date
    14. 6.2015 22:12:56
  3. Tober, M.; Hennig, L.; Furch, D.: SEO Ranking-Faktoren und Rang-Korrelationen 2014 : Google Deutschland (2014) 0.01 
    0.012470358 = product of:
  0.024940716 = sum of:
    0.024940716 = product of:
      0.049881432 = sum of:
        0.049881432 = weight(_text_:22 in 1484) [ClassicSimilarity], result of:
          0.049881432 = score(doc=1484,freq=2.0), product of:
            0.1611569 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.04602077 = queryNorm
            0.30952093 = fieldWeight in 1484, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.0625 = fieldNorm(doc=1484)
      0.5 = coord(1/2)
  0.5 = coord(1/2)
    Date
    13. 9.2014 14:45:22
  4. Kanaeva, Z.: Ranking: Google und CiteSeer (2005) 0.01 
    0.010911563 = product of:
  0.021823127 = sum of:
    0.021823127 = product of:
      0.043646254 = sum of:
        0.043646254 = weight(_text_:22 in 3276) [ClassicSimilarity], result of:
          0.043646254 = score(doc=3276,freq=2.0), product of:
            0.1611569 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.04602077 = queryNorm
            0.2708308 = fieldWeight in 3276, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.0546875 = fieldNorm(doc=3276)
      0.5 = coord(1/2)
  0.5 = coord(1/2)
    Date
    20. 3.2005 16:23:22
  5. Koopman, R.: ¬Ein OPAC mit Gewichtungsalgorithmen : Der PICA Micro OPC (1996) 0.00 
    0.0026262498 = product of:
  0.0052524996 = sum of:
    0.0052524996 = product of:
      0.010504999 = sum of:
        0.010504999 = weight(_text_:e in 4114) [ClassicSimilarity], result of:
          0.010504999 = score(doc=4114,freq=2.0), product of:
            0.06614887 = queryWeight, product of:
              1.43737 = idf(docFreq=28552, maxDocs=44218)
              0.04602077 = queryNorm
            0.15880844 = fieldWeight in 4114, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              1.43737 = idf(docFreq=28552, maxDocs=44218)
              0.078125 = fieldNorm(doc=4114)
      0.5 = coord(1/2)
  0.5 = coord(1/2)
    Source
    Zukunft der Sacherschließung im OPAC: Vorträge des 2. Düsseldorfer OPAC-Kolloquiums am 21. Juni 1995. Hrsg.: E. Niggemann u. K. Lepsky
  6. Lanvent, A.: Licht im Daten Chaos (2004) 0.00 
    0.0014856312 = product of:
  0.0029712624 = sum of:
    0.0029712624 = product of:
      0.005942525 = sum of:
        0.005942525 = weight(_text_:e in 2806) [ClassicSimilarity], result of:
          0.005942525 = score(doc=2806,freq=4.0), product of:
            0.06614887 = queryWeight, product of:
              1.43737 = idf(docFreq=28552, maxDocs=44218)
              0.04602077 = queryNorm
            0.08983562 = fieldWeight in 2806, product of:
              2.0 = tf(freq=4.0), with freq of:
                4.0 = termFreq=4.0
              1.43737 = idf(docFreq=28552, maxDocs=44218)
              0.03125 = fieldNorm(doc=2806)
      0.5 = coord(1/2)
  0.5 = coord(1/2)
    Abstract
    Spätestens bei der Suche nach E-Mails, PDF-Dokumenten oder Bildern mit Texten kapituliert die Windows-Suche. Vier von neun Desktop-Suchtools finden dagegen beinahe jede verborgene Datei.
    Content
    "Bitte suchen Sie alle Unterlagen, die im PC zum Ibelshäuser-Vertrag in Sprockhövel gespeichert sind. Finden Sie alles, was wir haben - Dokumente, Tabellen, Präsentationen, Scans, E-Mails. Und erledigen Sie das gleich! « Wer diese Aufgabe an das Windows-eigene Suchmodul vergibt, wird zwangsläufig enttäuscht. Denn das Betriebssystem beherrscht weder die formatübergreifende Recherche noch die Kontextsuche, die für solche komplexen Aufträge nötig sind. Professionelle Desktop-Suchmaschinen erledigen Aufgaben dieser Art jedoch im Handumdrehen - genauer gesagt in einer einzigen Sekunde. Spitzenprogramme wie Global Brain benötigen dafür nicht einmal umfangreiche Abfrageformulare. Es genügt, einen Satz im Eingabefeld zu formulieren, der das Thema der gewünschten Dokumente eingrenzt. Dabei suchen die Programme über alle Laufwerke, die sich auf dem System einbinden lassen - also auch im Netzwerk-Ordner (Shared Folder), sofern dieser freigegeben wurde. Allen Testkandidaten - mit Ausnahme von Search 32 - gemeinsam ist, dass sie weitaus bessere Rechercheergebnisse abliefern als Windows, deutlich schneller arbeiten und meist auch in den Online-Postfächern stöbern. Wer schon öfter vergeblich über die Windows-Suche nach wichtigen Dokumenten gefahndet hat, kommt angesichts der Qualität der Search-Engines kaum mehr um die Anschaffung eines Desktop-Suchtools herum. Aber Microsoft will nachbessern. Für den Windows-XP-Nachfolger Longhorn wirbt der Hersteller vor allem mit dem Hinweis auf das neue Dateisystem WinFS, das sämtliche Files auf der Festplatte über Meta-Tags indiziert und dem Anwender damit lange Suchläufe erspart. So sollen sich anders als bei Windows XP alle Dateien zu bestimmten Themen in wenigen Sekunden auflisten lassen - unabhängig vom Format und vom physikalischen Speicherort der Files. Für die Recherche selbst ist dann weder der Dateiname noch das Erstelldatum ausschlaggebend. Anhand der kontextsensitiven Suche von WinFS kann der Anwender einfach einen Suchbefehl wie »Vertragsabschluss mit Firma XYZ, Neunkirchen/Saar« eingeben, der dann ohne Umwege zum Ziel führt."
  7. Lanvent, A.: Praxis - Windows-Suche und Indexdienst : Auch Windows kann bei der Suche den Turbo einlegen: mit dem Indexdienst (2004) 0.00 
    0.0013131249 = product of:
  0.0026262498 = sum of:
    0.0026262498 = product of:
      0.0052524996 = sum of:
        0.0052524996 = weight(_text_:e in 3316) [ClassicSimilarity], result of:
          0.0052524996 = score(doc=3316,freq=2.0), product of:
            0.06614887 = queryWeight, product of:
              1.43737 = idf(docFreq=28552, maxDocs=44218)
              0.04602077 = queryNorm
            0.07940422 = fieldWeight in 3316, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              1.43737 = idf(docFreq=28552, maxDocs=44218)
              0.0390625 = fieldNorm(doc=3316)
      0.5 = coord(1/2)
  0.5 = coord(1/2)
    Content
    "Für eine 4-GByte-Festplatte mit mehreren Partitionen sucht Windows XP im Volltextmodus weit über zwei Stunden. Der Indexdienst verkürzt diese Recherchedauer drastisch um mehr als eine Stunde. Im Gegensatz zu den Indizes der kommerziellen Suchwerkzeuge erfasst der Windows-Indexdienst nur Text-, HTML- und OfficeDateien über entsprechend integrierte Dokumentfilter. Da er weder ZIP-Files noch PDFs erkennt und auch keine E-Mails scannt, ist er mit komplexen Anfragen schnell überfordert. Standardmäßig ist der Indexdienst zwar installiert, aber nicht aktiviert. Das erledigt der Anwender über Start/Arbeitsplatz und den Befehl Verwalten aus dem Kontextmenü. In der Computerverwaltung aktiviert der Benutzer den Eintrag Indexdienst und wählt Starten aus dem Kontextmenü. Die zu indizierenden Elemente verwaltet Windows über so genannte Kataloge, mit deren Hilfe der User bestimmt, welche Dateitypen aus welchen Ordnern indiziert werden sollen. Zwar kann der Anwender neben dem Katalog System weitere Kataloge einrichten. Ausreichend ist es aber in den meisten Fällen, dem Katalog System weitere Indizierungsordner über die Befehle Neu/Verzeichnis hinzuzufügen. Klickt der Benutzer dann einen der Indizierungsordner mit der rechten Maustaste an und wählt Alle Tasks/Erneut prüfen (Vollständig), beginnt der mitunter langwierige Indizierungsprozess. Über den Eigenschaften-Dialog lässt sich allerdings der Leistungsverbrauch drosseln. Eine inkrementelle Indizierung, bei der Windows nur neue Elemente im jeweiligen Verzeichnis unter die Lupe nimmt, erreicht der Nutzer über Alle Tasks/Erneut prüfen (inkrementell). Einschalten lässt sich der Indexdienst auch über die Eigenschaften eines Ordners und den Befehl Erweitert/ln-halt für schnelle Dateisuche indizieren. Auskunft über die dem Indexdienst zugeordneten Ordner und Laufwerke erhalten Sie, wenn Sie die WindowsSuche starten und Weitere Optionen/ Andere Suchoptionen/Bevorzugte Einstellungen ändern/Indexdienst verwenden anklicken."
  8. Ackermann, J.: Knuth-Morris-Pratt (2005) 0.00 
    0.0010504998 = product of:
  0.0021009997 = sum of:
    0.0021009997 = product of:
      0.0042019994 = sum of:
        0.0042019994 = weight(_text_:e in 865) [ClassicSimilarity], result of:
          0.0042019994 = score(doc=865,freq=2.0), product of:
            0.06614887 = queryWeight, product of:
              1.43737 = idf(docFreq=28552, maxDocs=44218)
              0.04602077 = queryNorm
            0.063523374 = fieldWeight in 865, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              1.43737 = idf(docFreq=28552, maxDocs=44218)
              0.03125 = fieldNorm(doc=865)
      0.5 = coord(1/2)
  0.5 = coord(1/2)
    Abstract
    Im Rahmen des Seminars Suchmaschinen und Suchalgorithmen beschäftigt sich diese Arbeit mit dem Auffinden bestimmter Wörter oder Muster in Texten. Der Begriff "Text" wird hier in einem sehr allgemeinen Sinne als strukturierte Folge beliebiger Länge von Zeichen aus einem endlichen Alphabet verstanden. Somit fällt unter diesen Bereich ganz allgemein die Suche nach einem Muster in einer Sequenz von Zeichen. Beispiele hierfür sind neben der Suche von Wörtern in "literarischen" Texten, z.B. das Finden von Pixelfolgen in Bildern oder gar das Finden von Mustern in DNS-Strängen. Das Anwendungsgebiet für eine solche Suche ist weit gefächert. Man denke hier allein an Texteditoren, Literaturdatenbanken, digitale Lexika oder die besagte DNADatenbank. Betrachtet man allein das 1989 publizierte Oxford English Dictionary mit seinen etwa 616500 definierten Stichworten auf gedruckten 21728 Seiten, so gilt es, einen möglichst effizienten Algorithmus für die Suche in Texten zu nutzen. Der in der Arbeit zugrunde liegende Datentyp ist vom Typ String (Zeichenkette), wobei hier offen gelassen wird, wie der Datentyp programmtechnisch realisiert wird. Algorithmen zur Verarbeitung von Zeichenketten (string processing) umfassen ein bestimmtes Spektrum an Anwendungsgebieten [Ot96, S.617 f.], wie z.B. das Komprimieren, das Verschlüssen, das Analysieren (parsen), das Übersetzen von Texten sowie das Suchen in Texten, welches Thema dieses Seminars ist. Im Rahmen dieser Arbeit wird der Knuth-Morris-Pratt Algorithmus vorgestellt, der wie der ebenfalls in diesem Seminar vorgestellte Boyer-Moore Algorithmus einen effizienten Suchalgorithmus darstellt. Dabei soll ein gegebenes Suchwort oder Muster (pattern) in einer gegeben Zeichenkette erkannt werden (pattern matching). Gesucht werden dabei ein oder mehrere Vorkommen eines bestimmten Suchwortes (exact pattern matching). Der Knuth-Morris-Pratt Algorithmus wurde erstmals 1974 als Institutbericht der Stanford University beschrieben und erschien 1977 in der Fachzeitschrift Journal of Computing unter dem Titel "Fast Pattern Matching in Strings" [Kn77]. Der Algorithmus beschreibt eine Suche in Zeichenketten mit linearer Laufzeit. Der Name des Algorithmus setzt sich aus den Entwicklern des Algorithmus Donald E. Knuth, James H. Morris und Vaughan R. Pratt zusammen.

Authors

Years

Types

Themes