Diskussion:Regulärer Ausdruck

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Regulärer Ausdruck“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 30 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Archiv

Archivierte Diskussionen befinden sich auf /Archiv. -- seth 14:20, 1. Dez. 2008 (CET)

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich  ✉  16:53, 6. Mär. 2022 (CET)

theoretische informatik vs. anwendung (software)

Aufteilung?

Der Artikel krankt so ein bißchen am Aufbau. Ich denke, man sollte das mal etwas umschreiben und zuerst erklären, was ein regulärer Ausdruck (in der Theoretischen Informatik) ist und anschließend die Syntax der verschiedenen Programme erklären. Meinungen? -- MlaWU 14:44, 23. Mär 2005 (CET)

tu das! ;-) --seth 01:10, 30. Mär 2005 (CEST)

Au ja! -- D. Dÿsentrieb ⇌ 02:07, 30. Mär 2005 (CEST)

ich probiere es mal -- MlaWU 16:20, 9. Mai 2005 (CEST)

Genau das habe ich auch gedacht. Reguläre Ausdrücke in der Chomsky-Hierarchie werden ja ein wenig einfacher dargestellt als die bekannte Regex-Syntax: 1. Literale, 2. Konkatenation, 3. Stern, 4. Vereinigung und sonst nichts! Die gängigen Regex-Syntaxen enthalten dagegen oft Erweiterungen, die sich streng genommen gar nicht mehr der Definition regulärer Ausdrücke ableiten lassen. Dies sollte streng getrennt werden. Ich habe es einmal ansatzweise versucht, das sollte aber jemand ergänzen, der das besser kann! (Ausserdem habe ich den auskommentierten Block "theoretische Grundlagen" wieder reingenommen - keine Ahnung, warum der auskommentiert war). -- Daniel Paul Schreber 19:39, 8. Feb 2006 (CET)

Ich hatte da mal was angefangen zu schreiben, war damit aber nicht zufrieden. -- MlaWU 14:17, 11. Feb 2006 (CET)

Insbesondere fand ich einen Absatz zum Syntax nicht sinnvoll, solange da nichts zur Semantik des ganzen steht. -- MlaWU 14:51, 11. Feb 2006 (CET)

Ich find das mit der Syntax o.k. für den Anfang. Es ersetzt noch keine Einführung in das Thema, aber da müsste neben der Semantik dann auch noch was über endliche Automaten, über rechtslineare Grammatiken, über das Pumping-Lemma usw. usw. stehen. Macht erst mal nichts, wenn das fehlt: wichtig ist, dass man hier schon einmal erkennen kann, dass das eine sehr viel eingeschränktere Syntax ist, als die von grep, Perl etc, und dass es einen anderen Zweck hat. -- Daniel Paul Schreber 22:50, 11. Feb 2006 (CET)

Eigentlich muß bei der Semantik nur was zu Sprachen stehen. -- MlaWU 21:33, 12. Feb 2006 (CET)

Bitte: Wir haben hier eine Enzyklopädie vorliegen und kein Handbuch/Nachschlagewerk der theoretischen Informatik! Auch muss sich hier kein "Prof" mit einer Veröffentlichung profilieren, die nur Eingeweihte verstehen.

Der Schwierigkeitsgrad sollte sich deshalb in der Art staffeln, dass der Leser vor allem in den ersten Abschnitten des Artikels in die Materie einlesen und ein-denken kann. Ich würde einen Spezialisten bitten, einige entsprechende Kapitel zu verfassen. Die hier ziemlich zu Beginn dargestellte Theorie, die meist in Form von Sonderzeichen und mathematischen Gleichungen formuliert ist, gehört eher ans Ende für die Leser, die mehr als solches Grundwissen erlangen möchten, um was es sich bei dem Begriff (wir haben ja eine Enzyklopädie vorliegen!) handelt. Frank Herbrand (Diskussion) 22:31, 6. Feb. 2014 (CET)

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich  ✉  16:53, 6. Mär. 2022 (CET)

Reguläre Sprache nochmals

Ich finde (bei aller Liebe zu Anwendungen) dass es nicht angeht, Reguläre Ausdrücke ohne Bezug - ja sogar in Abrenzung (s. Ende Abschnitt Regulärer Ausdruck#Gruppierung mit runden Klammern) - zu Regulären Sprachen darzustellen. Die aus regulären Ausdrücken inspierierten Anwendungen (Suchen, Suchen und Ersetzten) gehen nun eben mal gerade dort über die "theoretischen Grenzen" hinaus, wo sie ihre größte Nützlichkeit entfalten. Irgendwie müssen wir das hier zusammenbringen, oder etwa in einer Begriffsklärung? --Peu 22:02, 16. Okt. 2006 (CEST)

Sollte man nicht auch erstmal erklären, wie die Syntax eines regulären Ausdrucks in der theoretischen Informatik aussieht? Der Artikel bezieht sich meines Erachtens nur auf einen Spezialfall!

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich  ✉  16:53, 6. Mär. 2022 (CET)

Es gibt mehr als RegExp nach Perl-Syntax

Man sollte nicht vergessen, dass es auch noch andere Syntax-Formen von regulären Ausdrücken gibt, die nichts mit der im Artikel beschriebenden zu tun hat. So sind die Wildcards * und ? von DOS oder % und _ in SQL-LIKE reguläre Ausdrücke. Vor allem sind Sie dem geneigten Leser vielleicht sogar bekannter ;-) Der Artikel liest sich für mich so, als würde es nur die eine beschriebene Syntax einen Regulären Ausdruck ausmachen. -Arittner 20:20, 9. Nov 2005 (CET)

du verwechselst wildcards mit regulaeren ausdruecken. (siehe auch [1]) --seth 20:54, 9. Nov 2005 (CET)

Die DOS Wildcards und die SQL Syntax sind ebenfalls Möglichkeiten, reguläre Sprachen zu definieren. Den Begriff "Regulärer Ausdruck" kenne ich aber nur für das, was Perl und Grep verwenden, bzw, etwas formaler, was man in der Informatik benutzt (also z.B. a^*b² oder sowas). Mit letzterer Syntax lassen sich aber durchaus auch sprachen definieren, die nicht regulär sind (z.B. aⁿbⁿ). -- D. Dÿsentrieb ⇌ 23:13, 9. Nov 2005 (CET)

wie definiert man mit dos-wildcards eine regulaere sprache?--seth 23:58, 9 November 2005 (CET)

a* (DOS, syntax) ist Regulär (entspricht a.* in Perl-Syntax - dabei wird ein endliches Alphabet als Grundmenge vorausgesetzt). Man kann aber nicht jede Reguläre Sprache mit solchen Wildcards beschreiben, sie sind weniger mächtig als "echte" reguläre Ausdrücke. Oder was genau ist deine Frage? -- D. Dÿsentrieb ⇌ 00:25, 10 November 2005 (CET)

Ok, nochmal genauer: jedes "Muster", das Wörter akzeptiert (oder generiert, je nach Perspektieve) definiert eine Sprache. Alle Muster, die sich mit regulären Ausdrücken (Perl Style) definieren lassen, definieren reguläre Sprachen (saher der Name), und alle regulären Sprachen lassen sich durch solche Ausdrücke definieren. Alle Muster, die sich mit DOS- oder LIKE Syntax definieren lassen, definieren ebenfalls reguläre Sprachen, aber nicht alle regulären Sprachen lassen sich durch DOS-Wildcards oder LIKE Muster definieren. -- D. Dÿsentrieb ⇌ 00:31, 10. Nov 2005 (CET)

