Mathematik in Informatik erforschen [geschlossen]

Ich denke, es gibt ein paar Gründe dafür. Zum einen ist es in vielen Fällen wichtiger, die Aufgabe zu erledigen, als sie so gut wie möglich zu machen. Eine Menge Software, die ich schreibe, ist eine Sache, die nur gelegentlich auf kleinen Datensätzen ausgeführt wird, oder solche, bei denen die Implikationen der Performance ziemlich trivial sind (es ist eine Schleife, die eine feste Berechnung an jedem Element durchführt, also ist es einfach O (n) ). Für die meisten dieser Software wäre es albern, Zeit damit zu verbringen, die Laufzeit im Detail zu analysieren.

Ein weiterer Grund ist, dass Software später leicht geändert werden kann. Sobald Sie eine Bridge erstellt haben, können alle Fixes unglaublich teuer sein. Daher ist es sehr wichtig, sich vor der Ausführung Ihres Entwurfs zu vergewissern. In der Software können Sie Performance-Hotspots im Allgemeinen finden und optimieren, wenn Sie nicht bereits eine schreckliche Architekturentscheidung getroffen haben. Um diese schrecklichen architektonischen Entscheidungen zu vermeiden, können Sie im Allgemeinen ungefähre Berechnungen auf der Rückseite des Umschlags durchführen (stellen Sie sicher, dass Sie keinen O (2 ^ n) -Algorithmus für einen großen Datensatz verwenden und schätzen Sie innerhalb eines Faktors von 10 oder so, wie viele Ressourcen Sie für die schwerste Last benötigen, die Sie erwarten). Diese erfordern einige Analysen, aber in der Regel kann es ziemlich schnell und aus dem Schneider sein.

Und dann gibt es Fälle, in denen Sie wirklich, wirklich die ultimative Leistung aus einem System herauspressen müssen. In diesen Fällen setzen sich die Menschen häufig hin, erarbeiten die Leistungsmerkmale der Systeme, mit denen sie arbeiten, und führen sehr detaillierte Analysen durch. Zum Beispiel Ulrich Dreppers sehr eindrucksvolles Papier Was jeder Programmierer über das Gedächtnis wissen sollte (pdf) .

Denken Sie über die Ingenieurwissenschaften nach, sie haben alle sehr gut definierte Gesetze, die auf das Design und den Aufbau von physischen Dingen, wie Schwerkraft, Festigkeit von Materialien etc. anwendbar sind. Während in der Informatik nur wenige gut definiert sind Gesetze, wenn es darum geht, eine Anwendung gegen.

Ich kann mir viele verschiedene Möglichkeiten vorstellen, ein einfaches Hallo-Welt-Programm zu schreiben, das die Anforderung erfüllt. Wenn ich jedoch einen Strommast bauen muss, bin ich stark eingeschränkt durch die physische Welt und die Anforderungen des Pols.

Punkt für Punkt

1. Ein Strommast muss dem Wetter, einer Last, Korrosion usw. widerstehen und diese können quantifiziert und modelliert werden. Ich kann den Erfolg meiner Website-Einführung nicht quantifizieren oder wie meine Datenbank wachsen wird.

2. Vorzeitige Optimierung? Gut genug ist genau das, reparieren Sie es bei Bedarf. Wenn Sie ein Anbieter sind, haben Sie keine Ahnung, wie Ihr Code im realen Leben ausgeführt wird oder wie er konfiguriert ist. Wieder können Sie es nicht quantifizieren.

3. Vorzeitige Optimierung

4. Siehe Punkt 1. Ich kann nach Bedarf hinzufügen.

Mach weiter ... sogar Ingenieure bollix up. Kollapsbrücken, Verdunkelung, Auto-Sicherheit erinnert, "falsche Art von Schnee" usw. etc. Sollen wir die Frage zu "Warum nicht Ingenieure mehr empirische Beobachtungen verwenden?"

Die Antwort auf die meisten von diesen ist, um aussagekräftige Messungen (und akzeptierte Gleichungen, Grenzen, Toleranzen usw.) zu haben, die Sie in der realen Technik haben, müssen Sie zuerst eine Weise messen, was Sie gerade betrachten.

Die meisten dieser Dinge können einfach nicht einfach gemessen werden - Softwarekomplexität ist ein Klassiker, was ist "komplex"? Wie betrachtest du den Quellcode und entscheidest, ob er komplex ist oder nicht? McCabes Cyclomatic Complexity ist der nächste Standard, den wir dafür haben, aber es zählt im Grunde nur Verzweigungsinstruktionen in Methoden.

Es gibt wenig Mathematik in Softwareprogrammen, weil die Programme selbst die Gleichung sind. Es ist nicht möglich, die Gleichung zu berechnen, bevor sie tatsächlich ausgeführt wird. Ingenieure simulieren mit einfachen (und sehr komplexen) Programmen, was in der realen Welt passiert. Es ist sehr schwierig, einen Simulator zu simulieren. Hinzu kommt, dass viele Probleme in der Informatik nicht einmal mathematisch beantwortet werden können: siehe Außendienstmitarbeiter.

