Diskussion:Robustheit

Beispiel

Das Beispiel passt nicht sehr gut zu der Definition von "Robustheit". Schliesslich ist der Fall, dass ein Name bei einer linearen Suche erst gegen Ende der Liste (etwa innerhalb der letzten 10%) angetroffen wird, weder ein "seltenes Vorkommnis" noch eine "Fehlersituation", sondern schlicht die Regel. Es handelt sich hier also vielmehr um einen extrem ineffizienten Algorithmus als um einen mit zu geringer Robustheit. In einer Beziehung besitzt er im Gegenteil sogar ein Maximum an Robustheit: Bei falsch eingeordneten Eintraegen oder leicht falsch geschriebenen Namen (wenn die Korrelation berechnet wird) fuehrt nur die lineare Suche zum besten (sicheren) Erfolg. --132.199.98.122 14:59, 21. Aug 2006 (CEST)

Verstehe ich nicht. Nach der Definition im Artikel spielt es keine Rolle, ob der Worst Case haeufig oder selten eintritt. Der Worst Case fuehrt zur Unbenuzbarkeit und daher ist ein Verfahren nicht robust. Du darfst Dir aber gerne ein besseres Beispiel einfallen lassen und es verstaendlich erklaeren. Gruss -- sparti 23:11, 22. Aug 2006 (CEST)

Was wuerde man denn bei diesem Beispiel als Worst Case definieren? Wenn der Name an der 1.000.000-sten Stellen steht oder bei 900.0000 oder schon an der 100. Stelle, weil selbst bis dahin jeder halbwegs vernuenftige Algorithmus "zuegiger und ebenso korrekt" arbeiten wuerde? Worst Case bezeichnet durchaus ein seltenes Ereignis, hier ist es aber die Regel, waehrend der "nicht-Worst-Case" die absolute Ausnahme darstellt. Das Beispiel schildert nur einen extrem langsamen Algorithmus, mit Fehlertoleranz, die die Haupteigenschaft von Robustheit darstellt, hat dieser aber rein gar nichts zu tun. --89.51.245.67 00:23, 24. Aug 2006 (CEST)

Voelliger Unsinn. Worst Case ist der schlechteste Fall, der bei einem Algorithmus auftreten kann. Mit der Haeufigkeit des Auftretens hat das nichts zu tun. -- sparti 12:25, 24. Aug 2006 (CEST)

Schade, dass Du auf meine Beitraege nicht eingehst. Wo ist denn nun die Grenze fuer den Worst Case? Bei >999.999? Wuerdest Du die lineare Suche darunter dann als robust bezeichnen? Du scheinst die Schnelligkeit von Algorithmen mit Robustheit zu verwechseln. --89.51.232.149 13:09, 24. Aug 2006 (CEST)

Naja, ich glaube ich verstehe Deine Frage nicht. Es gibt keine Grenze fuer den Worst Case. Der Worst Case ist eine Formel, die mir sagt, was im aller, aller schlimmesten Fall passieren kann. Robustheit sagt, dass dass mein Verfahren auch dann noch brauchbar ist. Das ist aber eine subjektive Sache. Bei Webservern muss ein Verahren innerhalb von wenig 100ms antworten, oder der Benutzer wird ungeduldig. Bei einem OLAP System nimmt schon mal ein paar Stunden fuer eine Antwort hin. Mal ganz plakativ: Wenn mein Worst Case innerhalb dieser Grenzen liegt, ist mein Verfahren robust.

Um das nochmal etwas zu verdeutlichen. Eine optimale Hashtabelle anwortet im Worst Case O(1). In der Praxis wird man aber nur wenige optimale Hashtabellen finden. Eine entartete Hashtabelle kann theoretisch einen Worst Case von O(n) haben. Das ist aber zB. in Datenbanken nicht hinnehmbar. Das heisst eine Hashtabelle ist nicht robust. -- sparti 14:51, 24. Aug 2006 (CEST)

Du scheinst mich tatsaechlich nicht zu verstehen. Zumindest finde ich Dein Beispiel mit der Hashtabelle sehr viel besser. Es handelt sich um einen per se schnellen Algorithmus, wobei als extrem seltenes Ereignis eine n-fache Kollision auftreten kann. Falls dieses Ereignis nicht durch ein weiteres Suchverfahren innerhalb der Tabellenbehaelter abgesichert ist, mag es der Methode zumindest in Bezug auf zuverlaessige Schnelligkeit an Robustheit fehlen. Nichtsdestotrotz halte ich die lineare Suche, die in mathematischer Strenge vielleicht ebenfalls fuer fehlende Robustheit stehen mag, fuer ein ziemlich schlechtes Beispiel. Wenn ich einen per se extrem ineffizienten Algorithmus programmiere, werde ich mir ueberhaupt keine Gedanken ueber Robustheit machen, da bereits bei ceil((log(1)-log(10^6))/log(2))=20 Eintraegen die Methode der Intervallhalbierungen immer schneller ist. Auf der anderen Seite gibt es keinen robusteren Algorithmus gegen falsch sortierte Namen als eben die lineare Suche (so herum waere das Beispiel auch gut). --89.51.245.13 18:21, 24. Aug 2006 (CEST)

