Computing Issues: Mathematische Regressionsanalyse und Hierarisches Clustering in der Ökonomie/Wirtschaft

Computing Issues: Mathematische Regressionsanalyse und Hierarisches Clustering in der Ökonomie/Wirtschaft

Mathematische Regressionsanalyse und Hierarisches Clustering in der Ökonomie/Wirtschaft

Hierarchical-Clustering und seine Schwächen

Sehr geehrte Damen und Herren,

das was man lernt in seinem Studium, dass was man gesagt bekommt, ergibt sich erst später und wird einem erst klar, nachdem man es "setzen" hat lassen.

So ist es zum Beispiel mit der Vorlesung der "Ökonometrie".
Auch in der Gefahr, dass es nicht ganz richtig ist, was den Stoff der Ökonometrie angeht, schreibe ich meine Gedanken auf.

Es gibt zwei Verfahren in der Ökonometrie, die gerne in Kombination verwendet werden: Das Hierarchical-Clustering und die Regressionsanalyse.
Das Hierarchical-Clustering wird zur Bestimmung von Gruppen verwendet und deren Beziehung dann in der Regressionsanalyse berechnet.
Da die Regressionsanalyse schon sehr ausgeschöpft ist und da der Kern der Frage in der Bestimmung der Gruppen liegt, wird hier auf das Clustering wert gelegt.

Hierarchical-Clustering sucht immer die am Nächsten liegenden Punkte oder Mittelwerte einer Gruppe und verbindet die beiden Punkte zu einer neuen Gruppe. Das Ergebnis sieht wie folgt aus:

Abb. 1 - typisches Beispiel für Hierachical-Clustering ohne Dendrogramm [5]

Nach Wikipedia gibt es zwei Verfahren:

• divisiv - bzw "Top-down"
• und agglomerativ - bzw "Bottom-up"

Eine tiefere Unterscheidung ist in meinem Beitrag von 2009 zu lesen.
Pattern-Recognition anhand von Hierarchical-Clustering mit Hilfe des Cut-Off-Criterium

Leider sind nach Wikipedia die Verfahren Top-Down und Bottom-Up in ihrer Komplexität unterschiedlich.
Top-Down brauch naiv ${\displaystyle O(2^{n})}$ Schritte.
Bottom-Up hingegen nur ${\displaystyle O(n^{3})}$ Schritte.
Natürlich geht der Vorteil mit Verlust von Information/Unterscheidungsmöglichkeiten einher.
Doch dies ist hier nur prognostiziert.

Da ein Hierarchical-Clustering mit dem Hierarchie-Diagramm wie in Abbildung 1 nicht viel hilfreich ist, wird der Abstand zwischen den Clustern beim Vereinigungspunkt auf der Y-Achse abgebildet. Dies ist dann ein "Dendogramm", welches auch gedreht dargestellt werden kann. Ein Beispiel ist in Abb.2 gezeigt.



Abb. 2 - Beispiel für ein typisches Dendrogramm [1]


Hier wird dann das Cut-Off-Criterium angewendet, welches dazu dient die Cluster zu bestimmen.
Dazu gibt es unterschiedliche Verfahren, welche in: Pattern-Recognition anhand von Hierarchical-Clustering mit Hilfe des Cut-Off-Criterium vertieft werden können.
Manchmal reicht ein einzelnes Cut-Off-Criterum nicht aus, weil dann nur eine kleine Menge und eine ganz große Menge entsteht, welche oft nicht der Realität entsprechen. Daher wird gerne ein zweiter Schnitt gemacht, welcher dann nur auf die Große Menge bezogen wird und diese weiter unterteilt. Siehe dazu Abbildung 3. Durch Wiederholung dieses Verfahrens bis auf vorgegebene Größen von Mengen, ist dieses Verfahren sicherlich sinnvoll. Leider sind jedoch dadurch keine großen Mengen mehr erkennbar/unterscheidbar. Im Allgemeinen geht der Vorteil des Clusterns damit verloren. Denn, jede Menge lässt sich natürlich in andere Mengen unterteilen. Und am Ende sind die Mengen immer nur von zwei Elementen Abhängig.



Abb. 3 - Zwei cut-off Kriterien [3]

Trotz dem mehrfachen Unterteilen, liegt das Problem, weshalb Hierarchical-Clustering nicht vollständig als perfektes Verfahren etabliert ist, auch in der Möglichkeit, dass das Clustering "entartet". Man kann sagen: Die Frage der Entartung ist analog zur Frage wo geschnitten werden kann.
Genauso, wie es unter Binärbäumen entartete Bäume gibt, gibt es beim Hierarchical-Clustering auch entartete Hierarchien. Siehe dazu Abbildung 4.
Dies wird ebenfalls im Wikipeida Artikel[1] beschrieben, und dort als "single-link effect" (dt. Ketteneffekt) bezeichnet.

Abb. 4 - Beispiel für Entartung des Hierarchical-Clustering [4]


Es wird versucht mit verschiedenen Verfahren beim Alignment/Linkage das Probelm des single-link effects zu verhindern. Dabei wird zwischen drei Knoten im Hierarchical-Tree unterschieden. Der einzufügende/aligning Knoten (g_a) und die beiden letzten Knoten der aktuell betrachteten Menge (g_b).

Abb. 5 - "Daten und Dendrogramm mit der Centroid-Methode." [1]

Wie in Wikipedia[1] beschrieben, gibt es unterschiedlichste Verfahren zur Verhinderung von single-link effect.
Aktuell sind jedoch nur empfehlenswert, das Average-Linkage und das Centroid-Linkage Verfahren. Das liegt an der Betrachtungsweise. Für die Anwendungen in der Betriebswirtschaft ist es notwendig den natürlichen Gegebenheiten der Welt und dem natürlichem Verhalten von Menschen ähnlich zu sein. Dafür bietet sich das Centroid-Linkage und das Average-Linkage am besten an. Näheres über die Verfahren in [1]. Die beiden Verfahren Centroid und Average sind auch in erster Linie die Wahl, da andere Verfahren wie Median-Berechnung nur sinnvoll sind, wenn die Mittelwert-Berechnung an Aussagekraft verliert.

Der Grund hinter dem Linkage-Verfahren mit drei Gruppen/Mengen liegt, wie schon erwähnt, in der Lösung des single-link effect.
Um die Idee näher zu verstehen, ist es dienlich das Problem kurz zu umschreiben.

Problem der Entartung von Bäumen

Eine Entartung entsteht, wenn eine der zu vereinigenden Gruppen g_a oder g_b eine Stufe zuvor auch schon vereinigt wurden.
Um das zu erklären, ist es praktisch kurz die Eigenschaften eines entarteten Baumes zu beschreiben:

• das zuletzt hinzugefügte Element zu einer Gruppe,
  ist auch wieder Element der nächsten Gruppe,
• der Baum hat genauso viele Ebenen, wie Elemente (n).
  Bei einem ausgeglichen Baum gibt es hingegen nur log(n) Ebenen für n Elemente.

Daraus folgt:
Wenn k = | i - j |, mit |.| = Absolutwert der Ebenen-Nummer i für g_a und j für g_b, dann ergibt sich folgende Regel:
Ist |i-j| < log(n)/2, so führt diese Verbindung zur Entartung.


Nun kann man diese Verbindung auslasse und die nächst beste Gruppe nach dem Linkage-Verfahren betrachten.
Deshalb wird gerne das Linkage-Verfahren variiert um den single-link effect zu vermeiden.

Doch leider hat das Problem der entarteten Bäume wenig mit dem Linkage-Verfahren zu tun. Das Linkage-Verfahren dient nur der Frage, wie die Elemente ausgewählt werden um miteinander verbunden zu werden. Naturgemäß ist da das Kriterium des nähesten oder mittlersten Elementes, innerhalb zwei Gruppen A und B, am passendsten. Beispielsweise gäbe es noch das Verfahren des weitesten entfernten Elementes aus zwei Gruppen als Linkage (Complete-Linkage) zu betrachten, nur wird dies dem natürlichem Verhalten von Personen und Optionen kaum gerecht.


Die Entartung der Bäume liegt demnach nicht an dem Linkage-Verfahren.
Eine naive Lösung wäre nicht das Linkage-Verfahren zu variieren, sondern wie folgt.

Naive Lösung

1. Wenn |i(g_a) - i(g_b)| < log(n)/2 * 0,8 = log(n) 2/5,
   wobei i(g_a) die Ebenen-Nummer bei Vereinigung von Gruppe A ist und 0,8 o.B.d.A ein Wert, der für signifikant kleiner steht, ist,
   dann wähle die nächste, dem Linkage-Verfahren passende Gruppe g_c, welche zu g_a aligned würde. 
2. ist dann |i(g_a) - i(g-c)| >= 2/5 log(n), höre auf und verbinde g_a mit g_c.
3. ist |i(g_a) - i(g_c)| < 2/5 log(n), dann wiederhole Schritt 1,
4. bis keine alternative Gruppe gefunden wurde. So wähle g_b.

Diese Lösung ähnelt in etwa einem AVL-Baum[6]. Der Baum wird ausgeglichen um die "Entartung" zu vermeiden. Der Trick des AVL-Baumes besteht darin, den rechts oder links-lastigen Zweig höher zu stellen, indem ein anderer Root-Knoten gewählt wird. Dabei spricht man von Links-, Rechts- oder Doppelrotation.
Abb. 6 zeigt eine Linksrotation um den rechten schwereren Zweig auszugleichen.

Abb. 6 - Linksrotation [6]

Problem der Naiven Lösung

Leider ist das Problem der Naiven Lösung ganz offensichtlich: Die Mengen A wird mit einer anderen Menge C anstelle der von B verknüpft. Die Menge C ist jedoch von der Lokalisation weiter entfernt als B, und entspricht daher nicht dem Ähnlichkeitsprinzip. Geht es bei der Erstellung des AVL-Baumes nur um eine korrekte Sortierung der Elemente nach > oder <=, so ist ein AVL-Baum ausreichend. Hier im ökonomischen Zweig, geht es jedoch um Erkennung von Gruppen und diese sind nach Rotation, oder Wahl von C anstelle von B, zerstört.

Elegante Lösung

Ist der Datensatz mehr als eindimensional, also ein Vektor, so ist generell eine hierarchische Aufteilung nicht möglich. Die Datensätze besitzen nun eine Position in einem mehrdimensionalen Raum. Sie besitzen eine Lokalisation. D.h. die Datensätze haben mehrere Abstände zu ihren nächsten Nachbarn auf unterschiedlichen Achsen.
Eine Vereinfachung auf den am nahestehend Datensatz/Gruppe/Knotenpunkt ist somit eine Reduktion der anderen Abstände auf den anderen Achsen.
Durch dies Reduktion geht Information verloren, und das Ergebnis entspricht nicht dem gewünschtem Ergebnis.
Im Prinzip ist das Hierarchical-Clustering auf mehrdimensionale Daten ungenügend. Aktuell erstellt es eine Hierarchie, die so nicht die Gruppen der mehrdimensionalen Daten abbildet.

Vielleicht wäre eine Lösung durch einen vollständigen Travelling-Salesman-Path möglich.
Das Travelling-Salesman-Problem ist die Frage nach dem kürzesten Round-Trip, wenn alle Punkte/Städte auf mindestens Intervallskala, miteinander auf direktem Wege erreichbar sind.

Die Lösung wäre:

1. Das TSP auf den Daten X zu lösen
2. Bei der größten Teilstrecke in eine Richtung zu starten
3. Alle Punkte als eine gemeinsame Menge zu sehen, welche mit den TSP-Streckenabschnitten s verbunden sind, die kürzer als der durchschnittlichen Streckenabschnittslänge µ, abzüglich des Fehlers e, sind.
   s < (µ - e) ==> verbinden des vorherigen und nächsten Punktes.

Wie das TSP lösbar ist, wird in einem anderen Blog-Beitrag besprochen.
Siehe tspsolved.blogspot.de  .

Als Fehler e verwenden wir das a-Quantil mit alpha=0,04. D.h. bei z_(1-a/2) = 0,5160 für Normalverteilung, ist der Fehler:



    [7]

Leider ist das TSP auf naive Variante noch O(n!). D.h. zu langsam. Mit der Lösung des TSP wie unter tspsolved.blogspot.de, kommt es zur Veränderung in der Komplexität und einem großen Einfluss auf die Welt.
So kann das TSP einen Beitrag für die Öknometrie leisten.