ok, ich hatte dich zunaechst missverstanden (obwohl du's gar nicht falsch formuliert hast). sorry, war ne doofe frage. --seth 00:45, 10. Nov 2005 (CET)

@seth - nein verwechseln tu ich da nichts. Reguläre Ausdrücke und Reguläre Sprachen in der theoretischen Informatik definieren keine spezifische Syntax. Sie stellen (wie der Artikel ja schon richtig anfängt) formale Sprachen dar. Das die Bezeichnung "Regulärer Ausdruck" so stark von der Perl Syntax gefärbt ist, so dass es immer wieder gleich gesetzt wird, gebe ich ja gerne zu - bemängele das aber auch. Nun sind die Wildcards in DOS mit * und ? ganz sicher eine formale Sprache, um Zeichenkettenmuster zu beschreiben. Und die formale Sprache der Wildcards sind auch ohne Zweifel vom Typ 3 in der Chomsky-Hierarchie. Und dort das Zitat: Reguläre Sprachen können alternativ auch durch reguläre Ausdrücke beschrieben werden und die regulären Sprachen sind genau die Sprachen, die von endlichen Automaten erkannt werden können. Sie werden gewöhnlich genutzt, um Suchmuster oder die lexikalische Struktur von Programmiersprachen zu definieren.

@Dÿsentrieb - den Umkehrschluss, dass alle Untermengen von Perl RegExp Reguläre Ausdrücke sein müssen ist nicht ganz richtig, denn gerade aktuelle Perl Ausdrücke erlauben Rückwärtsreferenzen. Damit ist Perl-Regexp Grammatik nicht mehr eindeutig rechtsregulär oder linksregulär. Damit müssen auch Untermengen von Perl RegExp keinen reine Reguläre Ausdrücke sein. Davon unabhängig, wollte ich eigentlich nur sagen, dass Perl RegExp nur eine bestimmte Syntax hat, aber nicht die alleinige Reguläre Grammatik ist. Es gibt durchaus einfachere und erheblich komplexere Grammatiken. --Arittner 13:30, 10. Nov 2005 (CET)

Du hast recht, mit Perl lassen sich auch nicht-reguläre Sprachen definieren (z.B. die Klammersprache /(a+)b\1/) - die Bezeichnung "Regulärer Ausdruck" ist dann eigentlich irreführend. Vermutlich sollte man die Möglichkeiten von so genannten Regulären Ausdrücken in verschiedenen Programmiersprachen im Artikel besser rausarbeiten. Die "formale" Definition von "regulärer Ausdruck" ist wohl einfach alles, was eine Reguläre Grammatik definiert (also z.B. auch eine BNF für eine reguläre Sprache, wie S: "abc" oder sowas) - das unterscheidet sich aber deutlich von der "populären" Verwednung des Begriffes "Regulärer Ausdruck" in bezug auf Perl, grep, sed, awk und diverse andere Programme, die eine ähnliche syntax verwenden. Sollte man irgendwie einbauen... -- D. Dÿsentrieb ⇌ 14:10, 10. Nov 2005 (CET)

Um den Artikel nicht zu sprengen, sollte man vielleicht einen einen Spezialartikel anlegen, welcher auf die verschiedenen (vielfaeltigen) Varianten der Syntax von regulaeren Ausdruecken eingeht (z.B. mit Tabellen). Denn z.B. '(' ist in qed/vi eben nicht ein Meta-Character sondern steht fuer eine Klammer im Text ('\(' steht dort fuer den Beginn einer Gruppierung). Diese Unterschiede sind sicherlich fuer Anfaenger verwirrend, so dass ein extra Artikel gerechtfertigt ist. Wenn mir niemand zuvorkommt, werde ich einen solchen Artikel anlegen. --Gms 18:34, 9. Jun. 2007 (CEST)

ich wuerde dich dabei unterstuetzen. beachte aber, dass das ganz schon kompliziert und unuebersichtlich werden kann. zum einen, weil es sehr viel software gibt (en:Comparison_of_regular_expression_engines) und zum anderen, weil viele editoren auch mehrere varianten zulassen. in vim gibt es beispielsweise vier (!) verschiedene regexp-modi \v, \m, \V und \M. wie wuerdest du diesen spezialisierten artikel aufbauen wollen? -- seth 22:30, 17. Jun. 2007 (CEST)

Einleitung

kauderwelsch

Sagt mal Leute diese Einleitung ist aber nicht euer Ernst, oder? Wer bitte soll dieses Kauderwelsch verstehen?! 80% von dem was in dieser Einleitung steht will ausschließlich ein Leser wissen, der sich für staubtrockene Theorie interessiert; für praktische Anwender, sprich Programmierer, sind diese Informationen völlig nutzlos. Vielmehr sollte erklärt werden, wofür Regex tatsächlich benutzt wird. (siehe z.B. en:Regular expression) Wer etwas dagegen einzuwenden hat, möge es mir sagen, ansonsten halte ich die Einleitung für dringend bearbeitungsbedürftig und werde dies dann auch tun. -- » ASM 24.04.2006 16:51 CEST

Ich finde die Einleitung so schon in Ordnung. Reguläre Ausdrücke sind halt weit mehr als Textsuche und -ersetzung, wofür sie in vielen Programmen/Programmiersprachen eingesetzt werden. --RokerHRO 18:04, 24. Apr 2006 (CEST)

Die Einleitung ist echt abschreckend

Wenn ein Leser auf diesen Artikel gerät, der weder mit theoretische noch angewandter Informatik was am Hut hat, würde der die Einleitung nicht mal vollständig lesen, um zu entscheiden: "Nee, das ist nichts für mich."

Dabei lohnte es sich vielleicht aber doch. Ich selbst kenne etliche Programmierer (!), die es über viele Jahre geschafft haben, nicht mit regulären Ausdrücken warm zu werden, und das liegt an solchen einleitenden Sätzen wie hier. Sollten wir daran was ändern? --Peu 10:17, 16. Okt. 2006 (CEST)

Mach mal ’nen Vorschlag. Ich bin wohl betriebsblind, weil Informatiker, denn mir erscheint die Einleitung intuitiv verständlich, und mir fällt auch nix ein, wie man das anders formulieren könnte. --jpp ?! 12:08, 16. Okt. 2006 (CEST)

Die Einleitung trifft das Lemma auf den Punkt. Bis auf Implementierungen sind alle Fachwörter erklärt("verlinkt"). Die beiden Sätze dürften mit Hilfer der Links kein Problem im Oma-Test sein. Reguläre Ausdrücke und formale Sprachen sind nunmal sehr theoretisches Zeug. Wer sie in der Praxis beherrschen und anwenden will, muss sich wohl oder übel erstmal durch die Theorie graben, wenn er keinen Pfusch bauen will oder nicht nur einen kleinen Teil nutzen möchte.

Abgesehen davon gibts schon einen Diskussionsabschnitt zur Einleitung. --Schmiddtchen 说 15:26, 16. Okt. 2006 (CEST)

Schmiddtchen, wenn ich mal bei dir einhaken darf, was verstehst du unter Oma-Test?, warum findest du es wichtiger das Lemma auf den Punkt zu treffen, als für möglichst viele Leser verständlich zu sein?, wie kommst du zu der Annahme, dass wer reguläre Ausdrücke in der Praxis beherrschen und anwenden will,...sich wohl oder übel erstmal durch die Theorie graben müsste? und schließlich: warum sollte man eigentlich nicht nur einen kleinen Teil nutzen? (nutzt du denn alle Features von MediaWiki wenn du an der Wikipedia mitarbeitest oder alle Spielarten der Kommunikation, wenn du dich in einer Diskussion zu einem Artikel äußerst?). Ich bleibe dabei, dass die Einleitung für die meisten potentiellen Leser abschreckender ist, als sie sein müsste (ohne fachlich falsch zu sein, versteht sich). Vielleicht wäre ein Einstieg in die Tiefen der Thematik von der Oberfläche und den Anwendungen her günstiger. Wer vertiefen will, liest weiter; sprich: einladende Einleitung und Vertiefung verbunden mit zunehmender Investition (/-sbereitschaft)(?) --Peu 21:02, 16. Okt. 2006 (CEST)

Klar darfst du da einhaken ;)

Mit OMA-Test meine ich WP:OMA. Mit einem Tag Abstand muss ich jedoch sagen, dass die Einleitung den OMA-Test vielleicht doch nicht bestehen würde.

Ich finde es sehr wichtig, das Thema im Einleitungssatz präzise zu treffen, da die Einleitung dafür gedacht ist kurz und präzise zu sein, um auf einzwei Blicke das Thema wiederzugeben. Zum Prosa-Schreiben gibts dann immer noch den Rest des Artikels. Allerdings steckt die Einleitung scheinbar in dem Dilemma zwischen Präzision/Kürze und größtmöglicher Verständlichkeit/großer Zielgruppe. Man muss in dem Zusammenhang aber auch sehen, dass WP kein Märchenbuch, sondern ein Lexikon ist - gewissermaßen ein Fachbuch für viele Disziplinen und Wissensgebiete. Einen Artikel über RegExp oder <hochwissenschaftliches Thema mit kompliziertem Namen> liest man sich in der Regel nicht aus Spaß oder Langeweile durch, sondern weil man wissen will, was genau dahinter steckt. Und wenn man nunmal wissen will, was genau dahinter steckt, muss man sich eben auch mal durch ein paar verlinkte Fachwörter graben, und darf nicht gleich nach dem ersten Satz aufhören, nur weil der nicht mit "Es war einmal.." anfängt (Sorry für die Überspitzung).

Damit einher geht auch meine Forderung, sich mal für ein Thema ein bisschen in die Theorie einzugraben, wenn man sich dafür interessiert. Deswegen kann ich mich auch nicht so recht mit deinem Vorschlag, das von der praktischen Seite aufzuziehen, anfreunden.

(Nachtrag) Die Bedeutung von RegExp liegt nunmal viel tiefer als von einem grep erfasst. Es ist viel eher in den formalen Sprachen als in einer Anwendung davon verankert. Dies sollte (vor dem Hintergrund, dass wir hier ein Lexikon schreiben) durch Setzen gewisser Artikelprioritäten deutlich gemacht werden! (Schmiddtchen 说 01:15, 17. Okt. 2006 (CEST))

Nur weil man mal einen Artikel in der com! oder sonstwo gelesen hat, und einen Aspekt des Themas unbedingt für den revolutionären neuen Texteditor aus der hauseigenen Softwareschmiede benutzen will, heisst das nicht, dass es einfach wird. How-Tos und sonstige praktische Anleitungen in Prosa gibts anderswo; ein Lexikon sollte auch einen gewissen Fachanspruch an sich haben. Daran schliesst sich irgendwo auch die Forderung nach schönem Code an - wenn ich die Theorie zu soetwas wie RegExp verstanden habe, kann ich den praktischen Teil viel effizienter nutzen und bad-practices (oder best-practices gone bad) vermeiden. Dies in Hinblick auf mittlere und große Softwareprojekte.

(Nachtrag)Die von dir eingangs erwähnten Programmierer würden mit einer konkreten theoretischen Fundierung vielleicht viel eher warm werden als mit einem gestückelten praktischen Anlauf, der die Wurzel des Themas ausser Acht lässt. Zumal man als Programmierer sowieso gewöhnt sein sollte, sich durch trockene Papers voller Definitionen zu graben Oo (Schmiddtchen 说 01:15, 17. Okt. 2006 (CEST))