Junge, Du nervst. Hier gehts nicht darum den effizientesten Algorithmus zu finden. Sondern darum ein Beispiel fuer ein nicht robutes Verfahren zu zeigen. Intervallhalbierung auf einer sortieren(!) Liste ist dafuer eben nicht geeignet. Im uebrigen hast Du nicht den blassen Schimmer von extrem ineffizent. Eine lineare Suche laesst sich manchmal garnicht vermeiden und ein Aufwand von O(n) ist durchaus ertraeglich. Aber diese Diskussion gehoert hier nicht hin. Aus und Ende. -- sparti 12:15, 25. Aug 2006 (CEST)

Danke fuer die freundlichen Worte. Gut dass ich meine aktive Mitarbeit bei Wikipedia vor laengerer Zeit einstellte. Es gibt zuviele Leute hier, die diskutieren, ohne die Diskussion wirklich zu beherrschen. --132.199.98.122 14:58, 25. Aug 2006 (CEST)

Schlechtes Beispiel: Robustheit

Der Worst Case ist nicht wenn der gesuchte Name an der letzter Position steht. Sondern wenn der Name gar nicht in der Liste enthalten ist. Wenn nun der Algorithmus lautet: "Suche die Position Gesuchter Name = Eintrag", so würde der Algorithmus nie enden. Robustheit bedeutet, dass ein Algorithmus auch Ausnahmefälle beachtet und darauf zu reagieren weiß. Z.B. sich beendet und eine verständliche Meldung ausgibt. "Name konnte nicht gefunden werden". Mein Vorschlag ist dass Beispiel für Robustheit anzupassen.

Ja, Robustheit deckt beides ab. Sowohl den Worst Case als auch die Behandlung von Ausnahme Faellen. Dahin gehend ist das Beispiel wirklich schlecht, da der Algorithmus durchaus nicht unendlich läuft, auch dann nicht, wenn das gesucht Element nicht existiert.

Hast Du eine konkrete Idee für ein Beispiel, das leicht zu verstehen ist und beide Extremfaelle gut darstellt? -- sparti 13:35, 6. Jun. 2007 (CEST)

Ich bin kein Informatiker, sondern Maschinenbauer. Für mich (und die Begriffswelt des Design for Six Sigma) wäre der Algorithmus robust, wenn er bei Schwankungen und Störungen der Eingangsgrößen immer noch ein gutes Ergebnis liefert, also z.B. Groß- und Kleinschreibung, Tippfehler (vgl. Google: "Meinten Sie ...?") o.ä. toleriert. Wie passt das mit euren Definitionen zusammen? Das Beispiel der Linearen Suche ist m.E. geeignet, um Effizienz/Effektivität zu erklären, aber nicht Robustheit.

--pjt56 11:38, 10. Aug. 2008 (CEST)

Das Beispiel 'Telefonbuchsuche' ist tatsächlich ungeeignet: Wenn man die Qualitätskriterien für Software zugrundelegt, dann steht dort anstelle von 'Robustheit' der Begriff 'Fehlertoleranz', und zwar innerhalb der Kategorie 'Zuverlässigkeit'. Ein (externer) Fehler liegt aber im Beispiel nicht vor, insofern kann Robustheit auch nicht zutreffen.
Ein Ergebnis in kürzestmöglicher Zeit zu liefern, gehört dort in die Kategorie 'Effizienz', Kriterien 'Zeitverhalten' und 'Verbrauchsverhalten'. Also: Ich werde das Beispiel in Kürze ersetzen.--VÖRBY (Diskussion) 15:55, 6. Feb. 2013 (CET)

Hab den Text unter 'Informatik' aktualisiert, d.h. mit Quellen Belegt und das Beispiel ersetzt. Ggf. kann 'man' es bei Effizienz (Informatik) verwenden. --VÖRBY (Diskussion) 13:27, 7. Feb. 2013 (CET)

Definition

Die alte Definition war für mich wenig verständlich. Ich habe sie durch eine eigene ersetzt, die sich u.a. auf die englische Wikipedia und Taguchi stützt. Ansonsten hat Google nichts verwertbares geliefert. Falls jemand eine bessere Definition findet, diskutiere ich gerne mit (hier oder auf meiner eigenen Diskussionsseite).

--pjt56 22:08, 10. Aug. 2008 (CEST)

Falsche Kategorie

Der Artikel steht in der Kategorie Regelungstheorie. Trotzdem ist in dem Artikel nichts zur Regeluntstechnik geschrieben. Dafür gibt es den Artikel Robuste Regelung. Ich wäre dafür, die Kategorie Regelungstheorie aus diesem Artikel zu löschen. -- Clupus (Diskussion) 12:08, 1. Dez. 2012 (CET)

Zustimmung. GEEZER^{Spenden !? Spenden !!} 12:16, 1. Dez. 2012 (CET)