mit freundlichen Grüßen, hochachtungsvoll, Ihr Sebastian

References

[1] https://de.wikipedia.org/wiki/Hierarchische_Clusteranalyse
[2] http://sebastianboehmercomputing.blogspot.de/2009/12/pattern-recognition-anhand-von.html
[3] http://compbio.pbworks.com/f/partitonal.JPG
[4] http://www.saedsayad.com/images/Clustering_h1.png
[5] http://www2.cs.uregina.ca/~dbd/cs831/notes/clustering/Hiereg.gif
[6] https://de.wikipedia.org/wiki/AVL-Baum
[7] https://de.wikipedia.org/wiki/Konfidenzintervall

Programmkonstrukt - Grundlagen für eine Programmiersprache

Sehr geehrte Damen und Herren,

folgender Text ist unausgereift und hier nur als Skizze zu sehen.

eigentlich ist es ja so: Mit jeder neuen Technologie stellt sich die Frage, ob man diese brauch. Auch ist es immer wieder fraglich, ob es vorteilhafter wird, ob es einfacher wird, oder nur komplexer. Es stellt sich die Frage, ob die Technologie eine gute Idee war.
Prinzipiell ist jede Technologie gut. Jedoch gibt es auch die Möglichkeit eine unnötige Technologie zu besitzen oder Zeit in diese zu investieren. Man stelle sich vor, man hätte eine Waschmaschine, in die man nur ein Teil jeweils rein machen kann, die trotzdem eine Stunde pro Teil brauch. Oder ein stylischen Tretroller (Scooter), der ganze 10 kg wiegt.

Und im Prinzip verhält es sich mit der Programmierung gleich. Es gibt komplizierte Programmierkonstrukte, die mehr Chaos als Ordnung in die Programmierung bringen. Es sieht so aus, als ob nicht jedes Programmierkonstrukt geeignet ist. Es sieht so aus, als ob es ein optimale Technik geben könnte. Ich weiß, dass manche ja behaupten, jede Programmiersprache habe seine Berechtigung. Klar, jeder Mensch und jede Menschensprache auch. Nur gibt es auch Mörder und Kaudawelsch.

Wollen wir wirklich mörderisches Chaos? Wollen wir wirklich Programmiersprachen als Kaudawelsch? Sicherlich sehr künstlerisch, und sicherlich auch sehr cool. Nur leider nicht zielstrebig um folgende Punkte zu lösen:

* Schnelles Auffinden von Code-Stellen.
* Leichtes Einarbeiten in neuen Code.
* Schnelles Implementieren von neuen Features.
* Zukünftige und andauernde Verwendung dieses Programmierkonstrukts.

Lösung

Deshalb gibt es hier die Lösung.
Ziel ist es eine Programmierkonstrukt zu bekommen, welches die Punkte, wie oben beschrieben erfüllt:
Ziele:
* Schnelles Auffinden von Code-Stellen.
* Leichtes Einarbeiten in neuen Code.
* Schnelles Implementieren von neuen Features.
* Zukünftiges und andauerndes Verwenden des Programmierkonstrukts.
* Möglichst einfaches und fehlerfreies implementieren.

Das Programmierkonstrukt brauch eine hierarchische Ordnung. Es sollte folgende schon vorhandene und bewährte Hierarchien übernehmen.
Eigenschaften:
* Prozesse und Threads
* Memory Pages und Shared Memory
* Daten in JSON and Binary-Part in JSON

Im Prinzip ist ein Rechner eine Turing-Maschine. D.h. er besteht nur aus Einem Band, einem Schreib/Lese-Kopf und einem Alphabet mit Regeln.
Das Band sind Memory Pages und Shared Memory. Der Schreib-/Lese-Kopf sind die Prozesse und Threads. Das Alphabet sind die Daten und Programme. Und die Regeln sind die Rechenoperationen der CPU.

Im Prinzip lässt sich alles auf ein Netzwerk von Daten und Programminstruktionen reduzieren. In diesem Netzwerk verläuft man nun einen Weg. Um genauer zu sein, ist der Weg immer einen Round-Trip, sonst muss man die Maschine immer wieder neu-starten. Was dann auch einem Round-Trip entspricht.
Es bietet sich nun an einen Round-Trip immer im kürzesten Weg zu machen, denn wir wollen ja eine schnelle Maschine. Und nicht die Waschmaschine mit einem Teil.
D.h. der Programmierer ist immer dabei bei gegebenen Daten und Instruktionen den kürzesten Round-Trip zu formulieren, so dass am Ende das gewünschte Endprodukt entstanden ist, oder der gewünschte Prozess durchgeführt wurde.

Das Programmkonstrukt soll den Programmiere nun dabei unterstützen diese Round-Trips zu erschaffen und dabei die oben genannten "Ziele" zu berücksichtigen.
Man sieht sofort, es ist nicht möglich durch chaotische Programmkonstrukte einen kürzesten Round-Trip zu finden.
Ein Beispiel für einen gelungenen Round-Trip wäre:
Round-Trip A
1. warte auf User-Input
2. Lese User-Input
3. If (data x == 1) starte Round-Trip B
4. Drucke Information auf Bildschirm
5. Beginne wieder mit 1.

Round-Trip B
1. Drucke "Wie ist Dein name".
2. Warte auf User-Input
3. Drucke "Hallo " + Data y + " !"
4. Beginne mit Round-Trip A.1.

Wie man an dem Beispiel sieht sind mehrere Round-Trips auch miteinander Verknüpft. Jedoch wissen Informatiker, dass dabei nicht ein wildes umherspringen zwischen den Round-Trips passieren sollte, wie es z.B. mit Goto-Anweisungen früher der Fall war. Sonder, dass jeder Round-Trip auch einen klaren Pfad haben sollte, der einem "kurzen" Weg entsprechen sollte. "kurz" hier in dem Sinne von nützlich. Es ist z.B. nicht nützlich in B.2.5. einen Schritt "Warte auf User-Input" zu setzen und die Eingabe dann zu verwerfen. Denn, das wäre dann die Waschmaschine mit nur einem Teil.
Unter der Betrachtung von Daten und Instruktionen als Punkte-Menge, wäre das eine Abzweigung ohne zurück zu kommen. Demnach kein Round-Trip, demnach hier nicht gewünscht.

Aus der Lösung eines Travelling-Salesman-Problem (TSP) wissen wir, dass ein kürzester Round-Trip durch ein Devide-And-Conquer-Verfahren gelöst werden kann. D.h. der Raum wird in Teilräume unterteilt und jeder Teilraum löst wieder ein TSP.
Die Punkte im TSP ist das Turing-Maschine Alphabet mit Daten und Instruktionen. Jedes Datum ein Punkt und jede Instruktion ein Punkt. Auf diesen Knoten bilden wir nun die Struktur.
Aus dem TSP-Solver wissen wir, dass es eine hierarchische Baumstruktur seien sollte.

Vorhandene Struktur

Daten:
Unterste Ebene: Binärdaten
zweite Ebene: Primitive Data-Types (float, int, double, long, char)
dritte Ebene: JSON oder binary JSON. Am besten beides.
JSON ist dann eine hierarchische Ordnung der Daten und damit das Ziel erreicht.

Instruktionen:
Unterste Ebene: Maschinencode
zweite Ebene: Assembler-Befehle
dritte Ebene: Konstrukte höherer Programmiersprachen
vierte Ebene: OOP
fünfte Ebene: Spring-Framework?
Bei OOP sind wir in der hierarchischen Ordnung für Daten angekommen.

Jetzt benötigen wir noch eine hierarchische Ordnung/Aufteilung dieser Daten/Instruktionen.
Das ist zum einen die OOP, die zugehörige Daten mit Instruktionen verbindet und zum anderen, unser gesuchtes Programmkonstrukt, welches Diese OOP's dann wieder in Bereiche einteilt.

Neues Konstrukt

Eigenschaften des neuen Konstrukts:
* Jeder Bereich sollte maximal und minimal einen Round-Trip enthalten.
* Die Round-Trips, welche ineinander gehen, liegen in der hierarchie nebeneinander.
* Der oberste Knoten in dem Konstrukt sollte Versionierung und Varianten enthalten. Versionierung um eine Zeitskala abzubilden und Varianten um die Frage "für wen" abzubilden. Also kundenspezifische Varianten.
* Die oberen Nodes im Baum sollten auf beliebige Tiefe laufen können um mehrdimmensionale Eigenschaften abzubilden. Z.b. erste Ebene ist der Kunde, zweite Ebene ist der Ort/die Maschine, und dritte Eben ist die Version.
* Aspect-Orientierte-Programmierung sollte durch die Hierarchie ermöglicht werden.
D.h. von dem ursprünglichen Zweig kann jeweils immer eine andere Variante abgezweigt werden, die nur eine Erweiterung des Code's vom Original enthält.
* Prozess-hierarchien wie sie bei Multiprozessor-Technologien erscheinen, sind durch die Hierarchie im Programmierkonstrukt ebenfalls abgedeckt. D.h. das Programmkonstrukt brauch noch festgelegte Struktur, bevor es in die oberste, freie Struktur der Varianten gehen kann.

Festgelegte Struktur, bevor der freien Struktur.

Daten und Instruktionen sind gut in OOP gekapselt.
Threads sind gut in Prozesse gekapselt.
Memory ist gut in Pages und shared Memory eingeteilt.
Festplatten sind gut in Sektionen aufgeteilt.
Damit sind die Turing-Maschinen Features unterteilt.

Bleibt nur noch die Hierarchie für alle Komponenten zusammen.
Gewünscht ist:
* Mehrere Prozesse sollen miteinander Kommunizieren.
* Mehrere Daten und Instruktionen sollen miteinander Verbunden werden.
* Mehrere Zugriffsmöglichkeiten auf Memory und Festplattte sollen Verbunden werden.

Aktuelle Lösung:
* Prozesse kommunizieren über Inter-Process-Communication.
* Daten und Instruktionen sind in Bibliotheken miteinander verbunden.
* Zugriffsmöglichkeiten sind auf Memory und Festplatte über Datenbanken verbunden.

Gesucht ist also ein Konstrukte, welches:
* Inter-Process-Communication macht. Auf hierarchische Art-und-Weise.
* Bibliotheken und Versionierungssystem enthält.
* Und eine verteilte Datenbankanbindung nach dem CouchDB Prinzip enthält.

CouchDB:
Primitive Instructions einer Datenbank sind: query, edit, add und delete.
Eigenschaften sind: append-only updates, indizes as b-trees.

Pro CouchDB:
* Document-Based
* "Views are the method of aggregating and reporting on the documents in a database"[¹]
* "as many different view representations of the same data as you like"¹

Contra CouchDB:
* "When CouchDB documents are updated, all data and associated indexes are flushed to disk"[1]

MongoDB:
Neben CouchDB gibt es noch eine nach meiner Meinung geeignetere Datenbank.
Diese ist MongoDB. Sie ist insbesondere besser geeignet, da sie Consistency garantiert und nicht wie CouchDB zwischen verschiedenen Clients evtl. veraltete Daten besitzt. Die schnelle Erreichbarkeit ist eine andere Frage und kann einfacherweise später auf Consistency drauf gesetzt werden.

Pro MongoDB:
* Document-based,
* Consistency.
* typical find() method for queries.

Contra MongoDB:
* nicht so gute Availability.

Beide Datenbanken haben einen entscheidenden Nachteil. Ihre Basis sind nicht Elemente, sondern Documente. Es können so nur ganze Documente einen Index enthalten. Für das Union-Find Problem auf Datenbanken wäre ein Mengen-Orientierte Datenbank noch praktischer.

==> Entscheidung für MongoDB

Bleibt noch das Paketsystem.
Und bleibt noch die Inter-Process-Communication.

==> Das Paketsystem is mnu für JavaScript updater.

==> Die Inter-Process-Communication ist dann mit Events auf der Basis von Node.js

Contra Node.js:
* keine Typisierung im JavaScript - die Differenzierung der Daten geht verloren.
 (z.B. wie kann man einen 64Int in JavaScript darstellen? - nur mit einer Hilfsbibliothek, was zu Performance-Einbusen führt)