Ein Kompromiß - den du vielleicht sogar schon so gedacht hast, und ich hab das nur falsch verstanden - wäre, eine Art Motivationsabschnitt einzubringen, in der der praktische Nutzen und die Verwendung im "täglichen Leben" kurz beleuchtet wird - praktisch eine prosaische Erweiterung der Einleitung auf ein praktisches Niveau - ganz im Sinne der Überblicksfindung (wo steht der Leser, was kann er mit dem Thema anfangen), ohne sich in billige How-Tos zu entladen. Viele Grüße --Schmiddtchen 说 01:09, 17. Okt. 2006 (CEST)

Ja, das meinte ich; der Anlass den WP-Artikel zu lesen war für mich diesmal das am 5. Okt veröffentlichte neue Google-Produkt [2], wo in der Hilfe auf den Erläuterungen der englischen Wikipedia aufgebaut wird, neben Beispielen (zur Einführung) werden bei Google in der Hilfe die Unterschiede zu POSIX-Reg.Ex. angegeben. Gute Idee eigentlich, da man sich bei Google damit die Übersetzung spart, man kommt ja vom en-Artikel weit rum.

Im Punkt regexp hätte ich anzumerken, dass regex im Buch ISBN verwendet wird, darin suchte ich heute vergeblich (naja vielleicht zu kurz) nach einer formalen Definition. Aber der Mann schafft es ein ganzes Buch zu füllen, das auf die Praxis und auf maximales Verständnis hin geschrieben ist, das sich wirklich topp liest. Seine Lektüre ist auch der Gund für meine Zweifel an dem Wert der Fundierung in der Theoretischen Informatik für die Praxis; nicht falsch verstehen: ich habe nichts gegen die Theorie und bin durchaus mit einigen Aspekten vertraut, aber ein Lexikon braucht keinesfalls Praxisnähe zugunsten theoretischer Schärfe aufzugeben. Na ja im Wesentlichen sind wir uns wohl einig. (Ach ja siehe auch nächster Punkt [=man kann eigentlich nicht so hochgestochen theoretisch einleiten und dann so praktisch weitermachen]) --Peu 08:44, 17. Okt. 2006 (CEST)

Dieser Artikel macht mir (immerhin seit 20 Jahren informatik-interssierter Akademiker) den Begriff nicht annähernd verständlich. Ich verstehe nach dem Lesen nicht, wozu der Begriff benützt wird, warum man ihn gebildet hat, wozu er nützlich ist. Fachmännische Informationen sind im Wikipedia sicher angebracht, aber eine Einleitung für interessierte Normalbürger darf meines Erachtens nicht fehlen. Ich wäre dankbar für eine einleitende Ergänzung. - --schoebu 00:18, 3. Dez. 2006 (CET)

Aus aktuellem Anlass hab ich mich mal an einer erweiterten Einleitung versucht, die so eine Mischung aus "Was ist das in normalen Worten?" und "Wozu brauch ich das in der Praxis?" ist, die beiden grundlegenden Nutz-Zweige abdeckt und sogar ein praktisches Beispiel nennt! Ich bitte um Meinungen! --Schmiddtchen 说 00:44, 3. Dez. 2006 (CET)

ich finde Schmiddtchens ausfuehrlichere variante schon mal sehr viel besser als die vorige kurze. die saetze waren jedoch imho teilweise etwas zu lang und durch nachtraegliche aenderungen grammatisch angeknackst. hab es versucht etwas auszubessern. -- 84.56.230.34 23:52, 2. Mai 2007 (CEST)

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich  ✉  16:53, 6. Mär. 2022 (CET)

Hinweis in der Einleitung auf "denglish"

Aus eigener leidvoller Erfahrung weiß ich die deutsche Definition von ReEx in die Irre führt.

Der Überstzung "regular Expressions" in "reguläre Ausdrücke" ist meiner Meinung nach sinnentstellend. Mein Vorschlag wäre die Einleitung durch einen Hinweis auf "regelbasierende Übereinstimmungen" zu erweitern?

Grüße SuMa

Nö, "regular expressions" sind "reguläre Ausdrücke", wobei hier natürlich Ausdrücke im Sinne der Informatik gemeint sind (siehe Ausdruck (Programmierung) und Ausdruck (Logik), nicht Ausdruck (Linguistik) oder dergleichen). Und das "regulär" kommt von den regulären Grammatiken, zu denen sie gleichmächtig sind. Grammatik ist hier ebenfalls wieder ein Fachbegriff aus der Informatik. --RokerHRO 21:03, 21. Aug. 2007 (CEST)

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich  ✉  16:53, 6. Mär. 2022 (CET)

Ausführlichkeit der Einleitung / Beispiele

Bezogen auf diesen Edit, Quelle: Benutzer Diskussion:Carbenium:

Moin und frohe Weihnachten, Carbenium,

für meinen Geschmack ist die Einleitung zu breit ausgewalzt:

1. erkennen und erzeugen sind bei formalen Sprachen zwei Seiten derselben Medaille
2. das Beispiel mit den Spam-Adressen erscheint mir albern oder zumindest unzeitgemäß: kein ernst zu nehmender Spammer wird heutzutage noch :E-Mail-Adressen mit Brute Force erzeugen, oder? Aufgrund der vielen Bounces würde er doch sofort als Spammer erkannt und abgeregelt?

Was meinst Du?

Gruß aus Freiberg am Neckar, --Mussklprozz 19:53, 25. Dez. 2011 (CET)

Hi Mussklprozz, Dir auch ein frohes Fest!

1. Das mag sein, aber das weiß der Laie nicht – für ihn sind die Analyse von etwas Bestehendem und die Erzeugung von etwas bisher nicht Bestehendem schon aus der Alltagserfahrung etwa unterschiedliches. Von mir aus können wir aus der Differenzierung einen eigenen Abschnitt machen, aber verglichen mit anderen Artikeln ist die Länge der Einleitung durchaus moderat.
2. "Albern" ist übelster POV ;-) — "veraltet": meinetwegen, ich habe mangels intensiver Beschäftigung ein bisschen den Überblick über die immer weiter verfeinerten und ausdifferenzierten Strategien der Spammer verloren. Fakt ist allerdings dass ich tatsächlich (wenn auch vor einigen Jahren) mehrere Mails erhielt, die (bei einer Dreibuchstaben-Userkennung) an mich und alle Empfänger mit dem Namen x[a-z]y@<provider.de> adressiert waren. Zumindest ein historisch interessantes Beispiel – wenn dir ein besseres, relevanteres und aktuelleres einfällt: bitte austauschen! Ein Beispiel für eine Anwendung halte ich aber aus Gründen der Anschaulichkeit dieses doch recht abstrakten Themas für unumgänglich.

Grüße, Carbenium 20:40, 25. Dez. 2011 (CET)

Weblinks

Werkzeuge

Ich würde gerne sämtliche unter Werkzeuge aufgeführten Links löschen. Einmal braucht so was wirklich niemand, da ein Test eines regulären Ausdrucks in der benutzten Programmiersprache sehr viel sinnvoller ist, zum anderen, da die von mir getesteten Onlinetools alle falsche Ergebnisse brachten: Z.B. lieferte /a$/ keinen Match auf einen String der mit a und einem Zeilenumbruch endete. Lehmi 15:37, 6. Mai 2007 (CEST)

zwar sind zwei tage imho zu wenig ueberlegzeit, um solche entscheidungen zu treffen, aber afais steht letztlich das loeschen im einklang mit den wikipedia-regeln, von wegen "keine liste", "wenige externe links", und auch deine argumente sind nicht von der hand zu weisen. ich will auch gar nicht dafuer eintreten, die liste wiederzubeleben, aber trotzdem fand ich sie irgendwie nett. zum andenken setze ich hier mal nen link zur alten liste. moege sie in frieden ruhen. vielleicht gibt's ja irgendwo im netz eine aehnliche liste, die man einfach verlinken koennte? -- seth 00:17, 8. Mai 2007 (CEST)

analog dazu ein link zu den alten programmier-links. -- seth 00:44, 24. Mai 2008 (CEST)

Link hinzufügen ?

Kann man zum Thema noch einen Link (deutscher Online Tester) hinzufügen ? (Vorstehender nicht signierter Beitrag stammt von CIX88 (Diskussion • Beiträge) 2007-07-07T13:34:36)

siehe abschnitt hier drueber. die regelung ist WP:WEB. wenn dieses regexp-tool den anderen tausend tools, die es so gibt, haushoch ueberlegen ist, kannst du es hier mal zur diskussion stellen. -- seth 19:53, 7. Jul. 2007 (CEST)

Naja sehe nur, dass bei der deutschen Ausgabe von Regulärer Ausdruck viele engl. Links vorhanden sind. Ob es Überlegen ist, weis ich nicht, beurteilt selber: Regex-Tester --Mario 21:44, 9. Jul. 2007 (CEST)

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich  ✉  16:53, 6. Mär. 2022 (CET)

regexe.de

herverschoben von meiner DS. -- seth 13:41, 1. Dez. 2008 (CET)

