warum wird man eigentlich nie eine fehlerfreie komplexe software haben ?
-
ist bewiesen, daß, wenn man oft genuf würfelt, eine 6 dabei ist?
ja, für praktische belange ist es sinnvoll, anzunehmen, daß jedes größere programm fehler hat.
-
welches pc spiel mit einer ki basiert nicht darauf ?
aber tatsache ist auch das man mit einem programm keinen 100% zufall erzeugen kann@volkard: da die wahrscheinlichkeit für eine 6 nicht gleich 0% ist, ist es bewiesen ( laut definition )
-
DEvent schrieb:
welches pc spiel mit einer ki basiert nicht darauf ?
aber tatsache ist auch das man mit einem programm keinen 100% zufall erzeugen kannhäh? Ich kenne nicht viele Spiele, bei denen die KI durch Versuch und Irrtum lernt.
-
DEvent schrieb:
@volkard: da die wahrscheinlichkeit für eine 6 nicht gleich 0% ist, ist es bewiesen ( laut definition )
Du schaust dir deine Stochastiksachen am besten nochmal ganz genau an. Die Wahrscheinlichkeit, dass man nach N Versuchen mindestens einmal eine 6 gewürfelt hat ist nicht 1. Auch wenn N noch so groß ist.
And now for something completely different ...
Was ist überhaupt ein Fehler? Wenn das Programm nicht das tut was es soll, also eine Abweichung des Verhaltens von der Spezifikation vorliegt. Aber für welches Programm liegt schon eine 100%ig wasserdichte Spec vor? Ohne sowas ist schon der Begriff der Fehlerfreiheit so schwammig, dass man darüber kaum noch sinnvolle Aussagen machen kann.
Der Weg kann aber natürlich auch nicht dahin führen, jetzt auf Deibel komm raus exakte formale Spezifikationen zu schreiben, bevor man codet. Specs wachsen ja leider nicht auf Bäumen. Irgendwer muss eine Spezifikation auf höherer Abstraktionsebene haben, und diese in eine detailliertere überführen. IMHO ist das auch schon programmieren. Dieser Prozess ist offensichtlich rekursiv. Wo brechen wir das ganze ab? Gibt es eine passende, noch abstraktere Über-Spezifikation, deren Korrektheit offensichtlich ist (also ein Axiom)?
-
Was ist überhaupt ein Fehler?
was ist richtig, und was ist falsch?
//edit jaja ich weis, en bissl trollig das ganze, aber was ich damit sagen will: ein Fehler kann nur dort auftreten, wo richtig von falsch getrennt ist, dafür muss man aber erstmal wissen, was die beiden sachen bedeuten.
-
otze schrieb:
Was ist überhaupt ein Fehler?
//edit jaja ich weis, en bissl trollig das ganze, aber was ich damit sagen will:
Eher philosophisch. Oder ist das etwa das gleiche? Uiuiui....
-
DEvent schrieb:
Online schrieb:
ich finde dieses Wort niemals sollte verboten werden! Wie willst du beweisen, das etwas niemals gehen wird?
vollständige induktion ?
2^n ist immer untermenge von n^2 ( musste ich schon 2 semenster in meinem studium beweisen )...
Ok, na dann stopf mal den Zufall in eine Gleichung und versuch zu beweisen das ein komplexes Program niemals fehlerfrei sein kann.
Für Berechnungen in der Natur kannst du nur ne annährung machen aber du wirst nie wirklich ne exakte Lösung bekommen weil du die ganze Natur verstehen müsstest, alles aber wenn du irgendwann mal die ganz Natur genau verstehst dann kannst du natürlich auch den alles berechnen weli du jede Streung kennst.Fazit: ich kann (noch) nicht beweisen das es fehlerfrei geht und du kannst nicht beweisen das es die möglichkeit nicht geben wird etwas fehlerfrei darzustellen.
ich kann mich auf die Zukunft berufen und du kannst nur von der Vergangenheit sprechen.
-
Bashar schrieb:
Was ist überhaupt ein Fehler? Wenn das Programm nicht das tut was es soll, also eine Abweichung des Verhaltens von der Spezifikation vorliegt. Aber für welches Programm liegt schon eine 100%ig wasserdichte Spec vor? Ohne sowas ist schon der Begriff der Fehlerfreiheit so schwammig, dass man darüber kaum noch sinnvolle Aussagen machen kann.
Danke. Alle diskutieren fröhlich rum und du machst mit einem einzigen Hammerschlag alles kaputt.
-
volkard schrieb:
HumeSikkins schrieb:
weil es statisch gesehen wahrscheinlich ist, dass wenn n Leute m Vorstellungen von einem Problem p haben und dieses mittels eines Prozesses q, den sie aus einem Buch b haben und auf i verschiedene Weisen interpretieren, in eine Lösung l transformieren,
ahso, sobald die wahrscheinlichkeit für einen fehler über 98% liegt, postulierst du die existenz dessen.
Wo ist das Problem? In vielen Bereichen der Computerei ist alles unwahr, was nicht explizit aus der Wissensbank als wahr hergeleitet werden kann (das Busfahrplan-Beispiel).
Solange du nicht beweisen kannst, dass deine Software fehlerfrei ist, kannst du nur annehmen, dass sie das ist. Da es in der Vergangenheit aber bisher keine Beispiele für komplexe und gleichzeitig fehlerfreie Software gegeben hat, erscheint mir eine solche Annahme blauäugig zu sein.Ansonsten passt auf diese Thematik imo Fred Brooks' "No Silver Bullet" bzw. "No Silver Bullet ReFired" wie die Faust auf's Auge.
-
@ volkard - nein mein Lieber , das ist mir zu pauschal und undurchdacht.
Du kannts mir nicht erzählen, das Du eine Software von mehreren hunderttausend Programmzeilen schreiben kannst, die felerfrei ist.
Das geht IMHO nicht, weil Du die Anforderungen, welche die Software erfüllen soll ja garnicht in allen Anwendungsbereichen durchdenken kannst. Das ist doch schier unmöglich alle möglichen Möglichkeiten durchzudenken und diese logisch fehlerfrei umzusetzen, weil dein Erfahrungshintergrund garnicht ausreichen kann bei dieser Menge an Komplexität.( P.S. deine rechtschreibung lässt schon viel vermuten
)Ich glaube das alle Formalem Methoden nichts taugen. sie stellen nur immer eine Anäherung an eine gewisse Wahrscheinlichkeit dar.
IMHO sind wir durch unser begrenztes Denken nicht imstande diese Aufgabe zu lösen.
und ich meine Fehler, also logische Fehler in der Programmierung sind eine Art
mutatio die eine gewisse Nützlichkeit hat, sozusagen im evolutionären Prozess, also notwendig ist, weil Neuerungen , Anpassungen nur so möglich sind .danke an @otimizer und @ bashar -- die meinung teile ich voll...
-
vost schrieb:
@ volkard - nein mein Lieber , das ist mir zu pauschal und undurchdacht.
...besser unduchdacht,
Du kannts mir nicht erzählen, das Du eine Software von mehreren hunderttausend Programmzeilen schreiben kannst, die felerfrei ist.
...als nichtmal das thema kapiert haben.
ich sage nicht, daß jedes hunderttausend-zeilen-programm korrekt sei. nichtmal, daß es ein korrektes zur zeit gibt. ich sage nur, daß keiner beweisen kann, daß es unmöglich sei. und zwar, weil es (wenn auch mit einer für praktische belange viel zu geringen wahrscheilnichkeit) möglich ist.
würde deine dumme these richtig sein, daß jedes hunderttausen-zeilen-programm mindestens einen fehler hat, dann hätte doch auch jedes um diesen fehler bereinigte hunderttausenzeilenprogramm mindestens einen fehler. ad infinitum. also hätte jedes hunderttausenzeilenprogramm entweder unendlich viele fehler. ad absurdum. mit dem ausweg, daß es beweisbar unfindbare fehler gibt. das ist aber harter tobak. willste diese these wirklich haben?
-
Bashar schrieb:
Was ist überhaupt ein Fehler? Wenn das Programm nicht das tut was es soll, also eine Abweichung des Verhaltens von der Spezifikation vorliegt.
echt? ok, das nehme ich mal an.
Aber für welches Programm liegt schon eine 100%ig wasserdichte Spec vor? Ohne sowas ist schon der Begriff der Fehlerfreiheit so schwammig, dass man darüber kaum noch sinnvolle Aussagen machen kann.
falsch. man kann nicht durch aufzeigen von zusätzlichen fehlerquellen gleich alle fehler wegdiskutieren.
es gibt auch harte fehler, speicherschutzverletzungen, divisionen durch 0, wurzeln aus negativen zahlen, speicherlöcher, endlosschleifen und dergleichen mehr. es gibt auch echte abweicheungen von der spec, die selbst bei freundlichster betrachtung einfach als abweichung zu sehen sind. wenn das auto 5 rückwärtsgänge hat, ist da ein fehler. nicht wegdiskutierbar mit dem hinweis, daß die spec über den innenverstellbaren ausßenspiegel schwammig ist, weil nicht spezifiziert wurde, was innen und was außen ist.
man kann also nicht nur "kaum noch" sinnvolle aussagen machen. ich beschränke mich gerne auf harte fehler.denk doch mal zurück. anno win31 hätten viele leute min inbrunst (und dem hilfssatz der sicheren 6) bewiesen, daß jede in c geschriebene anwendung ab einer gewissen größe ein speicherloch haben muss.
Der Weg kann aber natürlich auch nicht dahin führen, jetzt auf Deibel komm raus exakte formale Spezifikationen zu schreiben, bevor man codet. Specs wachsen ja leider nicht auf Bäumen. Irgendwer muss eine Spezifikation auf höherer Abstraktionsebene haben, und diese in eine detailliertere überführen. IMHO ist das auch schon programmieren. Dieser Prozess ist offensichtlich rekursiv. Wo brechen wir das ganze ab? Gibt es eine passende, noch abstraktere Über-Spezifikation, deren Korrektheit offensichtlich ist (also ein Axiom)?
naja, der airbus darf nicht runterfallen. die sonde soll auf dem mars landen. der erkundungsroboter soll auf dem mars rumlaufen und zurückkommen. die ariane soll bis ins orbit kommen. die challenger soll nicht explodieren. der astra soll nicht brennen.
alles verflixt einfache spezifikationen, wo man prüfen kann, ob sie eingehalten wurden.
-
volkard schrieb:
Bashar schrieb:
Was ist überhaupt ein Fehler? Wenn das Programm nicht das tut was es soll, also eine Abweichung des Verhaltens von der Spezifikation vorliegt.
echt? ok, das nehme ich mal an.
Bessere Idee?
Aber für welches Programm liegt schon eine 100%ig wasserdichte Spec vor? Ohne sowas ist schon der Begriff der Fehlerfreiheit so schwammig, dass man darüber kaum noch sinnvolle Aussagen machen kann.
falsch. man kann nicht durch aufzeigen von zusätzlichen fehlerquellen gleich alle fehler wegdiskutieren.
Hab ich nicht behauptet.
es gibt auch harte fehler, speicherschutzverletzungen, divisionen durch 0, wurzeln aus negativen zahlen, speicherlöcher, endlosschleifen und dergleichen mehr. es gibt auch echte abweicheungen von der spec, die selbst bei freundlichster betrachtung einfach als abweichung zu sehen sind.
Klar. Was ändert das an der Aussage, dass die Fehlerfreiheit schwammig ist?
man kann also nicht nur "kaum noch" sinnvolle aussagen machen. ich beschränke mich gerne auf harte fehler.
Folgende Implementation meines Textverarbeitungsprogramms ist frei von harten Fehlern:
int main() { }
-
Nein, ist sie IMHO nicht, da sie nachweisbar selbst gröbste und ungenaueste Spezifikation bzgl. eines Textverarbeitungsprogramms nicht erfüllt.
Mit Volkards Definition
[...] es gibt auch echte abweicheungen von der spec, die selbst bei freundlichster betrachtung einfach als abweichung zu sehen sind
von "harten Fehlern" ist dieses Programm IMHO eindeutig als Fehlerhaft anzusehen, weil es klar die Anforderungen an einer Textverarbeitung nicht erfüllt und diese Funktionalität offensichtlich nicht bietet.
"Freundlich" ist ein schwammiger Begriff, deshalb stimme ich dir mit dem Spezifikationsproblem schon zu. Es ist wohl nicht leicht, nachzuweisen, dass ein Programm exakt die Spezifikationen befolgt, wenn es nicht/kaum möglich ist, 100%ig eindeutige Spezifikationen zu schreiben. Man kann allerdings in einigen Fällen sehr wohl sagen, dass eine Spezifikation nicht erfüllt ist.
Es ist wie mit den Fehlern selber. Man kann nie wirklich die Fehlerfreiheit garantieren wenn alles läuft, aber wenn ein Fehler entdeckt ist, kann man mit Sicherheit sagen, dass es ein Fehler ist.
-
Hi,
[quote="volkard]
ich sage nicht, daß jedes hunderttausend-zeilen-programm korrekt sei. nichtmal, daß es ein korrektes zur zeit gibt. ich sage nur, daß keiner beweisen kann, daß es unmöglich sei. und zwar, weil es (wenn auch mit einer für praktische belange viel zu geringen wahrscheilnichkeit) möglich ist.
[/quote]also wenn ich das richtig sehe, behauptest du, es gibt unter umständen fehlerfreie 100000-zeilen programme. das kann ja auch durchaus so sein, keiner wird dir das gegenteil beweisen können, genausowenig aber kannst du zeigen, dass eben dieses programm fehlerfrei ist. testen zeigt niemals die abwesenheit von fehlern, und außer testen hat man ja wohl keine chance. einen beweis führen wie in der mathematik geht nicht, dafür fehlen die grundlagen, wo fängt man an mit dem beweis?! testen ist ja immer endlich, ein beweis muss für alle gelten. das problem ist, würd ich sagen, nicht, das software nicht per se fehlerbehaftet ist, sondern das es einfach nicht möglich ist, das gegenteil zu zeigen.
-
volkard schrieb:
würde deine dumme these richtig sein, daß jedes hunderttausen-zeilen-programm mindestens einen fehler hat, dann hätte doch auch jedes um diesen fehler bereinigte hunderttausenzeilenprogramm mindestens einen fehler. ad infinitum. also hätte jedes hunderttausenzeilenprogramm entweder unendlich viele fehler. ad absurdum. mit dem ausweg, daß es beweisbar unfindbare fehler gibt. das ist aber harter tobak. willste diese these wirklich haben?
Ja ! das würde ich gerne lesen !
Dumme These hin und her: Fehlerhaftigkeit ist nicht beweisbar.
Hinzu kommt ja noch eine weitere latente Fehlerquelle: der Compiler , ist doch auch nur eine Software, und wer sagt mir, dass da alles 100% korrekt läuft.
Aber es wurde hier schon oft gesagt, die Spezifikationen sind IMHO eigentlich der Kern des Problems. Denn allein die Komplexität der zu spezifizierenden Probleme, der Interaktion der Softwarelösung in der umgebenden Organisation, die Komplexität der kognitiven Erfassung der vom Computer verarbeitbaren Information durch den Menschen und ergo damit grundlegenden Umgangs mit Software und die Komplexität des Herstellungsprozesses in vielerlei Hinsicht sind nicht fehlerfrei, bzw. werden immer anders interpretiert durch das Subjekt. Das sind IMHO die wesentlichen Probleme die dazu führen das eine fehlerfreie, also den Anforderungen und Handhabungen 100%ige Software eigentlich nicht möglich ist.
Wie gesagt, ich will jetzt nicht auf die formalen Methoden der Prüfbarkeit der SW auf Fehler eingehen, das sind ja auch nur immer Annäherungen.
Ich bin der meinung,dass keine exakten Vorhersagen über das Verhalten von diskreten Systemen getroffen werden können und es kein Skalierungsargument ghibt dass diese Eigenschaft erfassen kann? Keines, eher die Chaos Theorie, doch auch diese beruht nur auf der Beschreibbarkeit solcher Systeme durch Differentialgleichungen, was aber widerum für Programmsysteme nicht ausreicht.
Eigentlich ein Dilema ..?!Völlig untergegangen sind die Nichtdeterministischen Fehler.
Welche Rolle spielen sie dabei? Axiome fiel als stichwort, aber wie wollen wir diese algorithmischen möglichkeiten in Axiome erfassen und wer überprüft sie auf ihre Richtigkeit. Und gelten diese axiome noch in 10 , 20 , 100 Jahren. Würde das aber nicht Entwicklungen hemmen??Zwischenfazit: eine interessante Diskussion bisher . Danke an Alle
-
Optimizer schrieb:
Mit Volkards Definition
[...] es gibt auch echte abweicheungen von der spec, die selbst bei freundlichster betrachtung einfach als abweichung zu sehen sind
von "harten Fehlern" ist dieses Programm IMHO eindeutig als Fehlerhaft anzusehen, weil es klar die Anforderungen an einer Textverarbeitung nicht erfüllt und diese Funktionalität offensichtlich nicht bietet.
nein, das war nicht mit "hart" gemeint, sondern echt nur sachen wie abstürze.
"Freundlich" ist ein schwammiger Begriff
der begriff ist nicht "hart".
-
mata schrieb:
also wenn ich das richtig sehe, behauptest du, es gibt unter umständen fehlerfreie 100000-zeilen programme. das kann ja auch durchaus so sein, keiner wird dir das gegenteil beweisen können, genausowenig aber kannst du zeigen, dass eben dieses programm fehlerfrei ist.
ok.
damit ist die ursprüngliche frage "warum wird man eigentlich nie eine fehlerfreie komplexe software haben" kaputt, oder?
ich will nicht, daß es als sicher angenommen wird, man könne nie und nimmer fehlerfrei coden.
und für die general-vermutung, ein programm habe auch fehler, hab ich mich ja auch schon ausgesprochen. in allen praktischen belangen ist die ok. man darf es nur nicht als sicher annehmen, sonst kommt man in die teufelsküche.
-
volkard schrieb:
...und für die general-vermutung, ein programm habe auch fehler, hab ich mich ja auch schon ausgesprochen. in allen praktischen belangen ist die ok. man darf es nur nicht als sicher annehmen, sonst kommt man in die teufelsküche.
warum komme ich dann in teufelsküche? weil ich dann die SW in Frage stelle und mich auch. Das tue ich doch ohnhin.
-
Nein, das Problem ist, daß Du mit dieser Aussage schließen kannst, daß jedes 100000-Zeilen-Programm unendlich viele Fehler hat. Mach einen raus, das Programm bleibt ungefähr so lang wie es ist... also hat es einen Fehler etc.
Vielleicht kann man das aber heilen, indem man annimmt, daß man gelegentlich beim bufixen wieder was dazubaut.
Ich kann mir gut vorstellen, daß die Fehlerzahl in großen Softwaresystemen trotz regelmäßigen Bugfixings ab einer bestimmten Stelle konstant bleibt. Einfach weil es so kompliziert ist, daß man Fehler schlecht entfernen kann ohne neue zu machen