* Es ist ein Interpreter kein Compiler. Manche Fehler werden erst nicht zur Compilezeit aufgedeckt. Alles muss intensiver getestet werden, gerade, da Typ-Converting-Fehler auftreten können. (z.B. ein String in einen Integer).
* Eine Variable kann die eine Sekunde Integer und die andere Sekunde ein String sein. Daher keine klare Trennung von Daten.
* Keine besonderen Features guter Programmiersprachen, wie
 - exception-handling
 - Generics/Templates
 - kein AOP (aspect-oriented-programming)

Pro Node.js:
* Sehr Funktionale-Programmiersprache, da viele sogenannte "Lambdas" verwendet werden. Trotzdem Prozedural.
* Performanz ist zum Glück bei vielen Anwendungen nicht notwendig.

==> Aufgrund der vielen Contras, entscheide ich mich doch für C++ mit Poco als Inter-Process-Communication (IPC) über TCP/IP und HTML/JSON

Freie Struktur

 Die hier als "freie Struktur" bezeichnete Programmstruktur beinhaltet die Aufgabe alle besonderen und zusätzlichen Strukturen zu einem gemeinsamen Konzept zu vereinen. D.h. die Programmstruktur bildet einen Baum mit beliebiger Anzahl von Kindern über den oben vordefinierten Strukturen.

Angewandt heißt dies: Es benötigt ein Framework, welches MongoDB mit zusätzlicher verbesserter Availability, C++ in Kombination mit IPC über Poco und eine Versionierung mit AOP kombiniert.
Dabei muss Poco noch um Event-Driven Engineering erweitert werden. D.h. anstelle von Request-Response Schemas sollten Events in Poco eingeführt werden. Dies entspricht letztlich eher der Realität.

Auf dieser Struktur von C++ Poco und MongoDB kommt nun eine weitere Schicht Versionierung. Bei der Versionierung geht es darum für verschiedene Kunden verschiedene Versionen zu pflegen und dennoch eine gemeinsame Linie zu führen pro Produkt.

(Außerdem muss für die TCP Connection noch ein stabiles Messaging implementiert werden, in dem die Pakete mit und ohne Reliability verschickt werden können.)

Referenzen

[1] https://wiki.apache.org/couchdb/Technical%20Overview

Taskjuggler unter Windows

Hi,

warum hat Taskjuggler keine GUI?
Gut, es ist als Consolen-Anwendung geschrieben. Das ist toll. Doch gibt es leider keine grafische Oberfläche zum bedienen.
Wer will schon Kommandos an einen Server schicken, um einen kurzen einfachen Plan zu erstellen.
Nichts desto trotz, ist die Idee gut. Ein Server für große Projekte. Einzelne Tools lassen sich so gut in Taskjuggler integrieren. Z.B. kann das Ticketsystem dem Taskjuggler mitteilen, dass etwas länger dauert.

Falls jemand eine GUI schreibt, oder eine GUI finden sollte, dann bitte hier in den Kommentaren eintragen!

Das Taskjuggler nicht geeignet für schnelles Design von Aufgaben und einem Milestoneplan ist, sieht auch, die Person hinter diesem Link so.
http://www.pegasoft.ca/coder/coder_july_2008.html


Solange keine GUI zur Verfügung steht empfehle ich doch Visio, Word, Excel oder anything.

Grüße, Sebastian

Das "Stau aus dem Nichts" Problem

Sehr geehrte Damen und Herren,

Sie kennen es bestimmt. Sie stehen in einem Autostau und fragen sich am Ende des Staus, warum Sie eigentlich im Stau standen. Das Problem ist seit einigen Jahrzehnten bekannt. Viele Wissenschaftler haben sich schon damit auseinander gesetzt. So kenne ich persönlich eine Person, die an einem Leitsystem für medizinische Proben arbeitete, und versucht hat das Problem zu lösen. Alle bisherigen Lösungsmöglichkeiten sind aktuell gescheitert. Dabei würde es reichen, zu wissen, wann keine weiteres Auto mehr auf die Strecke darf, bevor die Strecke voll ist.
Die hier präsentierte Lösungsmöglichkeit gibt einen einmaligen Ansatz, der das Problem effektiv löst. Der Lösungsvorschlag ist auf Ihre individuelle Situation anpassbar und basiert auf schon bekannten Theorien aus der Mathematik.

Einführung

Bei der Beobachtung vieler Menschen bei Stau hat sich der Begriff "Stau aus dem Nichts" eingebürgert. Es gibt dazu einen Beitrag in Wikipedia, siehe [1].
Das Problem besteht darin, dass viele Einheiten, beispielsweise Autos, auf eine räumlich beschränkte Strecke fahren, und von dieser wieder abfahren müssen. Bei mehr als einer Spur gehen wir ohne Beschränkung der Allgemeinheit davon aus, dass auf beiden Spuren jeweils ein Auto gleichzeitig auffährt. 
Wenn nun viele Autos auf diese eine Strecke fahren, kommt es gelegentlich zu Stau. Das wird verursacht, aus dem Grund, das vorherige Autos mit niedrigerer Frequenz abfahren, als sie aufgefahren sind.
D.h., zu einem Zeitpunkt, ist die Frequenz in der die Autos auffahren höher, als die Frequenz, in der sie wieder abfahren. Dadurch entsteht eine Überfüllung der Strecke und damit Stau.

Naive Variante

Im weiteren sprechen wir von Einheiten, anstelle von beispielsweise Autos. Dies können auch Container oder Güter sein. Ja, selbst Menschenströme lassen sich damit berechnen.

Jeder würde sagen: Wenn das Problem in der Eingangsfrequenz bezüglich der Ausgangsfrequenz liegt, dann lässt es sich doch lösen, indem man einfach die Eingangsfrequenz niedriger als die Ausgangsfrequenz hält.

D.h. man misst am Anfang, z.B. pro Sekunde, wie viele Einheiten die Strecke betreten und misst am Ende, wie viele Einheiten die Strecke pro Sekunde verlassen. Dabei hält man die Frequenz der zusteigenden Einheiten niedriger als die Frequenz der verlassenden Einheiten.

Das würde dazu führen, dass keine Einheiten rein gelassen würden, da die Ausgangsfrequenz beim Start gleich 0 ist.
Also wird eine anfängliche Ausnahme gemacht. Es wird z.B. für 5 Sekunden immer rein gelassen, um danach dann wieder nur rein zu lassen, wenn die Ausgangsfrequenz höher ist.

Da es unbekannt ist, wie schnell die Einheiten rein kommen, kann es nun passieren, dass die Strecke schon voll ist, bevor überhaupt eine Einheit den Ausgang erreicht.

Wie viele Einheiten demnach auf die Strecke passen, kann vorher ermittelt werden und dann am Eingang eingestellt werden.
Z.B. wird festgestellt, dass 5 Sekunden zu lange ist für die übliche Zugangsmenge. Deshalb sind die 5 Sekunden auf 3 Sekunden reduziert.

Jetzt bildet sich kein Stau mehr, denn die Strecke ist nicht voll, wenn 3 Sekunden zugelassen werden.

Jedoch entstehen Lücken, in denen die Stecke nicht ausgelastet ist.
Zusätzlich können die Einheiten auch schneller eintreffen als gewöhnlich, so das 3 Sekunden vielleicht doch zu lange sind. So besteht die Gefahr, dass es wieder Stau gibt.
Wenn jetzt mehrmals hintereinander eine höhere als die durchschnittliche Frequenz kommt, dann bildet sich wieder Stau auf der Strecke.

Mit einer Frequenz und Zeitmessung kann das Problem leider nicht gelöst werden.

Die Idee eine Art Belastungsfrequenz für die Stecke zu spezifizieren, anstelle die Eingangszeit als Grenzwert zu verwenden, hilft leider nicht. Dadurch ändert sich das Problem nicht, da Zeitgrenzwert = Anzahl * Belastungsfrequenz ist.
(Belastungsfrequenz = Anzahl/Zeit)

Warum funktioniert das "Naive Verfahren" nicht?

Das Naive Verfahren funktioniert nicht, da es erst-mal nur mit Mittelwerten rechnet, und es zum Anderen auch nicht prognostiziert. D.h. es ist erst bekannt, wann es zu Stau kommen kann, wenn es schon zu spät ist. Das liegt daran, dass nur der Vergleich zwischen Eingang und Ausgang möglich ist.
Natürlich ist es möglich nun mehrere Messpunkte zu installieren, jedoch reduziert sich das Problem dann nur auf eine kleinere Strecke.

Kenntnis aus der Mathematik

Prof. Dr. Günther Dueck von IBM hat ein bekanntes mathematisches Phänomen in seinem Vortrag an der Hochschule Aalen am 18.05.2015[4] beschrieben:

Es lässt sich anhand des Auslastungsgrades ermitteln, wie viele Einheiten in der Warteschlange stehen. Er nennt dies die "Warteschlangenformel"[2].


Das verwendete Beispiel war die Kassiererin im Supermarkt. Sie hat z.B. eine Auslastung von 80%, dann stehen im Schnitt

Auslastung / (1 – Auslastung) = erwartete Anzahl der Kunden an der Kasse = a

0,80 / (1 – 0,80) = 4,0 Kunden an der Kasse

Im Vortrag wurde nochmal die erwartete Anzahl a mit der Auslastung multipliziert, um auf die durchschnittliche Länge der Schlange, in dem Moment, indem der Nächste dazu stoßt, zu bestimmen. Doch dies ist für den Anwendungsfall hier uninteressant, da wir nur die "Belastung der Strecke" wissen möchten.

Neue einmalige Lösung

Nun gibt es hier eine Lösung des "Stau aus dem Nichts" Problems, indem die Belastung der Strecke über die Warteschlangenformel bestimmt wird.
Dies ist eine einmalige und einzige Verknüpfung der Formeln und Probleme für Sie, welche individuell angepasst werden kann.

Es gibt die Eingangsfrequenz fe und die maximale Anzahl von Einheiten auf der Strecke a_max.

Es wird die Warteschlangenformel angewandt. Dies ergibt die erwartete Anzahl a von Einheiten auf der Strecke:

       a = fe/(1-fe)


Lösung

Es darf nun keine weitere Einheit auf die Strecke kommen, wenn a > a_max.

Resümee

Die "Warteschlangenformel" hilft zur Regulierung des Eingangs auf die Stecke. Mit dieser Formel und der Anwendung der oben beschriebenen Methode, gibt es eine Prognose, die es ermöglicht den Stau rechtzeitig zu verhindern. Und es gibt eine Differenzenbildung, welche besser ist als die Mittelwertberechnung im Naiven Verfahren. (Siehe dazu, hier weiter oben: "Warum das Naive Verfahren scheitert?")
Generell sind Differenzenbildung gegenüber reinen Mittelwerten bei Problemen mit Bewegung, immer zu bevorzugen. Reine Mittelwerte bedeutet hier nur den Mittelwert berechnen über die Eingangsgröße. Wird der Mittelwert über die Differenz gebildet, ist hier nicht der "reine" Mittelwert gemeint.

Ausschau

Ein weitere Zusammenhang, zum "Stau aus dem Nichts", ist die "logarithmic transformation concentration"[5] oder auch "Hill equation"[3].
Dabei wird versucht die restliche Konzentration in einer Lösung aufgrund von gebundenen und ungebunden Elementen zu ermitteln.
Es ergibt sich die restliche Anzahl der freien Elemente entlang der Zeit, nach dem Verlauf der Funktion:

      a_free = log( phi/ (1 - phi)),

wobei phi, die Formel wie in[3] beschrieben ist und das Verhältnis zwischen freien Elementen und gesamten Elementen beschreibt.

Bei dem "Stau aus dem Nichts" Problem wird nur der Logarithmus weg gelassen, der hier der Staugeschwindigkeit, also der Neigung der Einheiten zu einem Stau - a la. gute Fahrer neigen weniger zu Stau - entspricht.
Auch wird das Verhältnis freie Einheiten zu gesamte Einheiten und nicht belegte Einheiten zu gesamte Einheiten betrachtet.
So ist klar, dass die Hill Equation eine Anlehnung an die Warteschlangenformel ist und umgekehrt.

Bleibt noch zu klären, wie sich der Logarithmus in der "Stau aus dem Nichts" Problematik erklären lässt.
Der Logarithmus in der Hill Equation wird in der "Stau aus dem Nichts"-Lösung hier, durch die wiederholte Bestimmung der Eingangsfrequenz ersetzt.