Hallo Seth, du hast vorhin eine Änderung von mir im Beitrag "Regulärer Ausdruck" zurückgenommen. Der Hinweis, dass schon so ein Tool verlinkt ist stimmt zwar, aber hast Du mit dem schon mal gearbeitet? Ich glaube nicht, denn sonst würdest Du ihn schon längst aus der Linkliste entfernt haben ;-) Ich hab beruflich sehr häufig mit regulären Ausdrücken zu tun und das bisher verlinkte Tool ist nicht zu gebrauchen. Hier wird sich mehr auf den PHP-Code konzentriert als auf den Regulären Ausdruck. Außerdem sieht man auf der Ergebnisseite die Eingabe nicht mehr und muss hin- und herspringen. Also, wenn man es richtig machen will, sollte man den Link ganz streichen oder ersetzen. Was meinst Du? Mit regexe.de arbeite ich und meine Kollegen schon seit langem und sind sehr zufrieden.

Viele Grüße, Andreas (nicht signierter Beitrag von W.andreas (Diskussion | Beiträge) 13:38, 1. Dez. 2008 (CET))

gudn tach!

ich habe mit beiden tools nur wenige male gearbeitet. lieber teste ich ausdruecke selbst oder verwende auch mal re. das von dir genannte tool ist einfacher in der handhabung und nicht so sehr auf php ausgerichtet wie das zurzeit im artikel verlinkte. dafuer kann man dort auch nicht soo viel verschiedenes einstellen. z.b. kann man afaics nur i-, m- und s-modifier setzen. was gemaess WP:WEB besser (oder ueberhaupt) zum artikel passt, dazu enthalte ich mich mal einer meinung; siehe dazu auch obige beiden diskussionen. ich schlage vor: wenn sich innerhalb der naechsten 15 tage niemand dagegenstellt, kannst du die beiden links anschliessend tauschen. -- seth 14:10, 1. Dez. 2008 (CET)

phphatesme.com/...

• http://www.phphatesme.com/blog/akademischer-tag/regulaere-ausdruecke/

herverschoben von meiner talk page. -- seth 00:00, 10. Aug. 2009 (CEST)

Hallo seth, du hast meinen Link zum Thema Reguläre Audrücke rausgenommen. Warum? Wenn ich die Richtlinien lese, dann würde ich sagen, dass "Für Weblogs gilt generell das Gleiche, wobei Angebote besonders renommierter und zuverlässiger Institutionen und das Deeplinking einzelner Beiträge, wenn diese den Qualitätskriterien entsprechen, davon ausgenommen sind." doch zutreffen kann. Der Artikel ist auch mathematisch korrekt und besitzt keinesfalls einen Blogcharakter. Nur weil er in einem Blogsystem eingetragen ist, muss er trotzdem nicht alle Attribute eines typschen Blogbeitrags besitzen. Gruß, Nils (nicht signierter Beitrag von 217.233.62.114 (Diskussion | Beiträge) 10:03, 7. Aug. 2009 (CEST))

gudn tach!

ich finde, dass der artikel zu wenig ausfuehrlich ist. er bietet nur wenig mehr informationen als der wikipedia-artikel, der zugegeben zu der informatischen betrachtung noch viel zu wenig infos bietet. lieber waere es mir, wenn der wp-artikel weiter ausgebaut wird.

gibt's denn weitere meinungen zu dem link? falls sich noch jemand (moeglichst ein bisheriger autor des artikels) fuer den link ausspricht, will ich mich nicht dagegen stellen. -- seth 00:20, 10. Aug. 2009 (CEST)

Moin, also mit der Einstellung kann ich auf jeden Fall leben. Gruß, Nils (nicht signierter Beitrag von 193.7.250.35 (Diskussion | Beiträge) 08:59, 10. Aug. 2009 (CEST))

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich  ✉  16:53, 6. Mär. 2022 (CET)

http://regexpal.com/

Ich hätte gerne den regexpal in der Linkliste ergänzt, da dieser im Gegensatz zu regexe.de die Ausdrücke in Echtzeit auswertet und über Syntax-Highlighting verfügt. Dass dieses Tool nicht von einem deutschsprachigen Autor stammt, finde ich vernachlässigbar, da es sich bei Regexen ja um "sprachneutralen" Code handelt. Hobbyhobbit88 19:15, 5. Sep. 2011 (CEST)

aktuelle weblinks

gudn tach!
derzeit haben wir (in mit dem artikel identischer reihenfologe)

• eine regexp-test-page zum selbst ausprobieren. sowas kann sehr hilfreich zum verstehen von regulaeren ausdruecken sein.
• einen ausfuehrlichen artikel ueber praktische umsetzung und theorie dahinter (leibniz-rz, bayr. akad. d. wissenschaften)
• ein ausfuehrliches tutorial
• eine mini-einfuehrung; eher blogeintrag.
• posix-specs (ieee)
• regexps in perl (perldoc perlre), weiterentwicklung der PCRE, die mittlerweile in den grossen sprachen (python, perl, php, c++, javascript, java) immer mehr vereinheitlich werden.
• noch ein tutorial, ebenfalls ausfuehrlich, geht insb. auf unterschiede in den diversen programmiersprachen ein.

loeschwuerdig ist da imho vor allem die mini-einfuehrung, die weniger umfangreicher ist, als unser artikel (aber auch nicht praegnanter). -- seth 22:19, 5. Feb. 2014 (CET)

zu [3]: nicht nur im kindergarten und in der schule weiss man, dass das ausprobieren von dingen enorm das verstaendnis steigern kann. das deutsche museum in muenchen ist ein sehr gutes beispiel dafuer, wie man spielerisch an komplizierte sachverhalte herangefuehrt werden kann. ein tool zum regexp ausprobieren ist fuer interessierte, die den wikipedia-artikel ueberflogen oder gelesen haben, eine hochinteressante sache, um durch ausprobieren ein gefuehl fuer den artikelgegenstand zu bekommen. regexp-tester gibt's sehr viele im web. einer von denen sollte meiner meinung nach auf jeden fall auch im artikel genannt werden.

im artikel wurden immer mal wieder welche ausgewechselt. ich fand den aktuellen jetzt nicht besonders hervorzuheben, aber er war immerhin schlicht und hat funktioniert. die schlecht als solche markierte werbung emfand ich allerdings als etwas stoerend. beim kurzen stoebern bin ich auf https://www.debuggex.com/ gestossen, der fordert zwar javascript, aber malt einem einen zugehoerigen automaten auf, dessen zustaende man auch zeichen fuer zeichen durchlaufen kann.

imho ein sehr schoenes tool, nicht nur zum debuggen, sondern eben auch zum ausprobieren und verstehen von regexps. -- seth 23:16, 6. Feb. 2014 (CET)

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich  ✉  16:53, 6. Mär. 2022 (CET)

Werkzeuge II

gudn tach!
wie in den obigen threads erklaert, brauchen wir nicht mehrere tools, die sehr aehnlich sind. im zweifelsfall soll das nur das (gemaess WP:EL) bessere tool verlinkt werden. das tool von loresoft[4] ist ein regexp-tester, wie man ihn zu dutzenden im web findet, und er besitzt keinen wesentlichen vorteil gegenueber dem derzeit verlinkten (von debuggex.com). im gegenteil, er ist speziell auf php ausgerichtet. insofern bin fuers loeschen des loresoft-links. -- seth 13:12, 28. Feb. 2014 (CET)

Ich werfe mal https://regex101.com/ in den Ring. Zwar auf englisch, aber liefert zum Ergebnis Erklärungen, was mir z.B. sehr geholfen hat. --2A02:8109:9A40:1F0C:B82A:262B:E99:B2C5 14:26, 26. Dez. 2017 (CET)

grundsätzliches

Die Aussage, dass man mit regulären Ausdrücken die Syntax von Programmiersprachen prüfen kann, ist in der Allgemeinheit, in der sie hier formuliert ist, falsch. Mit regulären Ausdrücken kann man Teilaspekte der Syntax (z.B Identifier, String, Gleitkommazahl) überprüfen. Es ist aber zum Beispiel nicht möglich, die Korrektheit eines Formelausdrucks zu überprüfen. Ich bitte den Autor des Artikels, dies zu korrigieren. (nicht signierter Beitrag von 80.141.66.33 (Diskussion) )

Du hast Recht. Mit regulären Ausdrücken lässt sich nur die lexikalische Analyse durchführen. Ich passe das mal an. --jpp ?! 13:25, 31. Aug. 2007 (CEST)

woher kommen reguläre ausdrücke?

Was mir fehlt: Woher kommen reguläre Audrücke? wer hat sie erfunden? Seit wann gibt es sie? --84.60.21.122 18:29, 5. Apr. 2008 (CEST)

Beispiele

Wären Beispiele für gebräuchliche Ausdrücke nicht sinnvoll?

• Telefonnummer: ^[+][0-9]{1,2}[(][1-9][0-9]{1,5}[)][0-9]{3,10}([-][0-9]{1,10}){0,1}$ (nicht signierter Beitrag von DJAssi (Diskussion | Beiträge) 04:26, 15. Jun. 2008 (CEST))

nein, denn so einfach ist es nicht, vgl. [5]. -- seth 12:27, 15. Jun. 2008 (CEST)

Aber ein paar Beispiele wuerden schon helfen den Artikel auch fuer Programmierleihen

verstaendlicher zu machen. --Go2sh 03:54, 28. Aug. 2008 (CEST)

Es muss ja nichts so schwieriges wie Telefonnummern sein. Wie wäre es mit Postleitzahlen?: ^[0-9]{5}$ oder E-Mail-Adressen: /[\.a-z0-9_-]+@[\.a-z0-9-]+/i (da gibt es zwar auch noch viele andere Versionen, aber ich denke so ist das zumindest nicht ganz falsch. Wobei ich mir nicht sicher bin, ob alle Zeichen berücksichtigt wurden, die in E-Mail-Adressen vorkommen.) --Nico Düsing (Diskussion) 02:45, 31. Aug. 2008 (CEST)