Ein großer Teil der Mathematik ist auch in Sprachen und Bibliotheken eingebaut. Wenn Sie eine Hash-Tabelle zum Speichern von Daten verwenden, wissen Sie, dass jedes Element in der konstanten Zeit O (1) ausgeführt werden kann, egal wie viele Elemente in der Hash-Tabelle enthalten sind. Wenn Sie es in einem Binärbaum speichern, dauert es länger, abhängig von der Anzahl der Elemente [0 (n ^ 2) wenn ich mich richtig erinnere].

Das Problem ist, dass Software mit anderer Software spricht, die von Menschen geschrieben wurde. Die von Ihnen beschriebenen technischen Beispiele behandeln physikalische Phänomene, die konstant sind. Wenn ich einen elektrischen Simulator entwickle, kann jeder auf der Welt ihn benutzen. Wenn ich einen Protokoll-X-Simulator für meinen Server entwickle, wird es mir helfen, aber wahrscheinlich wird es die Arbeit nicht wert sein.

Niemand kann ein System von Grund auf neu entwickeln, und Leute, die Semi-Common-Bibliotheken schreiben, haben in der Regel viele Erweiterungen und Erweiterungen, anstatt einen Simulator für ihre Bibliothek zu schreiben.

Wenn Sie einen Simulator für den Netzwerkverkehr wünschen, können Sie einen finden, der Ihnen jedoch wenig über Ihre Serverlast erzählt, da der Datenverkehr nicht das Protokoll verwendet, das Ihr Server versteht. Jeder Server wird völlig unterschiedliche Verkehrssituationen sehen.

  

Es gibt einen Mangel an Anwendung der Mathematik in der aktuellen Software-Industrie.

     

zB: Wenn ein Maschinenbauingenieur einen Strommast konstruiert, berechnet er die Belastung des Fundaments mithilfe von Spannungsanalysetechniken (mathematische Gleichungen lesen), um genau zu bestimmen, welche Art und welche Stahlsorte verwendet werden soll, aber als Softwareentwickler eine Web-Server-Anwendung implementiert, er schätzt nur die geschätzte Last auf seinem Server und lässt den Rest auf Glück und Gott, es gibt nichts, was er mathematisch verwenden kann, um sein Problem zu beantworten (meine Beobachtung).

Ich würde nicht sagen, dass Glück oder Gott immer die Grundlage für die Lastschätzung sind. Oft können realistische Daten erhalten werden.

Es ist auch nicht wahr, dass es keine mathematischen Techniken gibt, um die Frage zu beantworten. Operations Research und Warteschlangentheorie können gut genutzt werden.

Das eigentliche Problem ist, dass der Maschinenbau auf physikalischen Gesetzen basiert und eine Grundlage für empirische und wissenschaftliche Untersuchungen von Tausenden von Jahren ist. Informatik ist nur so alt wie ich. Die Informatik wird viel weiter sein, wenn Ihre Kinder und Enkel die besten Praktiken ihrer Zeit anwenden.

Meine Gedanken:

1. Manche Leute wenden tatsächlich Mathematik an, um die Serverlast zu schätzen. Die Gleichungen sind für viele Anwendungen sehr komplex und viele Menschen greifen auf Faustregeln, Raten und Anpassen oder ähnliche Strategien zurück. Einige Anwendungen (Echtzeitanwendungen mit einer hohen Fehlerrate für Fehler ... Waffensysteme, Steuerungsanwendungen für Triebwerke, Avionik) berechnen sorgfältig die erforderlichen Ressourcen und stellen sicher, dass sie zur Laufzeit verfügbar sind.

2. Wie 1.

3. Ingenieure verwenden auch Komponenten, die von anderen bereitgestellt werden, mit einer veröffentlichten Schnittstelle. Denken Sie an die Elektrotechnik. Normalerweise interessieren Sie sich nicht für das Innere eines Transistors, sondern nur für die Schnittstellen- und Betriebsspezifikationen. Wenn Sie jede Komponente, die Sie verwenden, in ihrer Komplexität untersuchen möchten, sind Sie darauf beschränkt, was eine einzelne Person erreichen kann.

4. Ich habe ziemlich komplexe Algorithmen geschrieben, die bestimmen, was skaliert werden soll, wenn sie auf verschiedenen Faktoren wie Speicherverbrauch, CPU-Last und IO basieren. Die effizienteste Lösung ist jedoch manchmal die Messung und Anpassung. Dies gilt insbesondere, wenn die Anwendung komplex ist und sich im Laufe der Zeit entwickelt. Der Aufwand, der für die mathematische Modellierung der Anwendung (und die Aktualisierung dieses Modells über die Zeit) aufgewendet wird, kann mehr als die Kosten der verlorenen Effizienz durch Versuche und korrekte Ansätze sein. Schließlich könnte ich mir vorstellen, dass ein besseres Verständnis der Korrelation zwischen Code und der Umgebung, in der es ausgeführt wird, zu Systemen führen könnte, die die Ressourcennutzung im Voraus vorhersagen. Da wir das heute nicht haben, laden viele Organisationen Testcode unter einer Vielzahl von Bedingungen, um diese Informationen empirisch zu sammeln.