Beginnen Sie Ihr System individuell anzupassen, so erhalten Sie hiermit eine bessere und zufriedenstellende Lösung. (ca. 20% Steigerung)


Mit freundlichen Grüßen,
Sebastian Böhmer

Referenzen

[1] https://de.wikipedia.org/wiki/Stau_aus_dem_Nichts
[2] http://blog.kvd.de/2015/07/09/was-eine-schlange-an-der-supermarktkasse-mit-ihrem-persoenlichen-arbeitspensum-zu-tun-hat-2/
[3] https://en.wikipedia.org/wiki/Hill_equation_%28biochemistry%29
[4] https://www.hs-aalen.de/en/news/263
[5] https://www.comsol.com/support/knowledgebase/952/

Latex ModernCV Template für Lebenslauf und Anschreiben

Hallo,

jeder stand mal vor dem Problem. Gelegentlich ist es soweit, dass man sich neu bewerben muss. Dann kommen wieder tausend Tips und Tricks, wie man sich bewirbt und wie der Lebenslauf aussehen muss.
Ganz gerne wird gesehen, dass man ein Deckblatt hat auf dem am besten der Titel der Stelle mit abgebildet ist.
Dann möchte man gerne erstmal den Lebenslauf sehen und daraufhin dann das Anschreiben.

Alles in Allem, ist es günstig ein TeX-Vorlage zu verwenden. Sehr beliebt ist dabei ModernCV auf www.latextemplates.com .

Für das Deckblatt und die Signatur, sowie die Überschriften und Sans Serif, habe ich eine TeX-Vorlage eines Lebenslauf, welcher ModernCV verwendet.

Um den Lebenslauf zu erstellen und zu pflegen, ist es oft mühsam eine eigene TeX-Umgebung zu installieren und zu warten.
Zum Glück gibt es da schon eine Web 3.0 Platform, welche einem diesen Service ermöglicht.
Verwenden sie dazu www.overleaf.com um Ihren Lebenslauf zu erstellen.
Einfach den Code von unten in Ihre Tex-Datei im Overleaf-Projekt einfügen.

Erstmal viel Spaß, Sebastian

---

PS: Bei Interesse, stelle ich den Code in ein Repository.
PPS: Ein paar Dateinamen und Dateien, wie Bewerbungsbild und Anschreibentext, müssen zur Zeit leider noch angelegt werden.

Der TeX-Code

\documentclass[11pt,a4paper]{moderncv} %\moderncvtheme{casual} %\moderncvtheme{classic} \usepackage[document]{ragged2e} \moderncvtheme[purple]{casual} \usepackage{german} \usepackage[german]{babel} \usepackage[scale=0.8]{geometry} \usepackage{setspace} \usepackage{ifthen} % \equal \usepackage{color} \usepackage{enumitem} \setlist[itemize]{nosep} %-------------------------------------------- %---------- INDIVIDUAL SETTINGS ------------- %-------------------------------------------- % To omit the cover letter, just set variable to 0. \newcommand{\configWithLetter}{1} \newcommand{\announcementPosition}{Entwicklungsingenieur - SE-Teamleiter Physisches Bordnetz,} \newcommand{\salute}{Sehr geehrte Herr Huber,} \recipient{HR Department}{Corporation\\123 Pleasant Lane\\12345 City, State} % Letter recipient \date{\today} % Letter date \enclosure[Attached]{ \begin{itemize} \item Lebenslauf \item Zeugnisse \end{itemize} } % List of enclosed documents \newcommand{\letterContentName}{beispielText.tex} %-------------------------------------------- %---------- End INDIVIDAL SETTINGS ------------ %-------------------------------------------- %-------------------------------------------- %--------- personal configuration and common settings %-------------------------------------------- \sffamily \renewcommand{\familydefault}{\sfdefault} % \renewcommand{\familydefault}{\rmdefault} \firstname{Dipl.-Inf.\\} \familyname{Sebastian B\"ohmer} % TODO because \@firstname does not work in command. \newcommand*{\getfirstname}{Dipl.Inf.} \newcommand*{\getfamilyname}{Sebastian B\"ohmer} \title{Lebenslauf} \address{Aachener Stra\ss{}e 6}{80804 M\"unchen} \mobile{+49~(0)176~24797990} \email{sebastian.boehmer@web.de} % \extrainfo{additional information (optional)} % optional, remove the line if not wanted %\photo[120pt]{sebastian_boehmer_bewerbungsphoto.jpg} \newcommand{\coverPagePhoto}{sebastian_boehmer_bewerbungsphoto.jpg} %-------------------------------------------- %--------------- End common settings -------- %-------------------------------------------- % to show numerical labels in the bibliography; % only useful if you make citations in your resume % \makeatletter % \renewcommand*{\bibliographyitemlabel}{\@biblabel{\arabic{enumiv}}} % \renewenvironment{thebibliography}[1]% % {% % \subsection{\refname}% % \small% % \begin{list}{\bibliographyitemlabel}% % {% % \setlength{\topsep}{0pt}% % \setlength{\labelwidth}{\hintscolumnwidth}% % \setlength{\labelsep}{\separatorcolumnwidth}% % \leftmargin\labelwidth% % \advance\leftmargin\labelsep% % \@openbib@code% % \usecounter{enumiv}% % \let\p@enumiv\@empty% % \renewcommand\theenumiv{\@arabic\c@enumiv}}% % \sloppy\clubpenalty4000\widowpenalty4000% % }% % {% % \def\@noitemerr{\@latex@warning{Empty `thebibliography' environment}}% % \end{list}% % } % \makeatother % bibliography with mutiple entries %\usepackage{multibib} %\newcites{unpub,pub}{{asdf}} % some defines \renewcommand{\baselinestretch}{1.2} \newcommand{\lineheight}[1]{\renewcommand{\baselinestretch}{#1}} \newcommand{\signature}{ % ~ \includegraphics[width=42pt]{signature}\\ Sebstian B\"ohmer\\ \textcolor{gray}{Dipl. Informatiker}} \setlength{\hintscolumnwidth}{3.5cm} %\nopagenumbers{} % uncomment to suppress automatic page numbering \setlength{\unitlength}{1cm} \newcommand{\tabitem}{~~\llap{\put(0,0.1){\circle{0.15}}}~~} % also \textbullet %\usepackage[absolute]{textpos} % for textblock \newcommand*{\tabularitemize}[1]{% \begin{itemize}% % \setlength\itemsep{10em}% \item #1% \end{itemize}% }% % \recomputelengths % \fancyfoot{} % \fancyfoot[LE,RO]{\thepage} % \fancyfoot[RE,LO]{\footnotesize } \newcolumntype{$}{>{\global\let\currentrowstyle\relax}} \newcolumntype{^}{>{\currentrowstyle}} \newcommand{\rowstyle}[1]{\gdef\currentrowstyle{#1}% #1\ignorespaces } %=================================================================================================== \begin{document} %\includegraphics[width=\columnwidth]{../../util/xxx.jpg} % cover page \thispagestyle{empty} \pagenumbering{gobble} % remove and set to 1 ~ \\ \vspace{5cm} \centering{\includegraphics[width=0.22\textwidth]{\coverPagePhoto}} \\ % 0.22 = length of text Bewerbung. \vspace{1cm} \centering{ \Huge{ Bewerbung \\ ~ \\ \textbf{\announcementPosition} \\ ~ \\ ~ \\ \textcolor{gray}{\getfirstname{}}~\getfamilyname{} \\ }} %\setlength{\textheight}{3cm} % end cover page \clearpage \pagenumbering{arabic} % set on and reset to 1 \maketitle \section{Pers\"onliche Daten} \cvitem{Name}{Sebastian B\"ohmer} \cvitem{Geburtsdatum}{26.~09.~1979} \cvitem{Familienstand}{ledig} \cvitem{Nationalit\"at}{deutsch} \lineheight{1.0} \section{Lebenslauf} \cventry{03/2013 -- 08/2016}{C++11 Softwareenwickler}{ALTEN GmbH}{}{}{ \begin{tabular}[t]{p{6cm}^l} \rowstyle{\bfseries} \tabitem{01/2016 - 08/2016} & ALTEN Group - Friedrichshafen \\ \multicolumn{2}{l}{~ ~ Ticketbearbeitung eines Kunden } \\ \multicolumn{2}{l}{~ ~ C++, ClearCase, CearQuest} \\ \rowstyle{\bfseries} \tabitem{07/2014 - 12/2015} & Airbus DS Optronics GmbH - Oberkochen \\ \multicolumn{2}{l}{~ ~ Programmierung zur parallelen Ansteuerung (Data Distribution System) der Ger\"ate} \\ \multicolumn{2}{l}{~ ~ C++11, QtCreator, Qt, OpenCV, Squish, Git} \\ \rowstyle{\bfseries} \tabitem{03/2013 - 06/2014} & Airbus DS Group - Ulm \\ \multicolumn{2}{l}{~ ~ Programmierung einer GUI f\"ur ein Workflow-Management-Programm} \\ \multicolumn{2}{l}{~ ~ C++, Qt, Oracle, VisualStudio, SVN} \\ \end{tabular} } %\cventry{}{asdf}{a}{b}{c}{d} \cventry{01/2011 -- 08/2012}{JavaEE Softwareentwickler}{CoCoNet GmbH - Erkrath}{}{}{ \begin{tabular}[t]{l} Programmierung von Sicherheitstechniken wie Token und Principals \\ in einer WebSphere Anwendung\\ JavaEE 4\&6, WebSphere, Oracle, JSP, SVN \\ \end{tabular} } \cventry{01/2010 -- 10/2010}{Befristeter C++ Softwareentwickler}{Fraunhofer EMI - Freiburg}{}{}{ \begin{tabular}[t]{l} Programmierung einer Simulation, der GUI- und der Datenbank \\ C++, Qt, QtCreator, SVN \\ \end{tabular} } \cventry{09/2005 -- 12/2009 w\"ahrend dem Studium}{HiWi C++ Softwareentwickler}{IMTEK - Freiburg}{}{}{ \begin{tabular}[t]{l} Programmierung einer Bildverarbeitung und Kamerasteuerung \\ im Institut f\"ur Mikrosystemtechnik (IMTEK)\\ Windows, MFC/CLR \\ \end{tabular} } \cvline{}{}{}{}{} \section{Universit\"are Ausbildung} \cventry{09/2000 -- 05/2010}{Studium der Informatik~(Dipl.-Inf.) und HiWi}{Universit\"at Freiburg}{}{}{} \section{Diplomarbeit} \cvline{Titel}{\emph{Microarray Biochip Analysis}} \cvline{Schwerpunkt}{Bioinformatik - Alignment of DNA} \cvline{Betreuer}{Prof. Dr. Backofen und Dr. Brandstetter} \cvline{Note}{2,5} \section{Softskills} \cvline{}{\begin{itemize} %does not work \lineheight{1.0} \item Eigenverantwortlich im Bereich Testen in Oberkochen. \item Selbst\"andig an Systemen mit Squish in Oberkochen. \item Zertifikat als ISTQB Tester Foundation Level. \item HiWi w\"ahrend dem Studium in Freiburg. \item Freude am Programmieren. \item Einige Kundenerfahrungen mit der Firma ALTEN GmbH. \item Hohe Lernbereitschaft und gute Begeisterungsf\"ahigkeit. \end{itemize} } \section{Fortbildungen, Konferenzen} \cvline{24/07/2015}{\textbf{ISTQB Certified Tester Foundation Level 2011} - M\"unchen} \cvline{15/12/2015}{Einf\"uhrung in \textbf{AUTOSAR f\"ur Entwickler} - M\"unchen} \cvline{01/2007, 01/2008}{Referent im \textbf{Summer-Campus C++} - Freiburg Universit\"at} \section{Ver\"offentlichungen} \cvline{2010}{\textbf{A polymer-based DNA biochip platform for human papilloma virus genotyping} ~ ~ Thomas Brandstetter, Sebastian B\"ohmer, J\"urgen R\"uhe et al. \textit{Journal of Virological Methods Vol.163, pp 40-48, 2010} }{}{} \cvline{2006}{\textbf{Fast Content-Based Image Retrieval Based on Equal-Average K-Nearest-Neighbor Search Shemes} ~ ~ Zhe-Ming Lu, Hans Burkhardt und Sebastian B\"ohmer \textit{PCM Volume 4261 series Lecture Notes in Computer Science pp 167-174, 2006} }{}{} \pagebreak \section{Computer} \subsection{Betriebssysteme} \cvline{}{Windows, Linux} \subsection{Programmierung} \cvline{}{ \begin{tabular}[t]{p{6cm}l} C - Expertenwissen & C++11 - Expertenwissen \\ Rust - Grundkenntnisse & Bash - erweiterte Kenntnisse \\ Python - Grundkenntnisse & Qt - Expertenwissen \\ Boost - Expertenwissen & OpenCV - erweiterte Kenntnisse \\ OpenGL - Grundkenntnisse & Java - erweiterte Kenntnisse \\ \end{tabular} } \subsection{Tools} \cvline{}{ \begin{tabular}[t]{p{6cm}l} Git - erweiterte Kenntnisse & SVN - Expertenwissen \\ Visual Studio - Expertenwissen & Eclipse - Expertenwissen \\ WebSphere - erweiterte Kenntnisse & CMake - erweiterte Kenntnisse \\ Qt-Projects - Expertenwissen & Squish - Expertenwissen \\ \end{tabular} } \subsection{Datenbanken} \cvline{}{ \begin{tabular}[t]{p{6cm}l} Oracle - Expertenwissen & MongoDB - Expertenwissen \\ MS Access - Grundkenntnisse & MySql - erweiterte Kenntnisse \\ \end{tabular} } \section{Sprachen} \cvlanguage{Deutsch}{Muttersprache}{} \cvlanguage{Englisch}{verhandlungssicher}{} \section{Freizeitinteressen} \cvline{}{\small Pod-Casts h\"oren und klassische Gitarre spielen} \section*{M\"unchen, den 22.09.2016} \cvline{}{\begin{tabular}{l}\signature\end{tabular}} %---------------------------------------------------------------------------------------- % COVER LETTER %---------------------------------------------------------------------------------------- % To remove the cover letter, comment out this entire block \ifthenelse{\equal{\configWithLetter}{1}}% if #1 is empty { \opening{ \vspace{2cm} ~ \\ \textbf{\announcementPosition} %\hfill \today \vspace{1cm} ~ \\ \salute} % Opening greeting \closing{Mit freundlichen Gr\"u\ss{}en, \\ ~ \\ \signature } % Closing phrase \clearpage \firstname{} % for letter footer \lastname{} % for letter footer \makelettertitle % Print letter title %-------------------- TEXT --------------------------- \input{\letterContentName} %-------------------- End TEXT ----------------------- \makeletterclosing % Print letter signature }{} %---------------------------------------------------------------------------------------- \end{document}

Geschäftsidee - Neue Ideen Schmiede - IdeaHub

Hallo,

DISCLAIMER
Der Name "Ideen Schmiede" stammt von einem Kommiliton Namens Sebastian, und nicht mir. Der Name wird hier nur als Synonym verwendet. Der Ideenname ist IdeaHub.


lange ist es her. Doch, könnt Ihr Euch noch an die Zeiten der MetaCrawler erinnern?
Hey, wir haben nicht nur in Google gesucht und die typischen Seiten wie Sxxx und "Wer bekommt welche Likes" angeklickt.
Ne, wir waren damals viiiiiiieeeeel fortgeschrittener, wir haben so etwas benutzt, was uns auf alle Suchmaschinen gleichzeitig suchen lässt.
Klar hat nichts gebracht, da ja kein Inhalt drin war.

:-)