email-adressen. nicht so schwierig wie telephonnummern. dir ist klar, daß rfc-822 so schweinereien wie rekursiv verschachtelte kommentare erlaubt, die mit einer regulären sprache überhaupt nicht auszudrücken sind? "mastering regular expressions" hat eine regexp, die nur eine verschachtelungsebene erkennt, aber sonst alles was so erlaubt ist. die ist dann gut 4kB lang. -- ∂ 03:43, 31. Aug. 2008 (CEST)

ich stimme zwar zu, dass e-mail-adressen kein gutes (anfaenger-)beispiel darstellen, allerdings koennen mittels regexps mehr als nur regulaere sprachen abgedeckt werden. mittlerweile sind sogar rekursionen bis zu einem gewissen grad moeglich, siehe "perldoc perlre". -- seth 12:24, 31. Aug. 2008 (CEST)

Syntax-Unterschiede z.B. bei Zeichenliteralen

Es bahnt sich gerade ein kleiner Edit war zum Thema Zeichenliterale an, weshalb ich das hier diskutieren möchte. Das Thema ist Teil der Syntaxbeschreibung, die leider implementationsabhängig ist, obwohl es einen POSIX-Standard gibt. Im Artikel heißt es: Die folgenden Syntaxbeschreibungen beziehen sich auf die Syntax der gängigen Implementierungen mit Erweiterungen, sie entsprechen also nur teilweise der obigen Definition aus der theoretischen Informatik. Implementationsunterschiede werden aber in diesem Artikel nicht deutlich gemacht.

Der aktuelle Streit geht um die Spezialfrage, wie oktale Zahlen als Literale ausgedrückt werden können. Jemand, der unangemeldet arbeitet, bezieht sein Wissen aus Escape-Sequenz#Escape-Sequenzen in C und verwandten Programmiersprachen und besteht auf \ooo, während ich und andere dort \0ooo angegeben haben. Ich habe das mit dem in bash(1) und zsh(1) eingebauten Kommando echo -e '\101' ausprobiert und herausgefunden, dass es nicht funktioniert (Ergebnis: \101). echo -e '\0101' funktioniert aber (Ergebnis: A). Genauso verhält sich die tcsh(1) (hier muss man allerdings das -e weglassen), obwohl man die dazugehörige Manpage anders verstehen könnte. Zu meiner Überraschung verhält sich das Programm /bin/echo aus den GNU core utilities anders und interpretiert beide Schreibweisen als A. Die mit der führenden Null scheint aber portabler zu sein.

Frage: Soll die Syntaxbeschreibung im Artikel die Syntax einer bestimmten RegEx-Implementierung beschreiben oder versuchen, alle Implementierungen (mit ihren Abweichungen und Bugs) zu erfassen? Oder beschreiben wir lieber nur den POSIX-Standard, auch wenn verschiedene Implementierungen davon abweichen? --Thüringer ☼ 14:48, 27. Nov. 2008 (CET)

schwierig. erst mal zur allgemeinen frage:

alle grossen/wichtigen regexp-implementierungen unterscheiden sich (wenn auch haeufig nur geringfuegig) oder bieten mehrere verschiedene syntaxen an. im linux cli wurd haeufig die unterscheidung zwischen BRE und ERE getroffen. vim dagegen hat sein eigenes sueppchen gebraut, aber eine der leistungsfaehgisten regexp-implementierungen auf die beine gestellt, die selbst gegenueber der perl-regexp-engine vorteile hatte. php kennt pcre ($\neq$ perl) und posix. und das genuegt eigentlich schon an beispielen, um das existierende chaos anzudeuten. je nachdem aus welcher welt man kommt, haelt man nun die einen oder die anderen syntaxen fuer die massgeblichen. alle (selbst nur alle grossen) regexp-implementierungen koennen wohl nicht erklaert werden und wuerden darueber hinaus das verstaendnis (stichwort: OMA) erschweren. wenn man sich aber eine bestimmte implementierung heraussucht, fuehrt das vermutlich zu unnoetigen, ewigen diskussionen.

so wie wir es momentan machen, naemlich eine mixtur zu erklaeren und dabei an gegebenen stellen darauf hinzuweisen, dass es jeweils implementationsabhaengig ist, halte ich fuer einen guten mittelweg. denn der artikel soll ja kein manual sein, sondern ein enzyklopaedischer artikel, der also die prinzipien beschreibt.

zum speziellen problem: ein auszug aus dem perl-manual:

There is no limit to the number of captured substrings that you may use. However Perl also uses \10, \11, etc. as aliases for \010, \011, etc. (Recall that 0 means octal, so \011 is the character at number 9 in your coded character set; which would be the 10th character, a horizontal tab under ASCII.) Perl resolves this ambiguity by interpreting \10 as a backreference only if at least 10 left parentheses have opened before it. Likewise \11 is a backreference only if at least 11 left parentheses have opened before it. And so on. \1 through \9 are always interpreted as backreferences. (perldoc perlre)

das ganze ist dort also noch mal etwas komplizierter. sobald die zahlen dreistellig werden, funzt die schreibweise mit der fuehrenen null uebrigens in perl nicht mehr:

geht: \101, \12, \012, \007, \07

geht nicht: \7, \0101

keine der varianten \0nnn \nnn ist also wirklich von praktischem vorteil. mir persoenlich ist es wurscht, welche im artikel steht. um aber weitere edits in dieser richtung zu verhindern, sollte entweder als html-comment oder tatsaechlich im artikel auf die jeweils andere schreibweise hingewiesen werden. -- seth 16:55, 27. Nov. 2008 (CET)

Modifier

Der Begriff "Modifier" wird zweimal im Artikel verwendet, ohne überhaupt eingeführt worden zu sein. Der Leser erfährt lediglich, dass der s-Modifier (/<RegExp>/s) die Bedeutung des '.' auf wirklich beliebige Zeichen erweitert und dass der m-Modifier den Multilinemodus aktiviert, wodurch '^' und '$' auf jedes Zeilenende bzw. jeden Zeilenanfanganfang matchen. Der Begriff selbst und eine Tabelle mit den gängigsten Modifiern (und ein Hinweis, welche Programme überhaupt Modifier unterstützen) fehlt also noch (wenn man denn die Modifier hier erwähnen will). Falk _{Sprich^zumir…} 19:48, 13. Jan. 2009 (CET)

hmm, ich kann mir gut vorstellen, dass ich die beiden vorkommnise zu verantworten habe. an diesen beiden stellen sie muessen imho schon erwaehnt werden, um eben auf die wichtigen ausnahmen hinzuweisen. imho ist es dazu nicht wichtig zu wissen, was modifier genau sind, sondern bloss dass sie existieren und eben u.a. die genannten funktionen ermoeglichen.

ob eine einfuehrung der modifier sinnvoll ist, weiss ich nicht. der artikel ist eh schon ziemlich tutorial-maessig aufgebaut. die modifier werden uebrigens nicht besonders einheitlich definiert. ok, die wichtigsten vielleicht schon, aber php backt da z.b. auch vielen eigene broetchen. -- seth 22:20, 13. Jan. 2009 (CET)

also über Modifier sollte man schon ein extra Kapitel machen. Es gib als Modifier g s m i und sicher noch weitere. Wer fängt mal an ? --79.217.252.128 12:15, 24. Mär. 2009 (CET)

also das mit dem Tutorial mag ja sein (obwohl ich das gar nicht für schlecht empfinde, bei Wikipedia finde ich das einfach schön übersichtlich) aber die Modifier sind, denke ich ein wichtiger Bestandteil der Regulären Ausdrücke --DerGenaue(Allrounder) 93.135.39.92 22:19, 2. Apr. 2012 (CEST)

gudn tach!

das mit den modifiern ist mit der zeit recht kompliziert geworden. in perl gibt's seit version 5.14 smixpgcoduale, wobei o keine bedeutung mehr hat. in php gibt's smixeADSUXJu. in python heissen die dinger flags und werden syntaktisch anders notiert, naemlich als funktionsparameter re.S, re.I, re.L, re.M, re.U, re.X. c++ boost braut da ein eigenes sueppchen mit options, die man aber nicht immer verwenden kann[6]. siehe auch [7].

und dann kann man in einigen sprachen, z.b. in perl, auch die modifiers in subpattern verwenden, wieder mit etwas anderer syntax. ich denke, wenn man die modifiers hier im artikel behandelt, dann nur am rande in einem satz, indem man dann vielleicht auf einen ausgesuchten, naemlich den i-modifier beispielhaft eingeht.

fuer regelrechte tutorials/manuals gibt's andere wikis. die koennen, wenn sie besonders gut und informativ sind, dann hier verlinkt werden. der wp-artikel selbst sollte aber kein manual sein, siehe auch WP:WWNI. -- seth 22:45, 3. Apr. 2012 (CEST)

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich  ✉  16:53, 6. Mär. 2022 (CET)

Quantoren und Backtracking

Ich glaube, die folgende Aussage ist so nicht richtig:

Die Implementierung von genügsamen Quantoren ist vergleichsweise aufwändig (erfordert Backtracking), weshalb nicht alle Implementierungen diese unterstützen.

Ich kenne grundsätzlich zwei Implementationen:

