Hi,
Da bin ich halt egoistisch, zudem - ich bin sicher, daß Twilo sich das nicht angeschaut hätte, wenn das Posting an der moralisch richtigen Stelle gestanden hätte.
Und so hätte ich den Fehler nicht bemerkt.Ich habe ihn auch bemerkt, keine Angst.
Beruhigend - ich habe 20 verschiedene Test gemacht, und habe das einfachste übersehen. Manchmal sehen halt viele Leute mehr als man selbst mit hunderten von verschiedenen Denkansätzen.
Und ich schätze, wenn ich den fertigen Alg den Kiddies in meinem Forum gebe, dann kommen die auf Ideen, an die ich mein Lebtag nicht gedacht hätte.
Und warum hast Du nicht einfach direkt ein Inlineelement genommen?
Auch da hätte ich die CSS-Eigenschaften verändert. Bei beiden die Farbe und beim Ins hätte ich das Underline rausgenommen.
Nichts gegen kreativen Umgang mit Technik, wahrlich nicht, aber eine derartige Argumentation gegen die Benutzung eines Inlineelementes finde ich schon etwas ... ähm ... merkwürdig.
Aber es sei einmal darauf hingewiesen: Du postest in einem Forum, das sich mit HTML beschäftigt, da sind solche Beckmessereien durchaus an der Tagesordnung.
Beckmessereien ? (Error: unbekannter Ausdruck)
Mit Gewohnheiten bricht man schwer. Bei mir sind DIV mit anschliessender Style-Vergewaltigung zur Normalfall geworden :-(
reguläre Ausdrücke brauchen länger - ich vermeide sie halt, wo ich kann.
Das ist Microoptimierung und zu meiden.
Das wird relevant, wenn du Texte mit über 1000 Smilies in JS formatierst. Und ich habe anscheinend eine ganze Menge solcher User.
Es geht hier auch um Vorschau und Korrektur.
Ich speichere ja nicht den fertig formatierten Text ab, sondern den Text mit den Tags. Aus dem ganz einfachen Grund, damit man den Text jederzeit editieren kann. Das bedeutet aber auch, daß jedesmal der Text zur Ansicht aufbereitet werden muß.
Und dann werden solche Micro-Optimierungen interessant.
Der Algorithmus war nicht falsch, die Ausgabe hat etwas zu früh abgebrochen.
Ist aber auch 'ne schwache Ausrede ;-)
Noch schwächer ist, daß ich den Testfall übersehen habe.
Wo ich doch noch nicht mal eine einfache Prüfsumme schreiben kann.
Aber für sowas habe ich zum Glück die Argusaugen der Forummitglieder.
Die Komplexität wächst mit dem Faktor O(nn) = Feststellen der Worthäufigkeit, das Zuordnen mit dem Faktor O(n).
Ich glaube nicht, daß es einen Alg unter O(nn) gibt.Das mußt Du nicht glauben, das kannst Du sogar beweisen.
Müsste aber mal testen, was du mir genannt hast.
Das war nur zur einfachen statistischen Feststellung, wieviel sich geändert hat, nicht was und wo genau.
Die punctsum/whitesum Methoden benötigen O(n), die Levenshtein Methode O(n^2).
Suche noch immer eine Website für die punctsum/whitesum Methoden, auf der ich den Algorithmus verstehe :-(
Für Levenshtein habe ich folgendes gefunden:
http://www.levenshtein.de/
Soweit ich sehe ist Levenshtein dem Stepping-Stone (Umladeproblem bzw. der Zuordnungsmatrix) sehr ähnlich (Dazu habe ich mit Google nur PDFs gefunden).
Die Qualität einer Änderung in Levenshtein ähnelt sehr dem, was ich als Hamming-Abstand kenne
http://de.wikipedia.org/wiki/Hammingdistanz
Trotz genauerem Durchlesen von Levenshtein habe ich noch keine Idee, wie ich Levenshtein nutzen kann, um Änderungen von zwei Texten darzustellen. Vorallem habe ich das dumpfe Gefühl, daß Levenshtein zwei Texte absolut vergleicht, bei dem Einfügen eines einzelnen Wortes am Anfang würde der Levenshtein-Abstand sich deutlich erhöhen (um jeweils 1 für jeden diagonalen Sprung - was allen folgenden Wörtern entspricht).
Klar ! - eine Verschiebung ändert den Sinn. Also sollte man sie schon feststellen. Wichtiger ist aber noch, daß man gelöschte und hinzugekommene Wörter unabhängig von der Verschiebung erkennt.
Warum ist das wichtiger? Nein, ernsthafte Frage: warum meinst Du, das es wichtiger ist?
Reine Intuition/Überzeugung:
Wenn ein Absatz verschoben wird, dann ist die Wahrscheinlichkeit eines groben Sinnfehlers des ganzen Textes geringer als beim Löschen oder Einfügen eines Wortes.
Wenn es bösartige User gibt, dann glaube ich, daß sie eher Löschen und Hinzufügen.
Und dann noch das eingestehen einer praktischen Schwäche:
Ich habe mit der Darstellung einer Verschiebung (bzw. wie man die Änderung deutlich machen kann) ein wenig experimentiert.
In 'der Glocke' habe ich drei Absätze an eine andere Stelle geschoben.
Alles was ich benutzt habe, war irgendwie Mist als Darstellung.
Selbst eine 'erase' und 'copy' Markierung der einzelnen Stellen sah nichts aus und half nichts (bei drei Verschiebungen).
Meist geht dabei die Übersicht für die Änderungen im verschobenen Abschnitt verloren, und das halte ich für fatal, denn auf diese Weise können wirklich falsche Sachen sich einmogeln (siehe oben - meine Überzeugung).
Letztlich muß man sich den Text sowieso nochmals durchlesen, um zu sehen, ob er iO ist.
Deshalb bin ich ja auch der Meinung, das für die Feststellung des Änderungsmaßes einfache statistische Methoden vollkommen ausreichen.
Sowas wie Summe der absoluten Differenzen von gleichen Worten ?
Mir geht es um eine Erleichterung beim Auffinden der relevanten Stellen. Wenn man zwei Texte mit 3000 Worten abgleicht, in dem nur ein Schreibfehler verbessert wurde, dann braucht man schon sehr viel Konzentration - finde ich.
Dieser Algorithmus soll ja dazu dienen, um letztlich Änderungen zu überwachen.
Wenn Du die Änderungen mit Javascript aufzeigen willst mußt Du mindestens zwei Versionen laden. Bandbreite ist heutzutage das einzige, das wirklich noch kostet deshalb würde ich empfehlen sowas den Server machen zu lassen.
Was das statische Darstellen von Änderungen angeht, da gebe ich dir Recht.
Wobei, wenn du die Originalversion und die Änderungsdarstellung überträgst, oder die Originalversion und die geänderte Version, da glaube ich, komme ich im zweiten Fall günstiger.
Meine Idee ist, daß ich dem Nutzer eine Möglichkeit geben will, Änderungen der Änderungen zu machen. Letztlich ist das eine Art Korrekturüberwachung.
Dazu hätte ich schon gerne eine dynamische Sofortdarstellung beim User:
Dem User liegt ein Text vor, den er noch für i.O. hält, und ein Text (den er editieren kann), der nicht i.O. ist. Der User kann ziemlich einfach erkennen, wo er was abändern muß, um das Original wieder herzustellen.
Wobei ich jetzt mal von folgendem Fall ausgehe:
1. Originalversion (hohe Qualität)
2. unfreundlicher User verschmutzt die Version und löscht wichtige Informationen
3. ein weiterer User bringt sinnvolle Infos ein
Die Originalversion könnte wieder hergestellt werden, aber die Infos aus 3 wären verloren.
Wenn jetzt 1 und 3 verglichen werden, dann sieht man von beiden Usern die Änderungen. Wenn man jetzt das Ganze korrigiert, dann hilft es (nach meiner Meinung) enorm, wenn man das Ergebniss der Korrektur sofort anschauen kann.
Meine Idee mit den Ankerpunkten kommt vom einem Alg namens SIFT (Scalable Invariant Feature Transform), der beeindruckend gut gleiche Bildteile auf verschiedenen Bildern erkennt.
Naja, mich beeindruckt da nichts, das funktioniert nicht wesentlich besser, als vor 10 Jahren. Das finde ich schon etwas enttäuschend.
Apropos Bilder: wie vergleichst Du die in Javascript?
JavaScript kann nicht auf Infos aus Grafiken zugreifen...
Es gibt da ein Programm namens Autopano, daß letztlich erst Sinn macht mit dem Photo-Stitcher bzw. Panorama-Programm Hugin.
Autopano sucht erstmal gemeinsame deutliche Bildteile aus mehreren Bildern, um dann sukzessive undeutlichere Bildteile zu vergleichen.
Eine ziemlich teure Alarmglocke.
Aber gut, hast Du ja schon, bräuchtest Du nicht noch extra zu erzeugen.
Die Infos würden bei jedem Submit durch den JS erzeugt (falls sie nicht schon vorliegen).
Zu jeder Version gäbe es eine Änderungsqualität (Ankerpunkte gemessen an der Gesamtwortzahl des neuen Textes).
Wie gut das in der Praxis funktioniert und wie aussagekräftig dieser Wert ist wird sich zeigen müssen.
Geht so, ich habe Schillers Glocke und die Bürgschaft getestet, auch gegeneinander, und es hat jeweils ne Sekunde gedauert, bis das Ergebniss vorlag.
In Javascript auf dem Clienten, ja. Was ist mit Serverlast?
???
Dürfte dabei bei Null liegen.
Oder meinst du damit, ich sollte mal den Algorithmus auch in PHP schreiben und dann vergleichen ?
hasta luego,
Mathias