Jetzt hier, in dem technologisch fortgeschrittenen Deutschland, ist mir eingefallen, dass es Sinn macht, einen Internet-Service anzubieten, der Facebook, Twitter, Youtube, Google+, Flickr, Instagram und SoundCloud kombiniert.
Ihr fragt Euch jetzt, ob das ein Misch aus allen Web 2.0/3.0 Diensten werden soll?
Nein. Es bietet eigentlich nur einen Publication-Service an. D.h. der Meta-Publisher bemüht sich darum Euren Inhalt/Content in den Platformen mit einem extra generierten Account zu publizieren.
Jeder User des Meta-Publishers "IdeaHub", bekommt eigene erzeugte Accounts auf Youtube, Twitter, Google+, Flickr, Instagram, DropBox und SoundCloud.

PRO:
- Das Gut ist, dass dabei eine Versicherung abgeschlossen wird, die garantiert, dass zu weniger als 80% keine Copy-Right/Urheberrechte verletzt werden.
- Ihr könnt weiterhin Geld mit YouTube Videos, Flickr Fotos oder Facebook Werbung verdienen.
- Es können weiterhin alle Inhalte geteilt werden.
- Die Inhalte sind auf den Platformen normal erreichbar.
- So bald Du einen Account erstellt hast, kannst Du kostenlos publizieren.
- Auch Ideen können im IdeaHub geteilt werden.
- Vielleicht findet sich eine Sponsormöglichkeit für Deine Idee.
- Und, IdeaHub publiziert als Kommentar, Link, Video oder Sound auf den supporteten Platformen mit nur einem Klick.

CONTRA:
- Naja, hunder Prozent Copy-Right Schutz kann ich mir nicht vorstellen.
- Vielleicht kommt Jemand auf die Idee, den Content von anderen IdeaHub Benutzern zu kopieren und unter seinem Namen zu publizieren. Wie blöd kann man schon sein, wenn es einen gemeinsamen Versicherungspool für genau diese Fälle gibt.
- Vielleicht ist kein jugendfreier Inhalt auf IdeaHub. Tja, wenn wir auf Copy-Right Vergleichen, dann können wir wunderbar automatisch auf jugendfrei Vergleichen.
- Wenn mir nichts einfällt, vielleicht Euch ... :-)

Auch diese Idee muss finanziert werden. Daher bitte den Blog als RSS-Feed abonieren, hier und unter Twitter @seboeh, wird demnächst die Seite für das CrowedFounding geposted.

Für Anmerkungen und Kommentare bin ich offen,

Euer Sebastian

.NET CLR C2872: 'IServiceProvider': ambiguous symbol

Recommendet blog for Solving 'IServiceProvider' ambiguousity.

https://qualapps.blogspot.de/2008/07/using-atlstrh-in-managed-project.html

That was a good starting point, but does not help me completely.
I started than to reduce one interface to eliminate the error by binary search.
Therefore I decide to eliminate a interface close to the last changes, which probably cause the compiler error.

The Strategy to solve this problem of finding the correct 'using namespace System' is to take a simple interface, which is probably close to the new changes you made, and comment out all members and implement all methods with no content.
The second step is to comment out some includes in this  interface hearder file. One of that include could be the reason of error.
The third step is, to compile the program, to see if the error disapear.

If the error disappear, you found the position of 'usin namespace System' before or inside include of omitted header. The omitted header in the interface you simplify.

If the error does not disappear, you have to reduce /simplify another interface with suspect includes.

Good Luck

 Find a tree, ideally, that's my strategy.

Frequenzen und Zufall

Hallo, 

Viele Fragen stellen sich die Informatiker und Mathematiker.
Eine davon ist die Frage nach dem Zufall.
Zwei Theorien werden hier präsentiert. Leider ist der Ursprung nicht bekannt.
Es sei auch gesagt, dass die Theorien etwas komisch klingen können. Soll heißen, auf eine gewisse Weise unverständlich sind.
Abschließend wird hier beschrieben, welchen möglichen mathematischen Zusammenhang es zwischen den Theorien und Beobachtungen gibt. Dies liefert eine Perspektive, um den Zufall zu betrachten.
Meine Inspiration habe ich aus dem grandiosen Beitrag von Prof. Taschner bekommen. Dieser Vortrag wurde am 27.9.2013 in Wien vorgetragen. Er hat den Titel "Irrtum des Pythagoras" und ist auf einer bekannten Videoplattform zu finden.

Als erstes fangen wir an die These aus der Regressionsanalyse zu betrachten. Diese führt uns zu einem Aspekt des Zufalls.
Die Theorie, welche ursprünglich aus der Physik kommt und etwas kurios ist, besagt, dass es kein Zufall gibt.
Wenn man die Atome und deren Bewegung voraus berechnen kann, dann würde man die Zukunft bestimmen können.
Das soll damit begründet sein, dass, nach der Theorie, Atome nur logische Zusammenhänge bilden können, welche dann berechenbar wären.
Das heißt unser Leben ist eine reine vorbestimmte Art.
 

Die andere These aus der Volkswirtschaftslehre bedient sich einer Rechenmethode, die quasi die Informatiker erfunden haben. Regressionsanalyse. Dabei werden beispielsweise zwei Variablen betrachtet: A und B.
Jetzt wird noch deren Zusammenspiel betrachtet AxB (gesprochen: A korrelierend mit B, oder A Kreuz B).
Letztlich bleibt in diesem stark vereinfachen Modell nur noch ein, sogenannter, Regressionsfehler übrig.
Dieser Regressionsfehler, der immer bei jedem Regressionsmodell vorhanden ist, zeigt uns die Eigenschaften vom Zufall. Meine Vermutung ist: Der Fehler ist ein Bestandteil vom Zufall. 

Wir holen nun etwas aus, um den Zusammenhang zwischen dem Regressionsfehler und dem Physikmodell zu sehen.
Angenommen das Universum sei in einem Urknall entstanden, was sicherlich nicht nur ein, sondern mehrere, Urknall waren, dann sagen die Physiker: Da alles miteinander verbunden ist und von Atomen, Energie und Kräften bestimmt wird, handelt es sich bei dem Regressionsfehler um das "Rauschen" vom Universum.
Informatiker glauben für gewöhnlich nicht daran, da sie die Regressionsrechnung quasi erfunden haben. Informatiker wissen auch, dass A und B nur mit einer gewissen Präzision berechnet / gemessen werden können. Und sich der Regressionsfehler wahrscheinlicher daraus ergibt.

Schauen wir auf unser Hilfskonstrukt, welches den Zufall unterstützt, welches in Prof. Taschners Vortrag vorgestellt wurde. Es ist in der Harmonielehre so, dass sich die Oktaven bilden, indem man die Strecke einer gesponnenen Saite jeweils halbiert. Soll heißen: Man spanne eine Seite auf und zupfe an ihr, so bekommt man eine gleichförmige Schwingung, welche einen Ton bildet. Die Pythagoreer haben nun einen Holzkeil in genau die Mitte der Saite gespannt. So, dass auf jeder Seite die halbe Strecke der Saite ist. Zupft man nun o.b.d.A an der rechten Seite, so entsteht der gleiche Ton, nur eine Oktav höher.
Teilt man diese rechte Seite wieder in der Hälfte, so schwingt die Saite noch eine Oktav höher.
Jetzt wollen wir nicht durch zwei rechnen, sondern mit 2/3. Wir setzen unseren Keil demnach bei zwei Drittel der Saite. Mit der größeren Seite verfahren wir genauso. So entsteht immer eine höhere Quint.
Der Fehler in der Harmonielehre ist nun der Wunsch: bei 12 mal Unterteilen wieder den Anfangston zu kommen.
Der Wunsch kommt daher, dass sich auf diese Art und Weise, so die Tasten auf dem Klavier gut anordnen lassen, um sowohl Oktaven wie auch Quinten zu spielen. Wie Prof. Taschner erwähnte, gibt es das Problem bei Saiteninstrumenten nicht. Die Interpreten der Saiteninstrumenten machen es automatisch "richtig".

Es ist in diesem zweiten Beispiel, der Harmonielehre, nun so, dass der Wunsch nach ganzzahliger Aufteilung, und kombinierbar mit der Oktave, den Fehler, dass der Quintenzirkel nicht genau den Oktavzirkel trifft, für Instrumente wie das Klavier, in Kauf genommen wird.

Bach wusste auch, wie man den Fehler verringert. Man verschiebt jeden Ton geringfügig, so dass dann der artengleiche Ton in einer anderern Tonlage nach 12 Quinten auftritt. Das nennt sich das wohltemperierte Klavier. (mehr dazu in Prof. Taschners Vortrag vom 27.9.2013) 

Nun zu den Zusammenhängen der beiden Fehler, oder besser Korrekturen.
Manche Physiker gehen davon aus, dass sich die Zukunft und damit auch der Zufall berechnen lässt. Wenn wir alle Atome kennen, d.h. wissen, wo sie im Verhältnis zu uns liegen, sowie, die Energien und die Kräfte kennen. Dann lässt sich die Zukunft voraus berechnen und es gibt keinen Zufall, so die Theorie. D.h. selbst, wenn wir die Zukunft nicht vorher bestimmt werden kann, da uns die Rechenpower fehlt, so wissen dennoch, dass es keinen Zufall gibt.
 