1. Eingabe-gesteuert: Man macht aus dem regulären Ausdruck einen (nichtdeterministischen) Endlichen Automaten, bildet dessen (deterministischen) Potenzautomaten, minimiert den letzteren und füttert ihn mit dem Eingabetext: (a) bis man erstmals einen akzeptierenden Endzustand erreicht (i.e. reluctant?) oder nicht mehr weiterkommt oder (b) man merkt sich im Erfolgsfall den zuletzt erreichten Endzustand und konsumiert die Eingabe weiter in der Hoffnung, dass sie nochmals auf einen Endzustand führt (i.e. greedy?).

2. Regex-gesteuert: Man probiert die Alternativen des regulären Ausdrucks durch, im Falle von Quantoren durch Iteration über die Anzahl der Wiederholungen. Dann erfordern meines Erachtens auch greedy Quantoren Backtracking - nämlich für den Fall, dass sie zu viel gefressen haben und die betreffenden Zeichen der Eingabe von einem nachfolgenden Teilausdruck benötigt werden. Beispiel: „[ab]*[bc]“ mit der Eingabe „aabb“.

Wenn ich nicht irre (was möglich ist), hängt Backtracking nicht von der Frage greedy oder reluctant ab. -- mibo 17:57, 24. Mär. 2009 (CET)

gudn tach!

ich dachte, dass sowohl fuer greedy als auch lazy quantifiers backtracking noetig sei, etwa so wie es auf [8] beschrieben ist.

greedy ohne backtracking ist afaics nicht moeglich, ohne die possessivitaet abzulegen. evtl. ist mit dem von dir zitierten satz also einfach DFA gemeint? -- seth 15:47, 28. Mär. 2009 (CET)

laut Russ Cox [9] (vor allem Absatz "Ambiguous submatching") kann eine Implementierung auf backtracking verzichten (in Bezug auf Quantoren) - der Unterschied zwischen greedy und non-greedy ist fast nicht sichtbar (besteht nur in der Reihenfolge der Abarbeitung). Von dem her ja, der Satz ist falsch. google hat mit RE2 eine entsprechende Implementierung ohne backtracking (von besagtem Russ Cox) --Didgeedoo 22:55, 15. Nov. 2011 (CET)

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich  ✉  16:53, 6. Mär. 2022 (CET)

Was ist mit [. … .] und [= … =] ?

Es gibt noch weit mehr als das was bisher bei den []-Ausdrücken steht. :-/ --82.83.126.246 11:07, 2. Jun. 2009 (CEST)

Morphologie natürlicher Sprachen

Aus dem Artikel:

Die Mächtigkeit regulärer Ausdrücke reicht aus, um – von wenigen Ausnahmen abgesehen – die Morphologie einer natürlichen Sprache zu beschreiben.

Eine solche Aussage sollte dringlichst mit konkreten Quellen versehen werden.--Mrmryrwrk'^soch'os! 14:48, 17. Okt. 2009 (CEST).

Ich stimme dir vollkommen zu. Zumal die Behauptung auch noch bei Theoretische Grundlagen untergebracht ist. Ob Ausnahmen innerhalb der Sprache gemeint sind oder einige Sprachen ausgenommen sind, ist auch nicht klar. Nur aufs Deutsche bezogen: Wie sollen reguläre Ausdrücke die Pluralbildung beschreiben? (Frau/Frauen, Tau/Taue, Sau/Säue, Bau/Bauten) Keine Quellen: ich entferne es. --Zahnradzacken 12:47, 26. Jan. 2010 (CET)

Ist richtig so. Die Aussage lässt sich mehr noch relativ leicht widerlegen: Nimm den Plural von Bank…--Mrmryrwrk'^soch'os! 19:06, 26. Jan. 2010 (CET).

Natürlich banker, weil du bestimmt gerade vom Dänischen sprachst ;) --Zahnradzacken 19:34, 26. Jan. 2010 (CET)

Definition doppelt?

In der 4. Zeile der Definition

4. Sind x und y reguläre Ausdrücke, so sind auch (x|y) (Alternative), (xy) (Verkettung) und x * (Kleenesche Hülle) reguläre Ausdrücke.

verstehe ich nicht, welche Fälle x* erfassen soll, die noch nicht erfasst sind. Ist die Verkettung bei mehrmaliger Ausführung auf eine Leerelement-haltige Menge nicht gleichbedeutend? -- Lutz 08:35, 4. Feb. 2010 (CET)

Guter Deutsch?

Sind wir so furchtsam unsere Sprache voll zu nutzen? Haben wir wirklich keine Wörter[10] zum Beispiel für gematcht und müssen auf Denglisch zurückgreifen? Ist wahrscheinlich uncool… ;-) ich bin auch nicht für aberwitzige „Deutschungen“, und weiß zu gut, daß es Themenfelder (z.B. Statistik) gibt, bei denen englische Begriffe eher angebracht sind als deutsche, dennoch würde ich mich über eine gut formulierte deutsche Sprache freuen, ohne gleich in die Ecke der Ausgrenzer und Ausländerfeindlichkeit gestellt zu werden.-- A.Plank 20:18, 6. Apr. 2010 (CEST)

So sehr ich dir prinzipiell auch zustimme, manche deiner Änderungen finde ich nicht gelungen.

• "Matchen" ist üblicher Jargon und lässt sich nur schwer sinnerhaltend durch ein deutsches Wort ersetzen, denn das Matchen ist nicht das Finden allein, sondern transportiert auch den Gedanken des Suchens mit einer Schablone, die mit dem untersuchten Text abgeglichen wird. Dass ein Suchmuster "matcht" (übereinstimmt) ist eben zutreffender, als dass das Suchmuster von selbst "fündig wird". Und "zu to match" geht ja gar nicht.
• Backtracking ist kein Zurückverfolgen. Backtracking wird hier auch Rücksetzverfahren oder Rückverfolgung genannt, nunja, aber ist jedenfalls mehr als nur ein Zurückverfolgen – es ist eine Strategie des zurücknehmens getroffener Entscheidungen.
• Im folgenden Satz ist nun ein Fehler, er war vorher richtig:
  • „Soll eine Zeichenkette nur aus dem gesuchten Muster bestehen (und es nicht nur enthalten), so muss dies in den meisten Implementierungen explizit definiert werden, dass das Muster von Anfang (\A oder ^)¹ bis zum Ende der Zeichenkette (\Z, \z oder $)¹ reichen soll“
• Ich weiß nicht, wem dein Kommentar im Abschnitt Lookahead-Assertions dienen soll. Ich äußere mich trotzdem mal dazu: Meiner Meinung nach ist die Suchanfrage der reguläre Ausdruck, die Suchabfrage ist das, was als Treffer zurückgegeben wird.

--Zahnradzacken 21:58, 6. Apr. 2010 (CEST)

gudn tach!

ich sehe es aehnlich wie Zahnradzacken und habe deswegen einige weitere der aenderungen revertiert. der abschnitt zu den look-ahead-assertions war fuer mich (obwohl ich assertions gut kenne) nach der versuchten eindeutschung unverstaendlich.

der begriff matchen wird bei der ersten verwendung erklaert, insofern sollte es kein problem sein, diesen schlecht uebersetzbaren begriff zu verwenden. -- seth 21:40, 17. Apr. 2010 (CEST)

Ich finde den Revert etwas radikal. Zwar finde ich den Gebrauch von matchen okay, aber einige Umschreibungen waren doch zutreffend und der Satz somit leichter zu erfassen.

Den Satz "D. h., möchte man alle Zeichenfolgen „Sport“ matchen, denen die Zeichenfolge „verein“ folgt, ohne jedoch die Zeichenfolge „verein“ selbst zu matchen, wäre dies mit einer look-ahead assertion möglich" verstehe ich nun aber auch nicht besser. Das Wörtchen matchen ist mit der Übersetzung noch nicht genügend erklärt. Hier je nach Kontext etwas Sinngemäßes zu verwenden, fände ich leserlicher.

Zwar steht auch Implementation im Duden, aber Implementierung eben auch, warum also revert? --Zahnradzacken 23:24, 17. Apr. 2010 (CEST)

gudn tach!

gemaess WP:RS sollen richtige begriffe nicht durch andere, nicht richtigere begriffe ersetzt werden. die reverts auf den urspruenglichen zustand solcher edits sind jedoch notwendig, da die regel sich sonst selbst aushebeln und damit unnoetig machen wuerde.

0. Wenn wir von der gleichen Stelle reden, bezieht sich das eigentlich nur auf Schreibweisen; hier geht es an sich um zwei Wörter für die gleiche Sache. 1. Es ist nur nicht gewünscht, aber Gesetz ist es nunmal nicht. 2. Die Notwendigkeit eines Reverts sehe ich auch dann nicht, falscher wurde es ja auch nicht. Warum würde sich die Regel selbst aushebeln? 3. Ausnahmen sind nach WP:RS zulässig, um konsistente Formulierungen zu verwenden. 4. Wenn ich ein Wort aus stilistischen Gründen durch ein anderes ersetze, ist das "erlaubt", obwohl das nur subjektiv eine Verbesserung ist. Dass das andere Wort ein Synonym ist, ist ein Spezialfall. --Zahnradzacken 01:02, 19. Apr. 2010 (CEST)