Software Engineering unterscheidet sich sehr von den typischen Bereichen des Engineerings. Wo "normale" Technik an den Kontext unseres physikalischen Universums und die darin enthaltenen Gesetze gebunden ist, gibt es in der Softwarewelt keine solche Grenze.

Das Produzieren von Software ist normalerweise ein Versuch, eine Teilmenge der realen Welt in eine virtuelle Realität zu spiegeln. Hier definieren wir die Gesetze selbst, indem wir nur diejenigen auswählen, die wir brauchen, und sie so komplex machen, wie wir sie brauchen. Aufgrund dieses grundlegenden Unterschieds müssen Sie die Problemlösung aus einer anderen Perspektive betrachten. Wir versuchen, Abstraktionen zu machen, um komplexe Teile weniger komplex zu machen, genau wie wir Kindern das Gelb + Blau = Grün beibringen, wenn es wirklich die Wellenlänge des Lichts ist, das auf dem Papier springt, das sich ändert.

Hin und wieder sind wir jedoch an verschiedene Gesetze gebunden. Sachen wie Big-O, Test-Coverage, Komplexitäts-Messungen, UI-Messungen und dergleichen sind alles Modelle mathematischer Gesetze. Wenn Sie sich mit digitaler Signalverarbeitung, Echtzeitprogrammierung und funktionaler Programmierung befassen, werden Sie oft feststellen, dass die Programmierer Gleichungen verwenden, um herauszufinden, wie sie das machen können, was sie wollen. - Aber diese Techniken sind nicht wirklich (bis zu einem gewissen Grad) nützlich, um eine virtuelle Domäne zu erstellen, die komplexe Logik lösen, verzweigen und mit einem Benutzer interagieren kann.

Die Gründe, warum Windkanäle, Simulationen usw. in der Entwicklungswelt benötigt werden, sind, dass es viel billiger ist, einen verkleinerten Prototyp zu bauen, als das Ganze zu bauen und es dann zu testen. Außerdem ist ein fehlgeschlagener Test auf einer vollständigen Brücke destruktiv - Sie müssen für jeden Test einen neuen Test erstellen.

Sobald Sie in der Software einen Prototyp haben, der die Anforderungen erfüllt, haben Sie die richtige Lösung. Es besteht keine Notwendigkeit, die Vollversion zu erstellen. Sie sollten Lastsimulationen für Ihre Server-Apps ausführen, bevor Sie mit ihnen live gehen. Da die Ladevorgänge jedoch variabel und oft unvorhersehbar sind, sollten Sie die App so entwickeln, dass sie durch Hinzufügen von mehr Hardware zu jeder beliebigen Größe passt Belastung. Brückenbauer haben eine bestimmte Ziellast, die sie bewältigen müssen. Wenn sie eine voraussichtliche Nutzung von 10 Autos zu einem bestimmten Zeitpunkt hatten, und dann ein Jahr später die Popularität der Brücke auf 1.000.000 Autos pro Tag stieg, würde niemand überrascht sein, wenn es scheiterte. Aber bei Web-Anwendungen ist das die Art von Skalierung, die passieren muss.

1) Die meisten Geschäftslogiken sind normalerweise in Entscheidungsbäume unterteilt. Dies ist die "Gleichung", die mit Komponententests bewiesen werden sollte. Wenn du x eingibst, solltest du y bekommen, ich sehe dort kein Problem.

2,3) Das Profiling kann einen Einblick geben, wo Performance-Probleme liegen. Zum größten Teil kann man nicht sagen, dass die Software x Zyklen braucht, weil sich das mit der Zeit ändert (dh die Datenbank wird größer, das Betriebssystem wird funky, usw.). Brücken zum Beispiel erfordern ständige Wartung, Sie können nicht einen schlagen und erwarten, dass es 50 Jahre ohne Zeit und Geld für sie dauert. Die Verwendung von Bibliotheken ist so, als würde man Pi nicht jedes Mal ausprobieren, wenn man den Umfang eines Kreises finden möchte. Es wurde bereits bewiesen (und ist kosteneffektiv), so dass das Rad nicht neu erfunden werden muss.

4) Webanwendungen skalieren in den meisten Fällen horizontal (mehrere Maschinen). Die vertikale Skalierung (Multithreading / Multiprozess) ist tendenziell sehr viel komplexer. Das Hinzufügen von Maschinen ist normalerweise relativ einfach und kosteneffektiv und vermeidet einige Engpässe, die sich relativ leicht einschränken lassen (Platten-I / O). Auch der Lastausgleich kann die Möglichkeit ausschließen, dass eine Maschine ein zentraler Fehlerpunkt ist.

Es ist nicht gerade Raketenwissenschaft, wie Sie nie wissen, wie viele Verbraucher zur bedienenden Linie kommen werden. Im Allgemeinen ist es besser, zu viel Kapazität zu haben, als Fehler zu haben, angepisst von Kunden und jemand (in der Regel Ihr Chef), der Ihr Versteck kaut.