Das Modell geht jedoch davon aus, dass es Symmetrien gibt. Damit wird gemeint, dass es kein Chaos gibt, da ja alles vorherbestimmt ist. Das Modell meint zu wissen, wann, wo und wie sich die Atome, die kleinsten Teilchen, befinden und verhalten. Das Modell geht demnach davon aus, dass es sich berechenbar oder zumindest symmetrisch verhält.
Natürlich können irrationale Zahlen, wie sie die Harmonielehre zeigt, im Modell verwendet werden, jedoch sind die irrationalen Zahlen auch unendlich lang. 

Wenn man also mit einer irrationalen Zahl arbeitet, dann nur bis zu einer gewissen Präzision. Der Rest ist wieder Zufall. Denn, die irrationale Zahl ist unendlich lang. Und mit unendlich langen Zahlen kann man bei beschränkten Rechnern nicht rechnen. Wenn die Natur nun keine Rechenschwierigkeiten hat, so ist es immer noch Zufall, da auch wieder die unendlich lange irrationale Zahlen unendlich lang ist.
Soll heißen, die irrationale Gegebenheiten lässt sich nicht steuern/berechnen, und ist somit Zufall. Sowohl im Regressionsmodell als auch in der Harmonielehre.

Genauer, zeigt die Harmonielehre, dass es in der Natur kein symmetrisches Verhalten gibt. Die Aufteilung für den sauberen Klang ist eben die Logarithmierung der Saite. Und nicht das absichtlich schief justierte Klavier. Das wohltemperierte Klavier.
Die Natur richtet sich nicht nach der Harmonielehre. D.h. der Vogel trillert nicht wohltemperiert. D.h. Die Funk und Licht Wellen sind nicht wohltemperiert. Man sagt sie sind logarithmiert. Und dabei sind die Quint und die Oktav nicht überschneidend. Sie sind es sogar nie. Siehe dazu Taschners Vortrag - 27.9.2013. Zum Beispiel, bilden die Wellen Überlagerungen und diese kommen in irrationalen Frequenzen vor. Es wird vermutet, dass dadurch riesengroße Kavenzmänner entstehen können. 

Dies haben wir aus der Harmonielehre. Weiter können wir sagen:
Kombination unterschiedlicher Frequenzen bedeutet immer auch irrationale Frequenzen. Die Summe der Frequenzen sind nicht exakt aufeinander abstimmbar, sondern mit irrationalen Anteilen.

Was bedeutet dies nun? Was ist die Schlussfolgerung?

Aufgrund der Asymmetrie in der Natur, was uns die Harmonielehre gezeigt hat und den daraus folgenden irrationalen Zahlen, was wiederum Irrationalen in der Natur sind, folgt, dass der Fehler in der Regressionsanalyse Irrationalen sind. Und somit das Physikmodell, welches besagt, alles wäre vorbestimmt und nicht zufällig, widerlegt ist.
Denn, sei der Fehler in der Regressionsanalyse nicht zufällig, so wäre er auch nicht schwankend irrational. Das ist er jedoch aufgrund der Erkenntnis aus der Harmonielehre.
Dies bedeutet: Es gibt echten Zufall in der Natur.
Beispielsweise radioaktiver Zerfall, Maximale Peaks in Funkfrequenzen, Kavenzmänner und Neurotransmittersignale.

Mit freundlichen Grüßen,

Sebastian Böhmer, 6.6.2016

Why do we use quotation includes instead of library includes

Hi,

there is sometimes the discussion about the question: why is it useful to use quotation includes? This means includes with quotations,

  #include "anyFileName.h"

instead of includes of libraries,

  #include

Those question is mainly relevant for programmers in C++. Most other programmers can be happy and develop further on.

It's the baken of include question. And the best solution is, to use both, of-course.

The cream of the crop is, to use library include only for libraries. Though, if you include your own local files, which are not seperated by library-borders, it is necessary to include by quotation mark.

Let's have a look deeper.

The idea behind library includes is: that, you will shift the responsibility of include-paths to the configuration of your development-environment. This is especially usefull, if you see the computer as touring-machine, and in that way as a system which executes programms, but needs a configuration also.

Ok, if you use library includes to shift the responsiblity to configuration, it does not make any sense to apply path in the filename. Because, if you change the path of that libraries, and perhaps also a deeper path, it is necessary to change that internal/deeper path in all your files, which use the library. This is, what we like to eliminate with library include.

So, it makes no sens to add directories to library includes.

e.g.     #include


This causes the second problem, that all library files have to have a unique filename. For all libraries you use, e.g. if you like to have an own point or list implementation, you want to call the filenames "point.h" and "list.h", but they are already occupied by the library you use in the project also.

Therefore, you need local quotation include's. In this case, you can add a subpath to the filename and use it as e.g. #include "internalPath/point.h".

In the end it means: if you differ between namespaces or if you have local internal files only used by your application, use quotation includes, please.

Regards, Sebastian Böhmer, 06.04.2016

Sprachen in der Programmierung und ihre Anzahl

Dieses Dokument beschreibt die Thematik von Programmiersprachen. Es dient nicht einem Vergleich und nicht einer objektiven Einschätzung. Das Anliegen des Dokumentes ist es, den Sinn und Zweck von Sprachen in der Informatik zu beschreiben. Es werden grundlegende Gedanken erläutert, wie z.b. Was sind Sprachen? Wieviele Sprachen sind realistisch? Und wie realisieren wir eine mögliche Sprachlandschafe?
Zum Schluss wird eine aktuelle Tool-Chain genannt, mit der es möglich ist das Ziel der Sprachen zu erreichen.
Viel Spaß beim Lesen.

Sprachen in der Programmierung gibt es viele. Jede scheint ihre Berechtigung zu haben, doch wieviele Sprachen sind notwendig um korrekt zu modellieren?

Sprachen dienen dazu um im Computer zu modellieren bzw um ihn zu konfigurieren.
Am Ende wird auf eine Maschinencode-Ebene programmiert und konfiguriert. Letztlich steuert man den Elektronenfluss und wandelt einen elektrischen Input in einen Output um. Dabei wird der Input mit Sensoren aufgenommen und der Output durch Aktoren repräsentiert. Dazwischen gibt es viele unterschiedliche Features.
Features sind Merkmale, die die Translation des Inputs zum Output abstrahieren und so einen einfachen Umgang der Translation ermöglichen.
Generell kann man sagen, der Rechner besteht nur aus Bits, Transistoren und Kondensatoren. Die Bits kann man als Atome sehen, die Transistoren als Werkzeug und die Kondensatoren als Zeit. Raum ist derjenige, der benötigt wird um alle Transistoren, Kondensatoren und Leitungen zu platzieren. Demnach die Werkstatt.
Vielleicht werden Programmierer und Elektroingenieure daher als Bastler bezeichnet?

Was ist also eine Sprache? Wofür brauchen wir eine Sprache? Und warum brauchen wir eine Sprache?
Es ist so, dass der Rechner im Prinzip eine Touring-Maschine ist. Eine Touring-Maschine besteht aus einem Band, einem Alphabet und einem Schreiblesekopf. Die Daten stehen auf dem Band im Alphabet der Maschine geschrieben. Der Schreiblesekopf verarbeitet dann die Daten und schreibt sie wieder im Alphabet auf das Band. Oft an einer anderen Stelle des Bands. Das Band, d.h. der Speicher, bildet demnach auch einen Raum.
Doch was sind dann Sprachen?
Sie sind letztlich Features. Demnach dienen sie der Abstraktion und sind Werkzeuge der Logik. Logik ist wiederum eine Beschreibung um Gegebenheiten zu formulieren. D.h. auch eine Abstraktion. D.h. auch ein Feature. D.h. auch eine Sprache.
Es ergibt sich ein zyklischer Schluss. D.h. Sprachen formulieren Gegebenheiten.
"Du bist verheiratet" ist eine Gegebenheit. Sie ist aus anderen Gegebenheiten entstanden, wie z.B. Dass man sich kennenlernte.
Ist demnach alles eine Gegebenheit? Fast. Features, wie eine Sprache eröffnen eine neue Dimension. Eine Dimension, die nicht räumlich ist. Sondern kreativer, abstrakter und unendlicher Natur.
(Einstein: "Die Dummheit des Menschen und das Universum scheinen unendlich zu sein. Bei zweitem bin ich mir nicht ganz sicher.")
Sprachen dienen demnach der Kreativität, Abstraktion (als Feature) und Vielfältigkeit.

Somit ergibt sich die Frage des Blogs: Wieviele Sprachen sind notwendig?
Sprachwissenschaftler sagen: Jede Sprache, die aktuell von Menschen auf der Erde gesprochen werden, sind gleichwertig. D.h. es lässt sich in jeder Sprache den gleichen Gedanken in ähnlicher Effizienz, Effektivität, Robustheit und Transformität formulieren. Effizienz im Sinne von zeitlicher Geschwindigkeit, Effektivität im Sinne von vergleichbaren und gleichem Ergebnis, Robustheit im Sinne von Fehlerkorrektur und Transformität im Sinne von vielfältigen Variationen.
Sind alle Sprachen gleichwertig, so brauchen wir nur eine.
In der Informatik spricht man dabei von touring-vollständigen Sprachen.
Jetzt ist es jedoch so, dass wir weder wissen, ob uns ein Feature fehlt, in dem Touringmodell, noch wissen wir, ob wir alle erreicht haben.
In Prognosemodellen wissen wir, dass die Anzahl der unbekannten Variablen immer größer ist als die berücksichtigten.
Daher Sprechern wir mehr als eine Sprache.

Was heißt das in der Praxis?
Wie brauchen alle Sprachen, soweit sie sich deutlich unterscheiden. Deutlich unterscheiden bedeutet wiederum, sie müssen in ihren Wörtern, die Features präsentieren, so unterschiedlich sein, dass die Schnittmenge signifikant kleiner ist als die gesamte Anzahl der Wörter. D.h. die Schnittmenge sollte 80% nicht übersteigen. Konkret wäre das beste sie hätten keine Schnittmenge. Dann benötigen wir "beide" Sprachen.
Die Anzahl der notwendigen Sprachen ist somit abhängig davon, wie unterschiedlich sie sind. Wenige unterschiedliche Sprachen sind gleichwertig, zu vielen gleichen Sprachen. Zusätzlich zum Unterschied der Sprachen, ist die Anzahl der "notwendigen" Sprachen, abhängig von der Anzahl der Features (Worten unterschiedlicher Bedeutungen innerhalb der Sprache).

Im Chinesischem gibt es unterschiedliche Dialekte. Jedoch sind die Schriftzeichen gleich. So haben wir damit schriftlich die gleiche Bedeutung, jedoch sprachlich unterschiedliche Laute.
Dass bedeutet, dass im schriftlichen sich die Features zu 100% überschneiden, was tendenziell dazu führt, dass die Dialekte von der Bedeutung gleich sind, wir also keine weiteren Features gewinnen indem wir einen weiteren Dialekt lernen. Die gesprochene chinesische Sprache ist trotz ihrer Dialekte tendenziell gleich, da die Bevölkerung anhand der Zeichen weitere Bedeutungen lernt (insbesondere fachliche), so dass, trotz unterschiedlicher Laute, die gleiche Bedeutung entsteht. In anderen Sprachen ist es mit den Dialekten äquivalent. Auf die Theorie bezogen schließen wir, man erlangt keine weitere Dimension durch einen Dialekt.
(Ausnahme entsteht, wenn der Dialekt auch geschrieben wird, denn dann entsteht tendenziell auch eine andere Bedeutung. Bsp Servus vs. Tschüß und ciao. Servus soll herzlicher sein als Tschüß und ciao in Deutschland cooler.
Das zeigt auch, dass für gesprochene Sprachen die Bedeutung immer ortsspezifisch ist. Was bedeutet, dass alle gesprochenen Sprachen gleich wichtig sind zu lernen.)