zu dem sport-satz: vorher stand da der begriff "mitabfragen" und das ist falsch oder wenigstens missverstaendlich. hab's jetzt noch mal umformuliert und ein beispiel dazugeklatscht. beispiele sind fuer regexp imho mit die verstaendlichste erklaerung. falls es missfaellt oder weitere verbesserungen in dem abschnitt gemacht werden koennten, selbstverstaendlich gerne. und gerne auch, ohne hier noch mal nachzufragen. bloss das pauschale entfernen von begriffen ist nicht ok. -- seth 00:42, 18. Apr. 2010 (CEST)

Hm, also zunächst mal finde ich es doof, wenn man die Verwendung Wortwahl (Anglizismen, Fremdwörter) und Grammatik (“Guter Deutsch”) durcheinander schmeisst. Beides hat miteinander erstmal nichts zu tun. Aber egal… Eine deutsche Entsprechung von "matchen" in diesem Zusammenhang wäre „erkennen“: Ein Automat/eine RE-Abfrage erkennt einen gesuchten Ausdruck in einer gegebenen Zeichenkette oder eben nicht. In diesem Falle müsste man im Artikel allerdings die spezifische Bedeutung von erkennen näher erläuern.--Mrmryrwrk'^soch'os! 11:50, 18. Apr. 2010 (CEST).

gudn tach!

"erkennen" passt tatsaechlich in eingen kontexten. am beispiel der assertions sieht man aber auch, dass "erkennen" hier wieder zu leicht falsch zu verstehen ist. selbst im englischen hat man eigentlich das problem mit "match", insofern hat das verwenden eines fuer's deutsche eher neuen begriffs "matchen" sogar einen vorteil.

im beispiel /foo(?=bar)/ wird ein "foo" gematcht, dem ein "bar" folgt. erkannt werden, muss selbstverstaendlich auch das bar, aber ist eben nicht im gematchten string enthalten. man koennte zwar das wort "erkennen" fuer unsere zwecke umdeuten, aber das haette keinen vorteil gegenueber dem fachbegriff "matchen", da in beiden faellen eine erklaerung der jeweiligen begriffe erfolgen muesste. im gegenteil: man kann ohne umdeutung des begriffes "erkennen" diesen in seiner allgemein ueblichen bedeutung verwenden. -- seth 14:31, 18. Apr. 2010 (CEST)

Ich finde es auch sehr praktisch, dass sich die deutsche Sprache durch zu Fachbegriffen umgemünzten Fremdwörtern bereichert. Andererseits finde ich es nicht sehr ansprechend, wenn so häufig von "matchen" und "gematcht" die Rede ist. (Vor allem hat man sich in einem Wort präzise aber eventuell unverständlich ausgedrückt.) Aber ein deutsches Wort zu finden, das die Rolle übernimmt, eine ganz spezielle Bedeutung zu haben, ist nicht unsere Aufgabe. Wenn es so etwas in der Literatur gibt, sollte es erwähnt werden. Wenn nicht, muss man anders auskommen. Ich finde es weiterhin am sinnvollsten, wenn man die im Kontext am besten passende (knappe) Umschreibung wählt. Es muss ja nicht ein Verb durch ein Verb ersetzt werden, man kann Sätze ja auch umstellen. --Zahnradzacken 01:02, 19. Apr. 2010 (CEST)

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich  ✉  16:53, 6. Mär. 2022 (CET)

Beliebiges Zeichen

ich kenne natürlich nicht alle Implementiereungen, aber alle die mir bisher untergekommen sind, definieren . als "beliebiges Zeichen" oder als "beliebiges Zeichen außer Newline". In dem Absatz wird allerdings davon gesprochen, dass manche Implementierungen mit . nur Newline matchen würden. Das beißt sich doch mit dem restlichen Text, oder? Kennt jemand eine solche Implementierung? --Didgeedoo 23:13, 22. Jul. 2010 (CEST)

gudn tach!

missverstaendnis. das "auch" war hier additiv gemeint und nicht i.s.v "statt dessen". hab's umformuliert. -- seth 23:32, 22. Jul. 2010 (CEST)

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich  ✉  16:53, 6. Mär. 2022 (CET)

Plural von »Regex«

Was ist der Plural von Regex in der deutschen Sprache? Im englischen sagt man lt. Wikibooks »regexes«, aber mein Sprachgefühl sagt mir, dass man den Plural analog zu Index als »Regizes« bilden sollte. Gibt es dazu irgendeinen Konsens? --FUZxxl^D|M|B 17:03, 18. Jul. 2011 (CEST)

gudn tach!

"regizes" sagt ausser dir vermutlich kein mensch, vgl. [11]. "regex" bzw. "regexp" kommt von "regular expression", infolge dessen wird im deutschen auch meist wie im englischen "regexes" bzw. "regexps" verwendet. uebrigens hat "index" ebenfalls zwei plurale, siehe duden. -- seth 23:50, 18. Jul. 2011 (CEST)

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich  ✉  16:53, 6. Mär. 2022 (CET)

Fehlerhaftes Beispiel zu bedingten Ausdrücken

Im Artikel taucht im Block "3.11 Bedingte Ausdrücke" als Beispiel folgendes auf: (\()?\d+(?(1)\))

Wäre nicht (\()?\d+(?(\1)\)) korrekt? Es soll ja nicht auf die Ziffer 1 geprüft werden, sondern auf die erste Rückwärtsreferenz, also das Zeichen "(", wenn vorhanden. Im Artikel wird bei Rückwärtsreferenzen auch beispielsweise \1 als Beispiel genannt. -- Folker 14:11, 25. Jan. 2012 (CET)

gudn tach!

das im artikel ist schon richtig so, siehe perlre. man will ja nicht auf die backreference selbst zugreifen, sondern nur feststellen, ob sie existiert (in perl: wenn sie defined ist), d.h. ?(x) steht bloss symbolhaft dafuer, dass ueberhaupt \x etwas - und sei es den leerstring, falls erlaubt - matchte. -- seth 18:08, 28. Jan. 2012 (CET)

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich  ✉  16:53, 6. Mär. 2022 (CET)

Leeres Wort sehr wohl regulärer Ausdruck

Die Behauptung (so u. "Semantik"), ε sei (für sich genommen) kein regulärer Ausdruck, ist schlichtweg falsch. Siehe u. a. http://kontext.fraunhofer.de/haenelt/kurs/folien/Haenelt_RegEx.pdf (S. 13), oder http://www.gruenderboom.de/SprachTextTech/RegulaereAusdruecke.pdf (S. 88), oder je nach Belieben. Ich jedenfalls habe noch nie entsprechend Gegenteiliges vernommen, mit der prominenten Ausnahme eben dieses vorliegenden Artikels. Tatsächlich aber gehörte das leere Wort - präziser: die Menge, die (nur) das leere Wort umfasst - m. E. bereits innerhalb d. formalen Definition unter "Syntax" aufgeführt, es gilt hier schließlich das gleiche wie für die leere Menge. Sollte dem so sein, müssten jedoch auch die betreffenden Angaben unter "Semantik" entsprechend geändert werden. -- Zero Thrust (Diskussion) 09:42, 8. Jun. 2012 (CEST)

"Schlichtweg falsch" ist schlichtweg falsch. Zunächst ist das leere Wort ein Wort und kann damit vom Typ her kein Ausdruck sein. Deshalb unterscheiden sich hier auch $a_{i}\in \Sigma$ von $\mathbf {a_{i}}$. Diese klare Unterscheidung, wie sie etwa hier vorgenommen wird, unterscheidet dann eben auch $\varepsilon$ (Wort) von $\epsilon$ (Ausdruck), bzw. $\lambda$ (Wort) von $\Lambda$ (Ausdruck).

Die Menge, die das leere Wort enthält, ist natürlich erst recht nichts Syntaktisches. Warum du die Syntax umdefinieren willst, weil es auch die Sprache $\{\varepsilon \}$ gibt, verstehe ich nicht. --Zahnradzacken (Diskussion) 21:39, 16. Jun. 2012 (CEST)

Nee, regelrecht umdefinieren wollte ich die Syntax auch nicht. War lediglich der (falschen) Annahme, dort würde etwas fehlen. Wobei mein Missverständnis offensichtlich auf der Differenzierung von $\varepsilon$ und $\epsilon$ gründet, das war mir nicht klar. Bitte um Entschuldigung und recht herzlichen Dank für die Erklärung. -- Zero Thrust (Diskussion) 15:02, 17. Jun. 2012 (CEST)

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich  ✉  16:53, 6. Mär. 2022 (CET)

Generieren von Spam-Emailadressen

Auf diese Weise können etwa systematisch E-Mail-Adressen (vor allem der Teil vor dem @) für den Spam-Versand generiert werden. Das verstehe ich nicht. Wenn ich 100 Vornamen und 100 Nachnamen nehme, kann ich mit zwei Schleifen 10000 Emailadressen der Form <Vorname>.<Nachname>@t-online.de erzeugen. Und für Adressen wie franz34234@gmx.net brauche ich auch keine regulären Ausdrücke. --Siehe-auch-Löscher (Diskussion) 09:11, 17. Mär. 2013 (CET)

Ich brauche auch keine regulären Ausdrücke, um Eingaben auf ein Muster zu prüfen. Trotzdem gibt es sie genau dafür. Nun zweifle ich aber auch daran, dass das Generieren aus RegExps in der Einleitung arg sinnvoll ist. Von mir aus kann es da raus. --Zahnradzacken (Diskussion) 11:07, 18. Mär. 2013 (CET)

ich habe es mal gelöscht. Wenn das Beispiel etwas unterfüttert wird kann es ja wieder rein. Ich habe bisher keine regulären Ausdrücke als Generatoren für Wörterlisten gesehen. --Siehe-auch-Löscher (Diskussion) 11:22, 18. Mär. 2013 (CET)