Bei der Informatik kann man zum Glück reduzierter bleiben.
Geht man davon aus, man verwendet nur Sprachen, die sich in ihren Wörtern zu mindestens 20% unterscheiden. (da 20% der Breite der gaussschen Normalverteilung für nicht signifikante Abweichungen um den Erwartungswert entspricht), ergibt sich die Anzahl der "notwendigen" Sprachen anhand der existierenden Features.
Für Features gilt das gleiche wie für Sprachen, sie müssen sich in ihren Eigenschaften zu mindestens 20% unterscheiden.
Das praktisch zu betrachtene Feature ist atomar. Hat also nur eine Eigenschaft.
So ergibt sich die Anzahl der notwendigen Sprachen in der Informatik zum aktuellen Zeitpunkt hier Vorort und im Sinne der möglichen Verwaltung, anhand der atomaren Features der verwendeten Sprachen. (Ein Feature ist solange atomar, solange niemanden zwei Merkmale in diesem Feature einfallen, welche von der Mehrheit anerkannt werden.)

Atomare Features in der Informatik zum aktuellen Zeitpunkt, sind beispielsweise :
Kopieren, Zeiger, Vererbung, Polymorphismus, Verschiebung, Lokalisierung, Container, Schablonen, Timing, Responsbility und mehr. (Bitte in den Kommentaren erweitern.)

Das entspricht in der Programmierung :
Copyconstructor, Pointer, Inheritance, Adressen und Addressoperationen, class/structs, Templates/Generics, Multithreading/Concurrency und Handshakes, Visibility.

Das sind alles Features, die in c++ enthalten sind, jedoch nicht in c.
Wir erlangen durch diese Features in der höheren Programmiersprache somit mehrere zusätzliche Dimensionen.
Java kann dies auch, jedoch hat es bis auf den Gabagecollector nicht mehr zusätzliche Features. Es lohnt sich also nicht Java und C++ zu können, sondern nur den Unterschied zu wissen. (Pointer, Copy Paradigma, Gabagecollector.)
Es ist so, dass die Sprache C, z.B. das Feature Vererbung nicht kann. Dennoch ist die Sprache touringvollständig. D.h. es ist möglich das gleiche Programm in C, wie auch C++ zu schreiben. Jedoch in einer geringeren Dimension und somit nicht so kreativ und vielfältig. Modellierung, soweit dies bedeutet Eigenschaften der Gegebenheiten zu formulieren, ist in C schwerer, da wir weniger abstrahierende Dimensionen haben.

In der Informatik gibt es nun zusätzlich sogenannte Domain Specific Languages (DSL). Es werden dabei Sprachen verwendet, welche die Business Logik abdecken. Sie beziehen sich beispielsweise auf den Bereich des Bankings. Konkret: Ein Banker kann damit Zahlungen spezifizieren oder Gegebenheiten des broking modellieren. Z.B. kann er sagen: verkaufe Aktie, wenn der Wert niedriger ist als andere Aktie.

Brauchen wir diese?
Ja, denn sie erhöhen die Dimensionen. Und wenn die Dimensionen endlich sind, dann kommt man dem Ziel näher.
Domain spezifische Sprachen sind notwendig. Jedoch, sollten sie nicht zu ähnlich sein. Zusätzlich sollten sie ausschließlich atomare und unterschiedliche Features implementieren.
Zum Beispiel wären da: Ableitung, Integral, Korrelation/Faltung und auch Bewertungssysteme, Fuzzi Logik, Kooperation (friend classes) und Kooperationsstrategien und ihre Bestandteile (John Nash Equilibrium).

Tools :
Aktuell gibt es ein interessantes Tool, welches sich Embededer nennt.
Dieses ist, mit MSP (ein DSL Tool), zusammen ein Werkzeug, welches sich sehr gut zur Definition eigener DSL dient. Und was mittlerweile auch auf C++ aufbaut.
Daneben sind weitere Tools wie Spufax und Eclipse Xtext zu empfehlen.
Vielleicht lässt sich das automatic completion Tool Xtext auch mittlerweile mit Embededer kombinieren.

Wieviele DSLs brauchen wir?
Nur noch wenige, denn die Maschinen sind endlich.
Ideen und Dimensionen womöglich unendlich.

Disclaimer :
Die verwendeten Begriffe entsprechen nicht zu 100% der üblichen Verwendung.
Genaue Angaben/Referenzen können leider nicht hinzugefügt werden.
Rassistische Eindrücke sind nur aufgrund der Informatik zu verschulden.
Änderungen der eigenen Meinung sind unbeabsichtigt. Stand 2016. Ort München. Kostenlose Vervielfältigung ist erlaubt, unter hinzufügen dieses Reclaimer. Das gut unterliegt der Creative Common License 3.0, zu finden unter creative-common.org.
Autor Sebastian Böhmer.

Three Threads Streaming

Three Threads Stream

About

Many applications are performing an editing of their input. Especially in image processing. They all need to buffer their input, if they want to handle the processing. Especially, if you want to process the reading, modify and writing of data not in one thread. So, you need buffers between the threads.
Here it describes the problem and gives a solution in form of an implementation.
Afterwards this document discuss the timing problematic with too slow or too fast threads.
Below, you can add some comments about your opinion. Don't hesitate to ask some questions.

Problem

As in "about" described, we want to process data for reading, modifying and writing. Of course, we can use one single data address to process the reading, modifying and writing in one single thread. But now we want to do this with three different threads. One for reading, one for modifying and one for writing.
So you can say: lets use one data address for all three threads. To avoid a race condition (simultaneous writing and reading), we use a mutex, which we can lock.

The issue is, that when we use a mutex, it could be, that only the input thread is accessing the data, while the modify thread is every time again waiting on the lock. This happens, because when the modify thread is checking, if the mutex is free again, the input thread has lock the mutex again. In that way, the input thread is much more faster than the modifying thread. And in this way, we omit a lot of data to modify and write.


The modifying thread is called working thread further on. And the writing thread is called output thread in the implementation.

So it is not suitable to use a mutex here. Because, we have too fast access on the mutex. More detailed, the threads run in different speed, so it can be, that one thread is running twice as fast as the other. Or one thread is running at whole, while the other thread do nothing.
So at least we need two conditions: not_full and not_empty to indicate the different states of the cyclic buffer, if only one thread is running. This buffer and conditions are invented by batptiste-wicht[1].

The implementation

The buffer "BoundedBuffer"[1] is slightly modified. It is now a template based class.
We need two buffers. One to transfer the input data to working thread, called inputToWorkingBuffer, and one to transfer modified data to output thread called workingToOutputBuffer. There are two operations on that buffers. One for fetching the last data and one for depositing new data.
There are streams handling the fetching and depositing of the buffers. See the operators << and >> therefore. The code is also improved by r-value references. The r-value references permit the data to be moved into the buffer and moved from the buffer. So the copy process is reduced as much as possible. In the end, there are only one copy from input stream to buffer and one copy to output stream.

The BoundedBuffer

#pragma once /** * Under the license of LGPL V3.0 * http://www.gnu.org/licenses/lgpl-3.0.de.html * Copyright © 2015 Free Software Foundation, Inc. <http://fsf.org/> * Everyone is permitted to copy and distribute verbatim copies or changing * of this document is allowed. * Changed documents must contain this license notice. * You can use another license for your own changes. */ #include <mutex> #include <condition_variable> #include <iostream> #include <atomic> /** * @brief The BoundedBuffer class * A cyclic buffer, which has the read index everytime behind the write index. * The buffer size is given in the constructor. * @see http://baptiste-wicht.com/posts/2012/04/c11-concurrency-tutorial-advanced-locking-and-condition-variables.html */ template<typename T> class BoundedBuffer { public: typedef T value_type; value_type* buffer; size_t capacity; size_t front; size_t rear; std::atomic_size_t count; std::mutex lock; std::condition_variable not_full; std::condition_variable not_empty; BoundedBuffer(size_t capacity) : capacity(capacity), front(0), rear(0) { count.store(0); buffer = new value_type[capacity]; // XXX here you can allocate your frames once for the whole capacity. // Or you did not need to allocate, instead just move a pointer. } ~BoundedBuffer(){ delete[] buffer; // XXX here you would deallocate all the frames. } void deposit(value_type &&data){ std::unique_lock<std::mutex> l(lock); not_full.wait(l, [this](){return count.load() != capacity; }); buffer[rear] = data; rear = (rear + 1) % capacity; ++count; not_empty.notify_one(); } value_type && fetch(){ std::unique_lock<std::mutex> l(lock); not_empty.wait(l, [this](){return count.load() != 0; }); value_type result = buffer[front]; front = (front + 1) % capacity; --count; not_full.notify_one(); return std::move(result); } BoundedBuffer<t> & operator<<(typename BoundedBuffer<t>::value_type &&rhs) { deposit(std::move(rhs)); // Return-Value-Optimization (RVO) will simplify the return value. return *this; } BoundedBuffer<t> & operator>>(typename BoundedBuffer<t>::value_type &rhs) // const - not possible, because front. Solution: front as mutable. { rhs = std::move(fetch()); return *this; } template <t> friend std::ostream & operator<<(std::ostream &lhs, BoundedBuffer<t> &rhs); template <t> friend std::istream & operator>>(std::istream &lhs, BoundedBuffer<t> &rhs); }; template<typename T> std::ostream & operator<<(std::ostream &lhs, BoundedBuffer<t> &rhs) { lhs << rhs.fetch(); return lhs; } template<typename T> std::istream & operator>>(std::istream &lhs, BoundedBuffer<t> &rhs) { T value; lhs >> value; rhs.deposit(std::move(value)); return lhs; }

The main

/** * Under the license of LGPL V3.0 * http://www.gnu.org/licenses/lgpl-3.0.de.html * Copyright © 2015 Free Software Foundation, Inc. <http://fsf.org/> * Everyone is permitted to copy and distribute verbatim copies or changing * of this document is allowed. * Changed documents must contain this license notice. * You can use another license for your own changes. */ #include <iostream> #include <chrono> #include <thread> #include <atomic> #include <iostream> #include <future> // for std::async #include "BoundedBuffer.h" // Every-where you find XXX you have to change something /** * some specifications * Every-where you find XXX you have to change something */ namespace ttt { // XXX check the parameters: // the data type of the buffers. E.g. pointer on image frame. Here an integer. typedef int dataType; // capacity of all two buffers. static const int capacity = 100; // here only for simulation of input elements. This is the count. static const int inputMax = 10000; // delay in the three threads. static const std::chrono::milliseconds delay {8}; // used to indicate the end of inputThread. static std::atomic_bool isFinished; } using namespace std; // input thread template<typename T> void threadInputFnc(BoundedBuffer<t> &buffer, std::chrono::milliseconds delayMs) { for (T i=0; i < ttt::inputMax; ++i) { // XXX here you have to grab the frame and move it to the buffer. buffer << std::move(i); std::this_thread::sleep_for(delayMs); } ttt::isFinished.store(true); } // working thread template<typename T> void threadWorkingFnc(BoundedBuffer<t> &outBuffer, BoundedBuffer<t> &inBuffer, std::chrono::milliseconds delayMs) { T x; while (!ttt::isFinished.load()) { inBuffer >> x; std::this_thread::sleep_for(delayMs); // XXX here you make your calculations on the frame. Here just multiple of 2. outBuffer << x*2; } } // output thread template<typename T> void threadOutputFnc(BoundedBuffer<t> &buffer, std::chrono::milliseconds delayMs) { while (!ttt::isFinished.load()) { // XXX the output can be designed in other ways. // you can clean the frame pointer here. Also release the memory, if you allocated above. std::cout << '\r' << buffer; std::cout.flush(); std::this_thread::sleep_for(delayMs); } } int main() { cout << "starting ..." << endl; BoundedBuffer<ttt::dataType> inputToWrokingBuffer(ttt::capacity); BoundedBuffer<ttt::dataType> workingToOutputBuffer(ttt::capacity); auto inputThread = std::async(std::launch::async, threadInputFnc<ttt::dataType> , std::ref(inputToWrokingBuffer) // ref, because & ref in thread fnc. , ttt::delay); auto workingThread = std::async(std::launch::async, threadWorkingFnc<ttt::dataType> , std::ref(workingToOutputBuffer) , std::ref(inputToWrokingBuffer) , ttt::delay); auto outputThread = std::async(std::launch::async, threadOutputFnc<ttt::dataType> , std::ref(workingToOutputBuffer) , ttt::delay); outputThread.get(); workingThread.get(); inputThread.get(); cout << "Finished." << endl; return 0; }

There are three threads in the main declared: inputThread, workingThread and outputThread. With get(), we wait of finishing the threads in reverse order of creation. std::ref(buffer) is needed on calling threads, because the buffer should be changed outside of the threads.

If all works correctly, we get the output of only even numbers from 0 to ttt::inputMax.

Timing Issues

There are 2^3 timing issues. This is because, every thread can be too slow or too fast. Those, timing issues are handled by some tricks. For example, if the outputThread is too fast, we can repeat the last frame.

All tricks are:

• If working is too slow or input too fast, overwrite old data in inputToWorkingBuffer.
• If input is too slow or working too fast, repeat return of last data in inputToWorkingBuffe.
• If working is too slow or output too fast, repeat display of last data.
• If output is too slow or working too fast, overwrite old data in workingToOutputBuffer.

fetch() must be changed to:

value_type && fetch(const std::chrono::milliseconds &delayCheckOnEmpty){ std::unique_lock<std::mutex> l(lock); not_empty.wait_for(l, delayCheckOnEmpty, [this](){return count.load() != 0; }); if (count.load() == 0) { return buffer[front]; }
And we have to change deposit() slightly. All correct code will be in the gitHub[2]. void deposit(value_type &&data) { std::unique_lock<std::mutex> l(lock); not_full.wait_for(l, delayCheck, [this](){return count.load() != capacity; }); if (count.load() == capacity) { size_t i = front.load(); front.store((i+1) % capacity); } else { ++count; }

The front size_t needs to be changed to atomic, because it is used in fetch() and deposit().


Have a lot of fun, Sebastian

References

[1] http://baptiste-wicht.com/posts/2012/04/c11-concurrency-tutorial-advanced-locking-and-condition-variables.html
[2] https://github.com/SebastianBoehmer/example/tree/master/threeThreadsStream

Why to use linked list more often than dynamic arrays

Hello together,

About

today, it is about an issue, which concerns every computer consultant, programmer or computer scientist.
This topic is discussed about 56 million times on google (search string "list vs vector"). We need a clear decision to program qualitative and efficient programs. It is late in time to clarify the misunderstanding. And, you get the information for free. Independent on your location. This information is important to everyone, independent if you are a chief or a student.

The question is: What is the preferred container for your data?

We enlighten two containers: the list and the dynamic array (also called vector).

List

A list is a set of nodes, which consists of the data and one pointer to the next node. Nodes can be everywhere in the memory.
To have a reference to the list, we have a pointer to start of the list.
With few effort, we can also have a pointer to end of the list. This end-pointer is state of the art and typically the case (e.g. in STL lists), so we assume this additional condition.
More about lists you can read in "Algorithm and Data Structures"[1] or in the internet[2]

Vector

A vector is a set of data. This set is continuously combined in the memory.
To have a reference to the vector we have a so called offset.
More about dynamic arrays (vectors) can be read in "Algorithm and Data Structures"[1] or in the internet[3].

 The court

Most people prefer vectors over list. This was my experience in my research. 
Additionally, People using vectors blame people using lists to use vectors.
We assume therefore, that vector is the claimant and list is the defender.
So, we start with the arguments of using a vector.

Arguments of people using vectors:
- random access
- less memory
- faster allocation of memory
- faster indexing technical and theoretical
- compactness / discriminative

Claim of vectors

Random Access
There is the argument, that vectors have random access to their underlying data. This means, with a simple calculation of offset+x*s you get the memory position of the x'th data with size of data s. So, you can access the memory randomly in time O(1).
They claim: A list have to iterate from start x'th times to the next node.
This take O(n) time (see [1] for explanation of O-Notation).

Less Memory
They argue, that a list have to allocate additional memory for their next pointers. Lists allocate n times the next pointer, with a pointer currently 4 bytes in memory.
So, a dynamic array would only allocate the necessary space, while list would allocate the necessary space plus the next pointers. This is more space than necessary.

Faster Allocation of Memory
They claim the list to allocate the memory every time of a next element, which is every time a request to the system for free memory space. They argue, the request would take time, because some memory is already allocated and some memory is not allowed to use. Therefore, the system have to use complicated algorithms to request the memory space. Vectors, on the other hand, allocate only once their whole data space.

Faster Indexing Technical and Theoretical
First of all the technical is faster for vectors. They only have to calculate the next address of an arbitrary element in the container. While lists are using the next pointer to get the address. Therefore, they have to fetch the memory for the next pointer, while an array have only one calculation.
The second is the theoretical disadvantage of a list. The list have to iterate from start to the x'th node to get the data. This takes O(n) time.


Compactness / Discriminative
Additionally, there is an argument that lists are not compact. The nodes are equally distributed over the memory. So, loading the data into a cache does not have the same effect like for dynamic arrays.
Further on, "compactnes matters" - is it called from a famous computer expert.
This argument ("matters") is a little bit complicated. As far as I understand, it means: if you have compact data, you are not jumping around every time.
I will add the argument "Discriminative". This means, an array is allocating a whole memory block, so the data is distinguished between blocks. If your input is now distinguished between blocks, it is more easy to discriminate for the computer than it would be if the data is equally distributed. Some algorithms, which try to predict, have that problem of discrimination. This is used for example in the area of pattern recognition.

Plea

The defence appeals to innocent.


Random Access
This is true. Arrays have a faster random access than lists.
When do you need it? The most time you process data sequential.
Of course, your sensor or user input have random values, but the input is processed sequential.
Only if you have the inputs, which are coordinates according to an element of data. This is for example the case, if you have user input from the screen. On the screen you have input by the mouse in the form of coordinates. According to the coordinates, there are underlying elements on the screen, which should be processed.
Lists deputy argue, this case is the only one. In all other cases it is better to use lists, because they are processed sequential.
Please use lists more often than dynamic arrays!


Less Memory
To be honest, arrays wast memory also. They allocate memory, which is not immediately used.
Therefore ,you have to understand the concept for dynamic arrays.
Vector argue: There are tricks to reduce this allocation problem by creating a list of vectors.
The plea calls objection - this is manipulative. In this case comparison between lists and vectors are not possible.
Lets go back to the description of dynamic arrays.
Dynamic arrays double the size of allocated data at growing. Growing happens when you insert a new element to a filled dynamic array. In this moment, the array is allocating twice the current size and copies the old data to the new memory space. The old space is deleted afterwards.
This will take time and space. The time you need is amortized O(1) (see Table of O-Notations in [2]) to append a new element at the back of the array (the so called push_back() function). The space you need is amortized 3/4 * n space. This means you waste 1/4 * n space. We assume that an array is filled step by step with push_back(). So the averaged space used by the array is 3/4 full and 1/4 empty.
The plea want to submit evidence:
This evidence describe the amount of memory wasted by the list.
A pointer has currently 4byte. This is allocated n times. Makes 4*n byte.
The plea argue: If you have a data size s, which is over 16 byte, the array would wast memory of 1/4 * n * s. This is minimal 4 * n byte of memory. This is at least waisting as much space as a list do, for a >= 16byte data element.
On a machine with 64bi, using two integers reaches the size of 16bytes. See therefore [4].
The plea appeals to innocent, because of really rare exceptions of data structs below 16 byte.
Vector is interrupting: For big data we use pointers to the data.
The plea counters: Then, the advantage of arrays are going lost, because you need additional memory fetching.
The plea appeals to innocent in this case, cause lack of evidence!
Please use lists for data-elements above 16 bytes!
Doubles have already 8 byte[5]!

Faster Allocation of Memory
The plea is defending to innocent, because memory allocation is issued by array and list equally.
The defence submits some evidence: We are discussing about dynamic memory allocation. And about the currently common method of using blocks to handle the memory.
Dynamic memory allocation means, memory allocation while run-time.
Compared with static memory allocation, while compile-time, this is not yet allocated when you start the program.
The currently common method to use blocks is used to help avoiding fragmentation. As far as I understand, fragmentation is a problem, when you want to insert a big data-element and found no continuous space for it. Instead you have many small free spaces. So, you would have enough memory, but because of fragmentation there is no space for the big data.
The plea argue, if all data would have the same size, fragmentation would not happen. The problem therefore is not the size per se, but the difference in size.
So, arrays and lists are both equally guilty.
The plea appeals: In case of the accused.
The court sad: Fragmentation is not relevant here.

The plea gives them right and goes back to the topic.
The claimant intersects: The problem of allocation is not the fragmentation, but the overhead by the repeated allocation by the list.
The plea argues, that disadvantage is only different from array allocation if you use big arrays. In case of big arrays, the system will allocate a new block according to the size of the array, which is bigger than a threshold. In case of small arrays, the system have to look into the current block also. In this case of small arrays, you have to allocate often small arrays for big input.
So, you are also investigating the overhead.
Because of equal concern, the plea appeals for innocent.
Please use lists more often!

Faster Indexing - Technical and Theoretical
Technical is the indexing on arrays a calculation, whereas the indexing on lists is a fetching.
The plea agrees: This is a difference.
The computational steps on a list are:
1. reading memory address of next pointer from the register R2
2. fetching data from memory to register R1
3. and fetching next pointer from memory to register R2

The computational steps on a vector are:
1. increasing the index in the register
2. adding the offset from the register
3. fetching data from memory

Point 1. of array is typically an improvement for arrays.
The true steps of array would be:
1. reading index from register R1
2. calculating index + 1
3. reading offset from register R2
4. calculating index + offset
5. fetching data from memory to register R3

The plea appeals to think about the advantage on pipe-lining for fewer computational steps, as for lists.
Lists have no calculations.
The plea appeals to think about the register size.
List need only two register and therefore the processor can handle more lists synchronously.
Please, use lists for mixing different input!


Compactness / Discriminative
The plea begs the court to drop the argument of compactness, because it's misunderstanding.
My own argument Discriminative will be dropped, because the input is generally not discriminative. If the input would be discriminative, we could easily predict, just depending on which input we got. You would say, if the sensor A gives a signal it is an elephant and if the sensor B gives the signal it is a rabbit.

Conclusion

None of the arguments of vectors have had an evidence to prefer vectors over lists. Also, the performance is not arguable better.

Dynamic arrays are not better than lists.
Lists are more related to Touring-Machines.
If memory matters, use lists. If speed matters use vectors.
The problem is currently, that the additional data (next pointer) in the list
is used in the processing, while the additional data in the array (reserved fields) is not used in the processing.
This means, if speed really matters, the array would be better. Even though, fetching is slower than calculation, and lists do one more fetching.
On the other hand, the additional data of the list is only 4 byte for each element. And it is more recommended to use lists for big data (>16 bytes). See argument "less memory" above.
This means, if memory matters, use lists.


Beside the argument of memory, random access takes into account.
Use vectors only if you have random access mapping to data.
For example a user input by mouse on the screen. The mouse coordinate can be used to directly find the underlying data. This is also the case for mapping. In this case a map, which is a special array, is the best choice.
In all other cases, please prefer lists over vectors.
Your first question should be: Is my underlying data bigger than 16 bytes, then I use a list.
Now you can argue, nearly every primitive data type is below 16 byte (on 32bit machines). So we can split the data type bigger than 16 byte in several arrays with primitive data types.
That is true, you can do this if you can program in that way.
Normally, it is like baking a cake. You need different ingredients like milk, wheat, eggs and butter. Now you are combining the ingredients and processing them in the oven. In the end you should get a cake.
I don't know how to bake a cake without mixing the ingredients together.
Perhaps it is possible to mix the ingredients together in the last moment. This would be very hard to program.

Other Argue

"One block allocation - if you don't have enough memory to provide a single block (but you have sufficient scattered memory blocks) to allocate the space for the array then you'll need to defragment and other similar stuff to first create a free block of that size. So you may like to term it as improper utilization of memory :-)"
[http://geekexplains.blogspot.de/2008/05/array-vs-linked-list-advantages-and.html]

[http://programmers.stackexchange.com/questions/185222/what-is-the-point-of-using-lists-over-vectors-in-c]

References

[1] Th. Ottmann, P. Widmayer. Algorithmen und Datenstrukturen. xvii+716 Seiten, 4. Auflage, Spektrum Akademischer Verlag, Heidelberg 2002
[2] http://en.wikipedia.org/wiki/Linked_list 2015
[3] http://en.wikipedia.org/wiki/Dynamic_array 2015
[4] http://en.wikipedia.org/wiki/Integer_%28computer_science%29
[5] http://en.wikipedia.org/wiki/Floating_point