Gut. Aber deine anderen Änderungen finde ich nicht so gut. Was soll "Neben fast allen Programmiersprachen … existieren Implementierungen" heißen? Und nun wird die mächtige Textersetzung leider auf die Verwendung in Texteditoren reduziert. --Zahnradzacken (Diskussion) 15:20, 18. Mär. 2013 (CET)

Ja, die Textersetzung gehört eigentlich in den Einleitungssatz. Der ist auch noch nicht ganz OMA-tauglich, wie bereits weiter oben bemängelt wird. Ich denke mal drüber nach. --Siehe-auch-Löscher (Diskussion) 16:51, 18. Mär. 2013 (CET)

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich  ✉  16:53, 6. Mär. 2022 (CET)

Reguläre Ausdrücke in Proteindatenbanken

In der jetzigen Form ist der Erklärungswert der Einfügung dürftig. Als Außenstehender hätte ich schon gerne einen Verweis, um nachlesen zu können, was ein Proteinmotiv ist. Und eine Erklärung, wofür die Buchstaben in dem Beispiel-Ausdruck stehen. --Mussklprozz (Diskussion) 16:49, 9. Mai 2014 (CEST)

Ist es jetzt durch die Hyperlinks und Erklärung klar? (nicht signierter Beitrag von 149.172.89.227 (Diskussion) 21:23, 5. Aug. 2014 (CEST))

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich  ✉  16:53, 6. Mär. 2022 (CET)

Gruppierungen und Rückwärtsreferenzen - Beispiel

Ein Datum im Format MM/DD/YYYY soll in das Format YYYY-MM-DD überführt werden.

Mit Hilfe des Ausdrucks ([0-1]?[1-9])\/([0-3]?[1-9])\/([0-9]{1,4}) werden die drei Zahlengruppen extrahiert.

Dies erscheint mir fehlerhaft für das Beispiel "10/10/1999"

nicht besser ist ([0-1]?[0-9])\/([0-3]?[0-9])\/([0-9]{1,4}) denn das erlaubt "0/0/1999" ich denke nochmal nach (nicht signierter Beitrag von 84.134.254.122 (Diskussion) 12:02, 6. Sep. 2015 (CEST))

gudn tach!

ja, das pattern ist so (mit [1-9]) eigentlich eher unbrauchbar. deine verbesserung (zusammen mit der einschraenkung, dass die jahreszahl 4-stellig sein soll, was in den meisten faellen sinnvoll ist) ist aber fuer das beispiel imho hinreichend. hab ich nun auch so im artikel umgesetzt.

ein richtiger datums-check, der auch schaltjahre und weitere eigenheiten beruecksichtigt, waere zwar mit regulaeren ausdruecken durchaus moeglich, aber sehr lang und haesslich. als simples beispiel waere das ungeeignet.

fuer simple konvertierungen reicht in vielen faellen das obige (korrigierte) pattern, wenn man gewisse anforderungen an den text stellen darf/kann. -- seth 19:02, 6. Sep. 2015 (CEST), 00:07, 7. Sep. 2015 (CEST)

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich  ✉  16:53, 6. Mär. 2022 (CET)

Beispiele "unter anderem"

Unter Beispiele heißt es: Wenn das Alphabet aus den Buchstaben a , b und c besteht, also Σ = { a , b , c } , dann lassen sich die folgenden Sprachen mit den entsprechenden regulären Ausdrücken beschreiben: Die angegebenen "folgenden Sprachen" erwecken den Eindruck als ob sich c anders als a und b verhielte. Deshalb denke ich sollte es besser lauten: Wenn das Alphabet aus den Buchstaben a, b und c besteht, also Σ = { a , b , c }, dann lassen sich unter anderem die folgenden Sprachen mit den entsprechenden regulären Ausdrücken beschreiben: --TumtraH-PumA (Diskussion) 17:43, 22. Mär. 2018 (CET)

Binärzeichen

Ich finde "binär" im ganzen Artikel nicht, würde aber einfach gerne mal direkt Binärzeichen mit grep finden können, z.B. ... -- itu (Disk) 11:30, 12. Dez. 2019 (CET)

Es gibt viele Dialekte des RegExp und auch in der ux-Welt ist nicht immer jedes grep gleich schlau.

Viele verstehen: \u1234

Viele erlauben den Einbau direkt, notfalls in [ ] als Einzelzeichen eingeschlossen.

Es kann sein, dass bestimmte ux-Kommandozeilen bei bestimmten höherwertigen oder mit Sonderbedeutung belegten Binärcodes das anders interpretieren.

„Binär“ ist in diesem Sinn keine Eigenschaft des RegExp als solchem, sondern ein dialekt- und umgebungsabhängiges Kodierungsproblem, und insofern fehlt dem Artikel eigentlich nix.

VG --PerfektesChaos 13:55, 12. Dez. 2019 (CET)

Was grep betrifft ist nach leidlicher Suche, jetzt der einzige Lichtblick der Parameter -P mit dem \123 und \x12 funktionieren. -- itu (Disk) 15:14, 12. Dez. 2019 (CET)

LUA

WP verwendet intensiv Lua. Dennoch fehlt hier jeglicher Hinweis auf die abweichende Syntax, insbesondere Einsatz von % statt \--Klaus-Peter (^aufund_davon) 06:50, 9. Jul. 2020 (CEST)

Soll das ernsthaft eine Erklärung sein??

Moin.

Da ich aus beruflichen Gründen wissen müsste was eine Regular Expression ist hab ich hier mal rein geschaut. Noch abschreckender geht es ja wohl kaum! Selbst als Elektroingenieur (ok, Anfang der 90er abgeschlossen) könnte das genau so gut in Chinesisch geschrieben sein. Ein Programmierer mag das verstehen, für jemand dessen täglich Brot das nicht ist handelt es sich hier (m.E. nach) um Datenmüll! Ich kann nicht nachvollziehen, warum Moderatoren so was nicht als Löschkandidat betrachten.

Schade eigentlich, ich dachte immer Wikipedia wäre für die Allgemeinheit gedacht und nicht für Randgruppen! (nicht signierter Beitrag von 193.24.32.57 (Diskussion) 09:09, 3. Mär. 2022 (CET))

Was genau meinst du? Den ersten Satz, die Einleitung oder allgemein den ganzen Artikel. Bitte konkret sagen was nicht passt.

Moderatoren haben in der Wikipedia übrigens nichts mit Löschen zu tun und Löschkandidaten entstehen nicht dadurch, dass der Text unverständlich ist. Aber egal - bitte wie gesagt um konkrete Kritik und nicht abstrakte. --Sebastian.Dietrich  ✉  15:46, 3. Mär. 2022 (CET)

Im ersten Satz erfährt man, dass es sich um ein Konzept aus der theoretischen Informatik handelt, im zweiten Satz steht, dass diese Technik in der Softwareentwicklung Anwendung findet. Das ist bereits eine wesentliche Information und sollte bei der Entscheidung helfen, ob man den Artikel überhaupt weiterlesen mag oder nicht. Im dritten und vierten Satz (immer noch im ersten Abschnitt) erfährt der Leser, dass Reguläre Ausdrücke höchstwahrscheinlich sogar in seinem Texteditor beim Suchen und Ersetzen verwendbar sind. Das könnte ihn motivieren, weiterzulesen.

Für alles Folgende gilt Einsteins Satz „Man sollte alles so einfach wie möglich machen, aber nicht einfacher.“ --Mosmas (Diskussion) 17:44, 4. Mär. 2022 (CET)

Wie meine Vorherigen Schreiber betonen ...

Ich bin schon seit mehr als 40 Jahren Programmiere.

Habe schon sehr viele Handbücher zu Programmiersprachen gelesen.

Im Vordergrund dieses Artikels steht der Wissenschaftlich - Mathematische Ansatz, den ich nur am Rande etwas Versthe.

Als Progrmmammierer scrolle ich gleich runter bis zum Abschnitt "Ein Zeichen aus einer Auswahl".

Ab hier erst fange ich an zu lesen und zu verstehen. (nicht signierter Beitrag von Jens.Geier.1968 (Diskussion | Beiträge) 11:09, 6. Mär. 2022 (CET))

{{Erledigt|1=--[[Benutzer:Sebastian.Dietrich|Sebastian.Dietrich]] [[Benutzer Diskussion:Sebastian.Dietrich| ✉ ]] 16:53, 6. Mär. 2022 (CET)}}

Ich bin nicht der Meinung, dass sich diese Diskussion erledigt hat. Hier geht es um die Verständlichkeit des Artikels, und die darf gerne mal in Frage gestellt werden. --Mosmas (Diskussion) 23:12, 6. Mär. 2022 (CET)

Ok gerne - aber die IP hat sich bislang nicht dazu geäußert, was für sie unverständlich ist. Also gehts hier mMn nicht um "die Verständlichkeit des Artikels".--Sebastian.Dietrich  ✉  07:43, 7. Mär. 2022 (CET)

Vielleicht warten wir einfach noch ein paar Tage. Wenn dann niemand den Thread aufnimmt, schieben wir ihn ins Archiv. --Mosmas (Diskussion) 14:00, 7. Mär. 2022 (CET)

Dieser Abschnitt kann archiviert werden. Mosmas (Diskussion) 16:17, 30. Mär. 2022 (CEST) (da keine weiteren Beiträge folgten, siehe Disk oben)