Tag Archive for: Data Science

Valentin Curtef

Deep Learning and Human Intelligence – Part 1 of 2

/in , , , , , /by

Many people are under the impression that the new wave of data science, machine learning and/or digitalization is new, that it did not exist before. But its history is as long as the history of humanity and/or science itself.  The scientific discovery could hardly take place without the necessary data. Even the process of discovering the numbers included elements of machine learning: pattern recognition, comparison between different groups (ranking), clustering, etc. So what differentiates mathematical formulas from machine learning and how does it relate to artificial intelligence?

There is no difference between the two if seen from the perspective of formulas however, such a perspective limits the type of data to which they can be applied. Data stored via tables consist of structured data and are stored in so-called relational databases. The reason for such a data storage is the connection between different fields that assume a well-established structure in advance, such as a company’s sales or balance sheet. However, with the emergence of personal computers, many of the daily activities have been digitalized: music, pictures, movies, and so on. All this information is stored unrelated to other data and therefore called unstructured data.

IEEE International Conference on Computer Vision (ICCV), 2015, DOI: 10.1109/ICCV.2015.428

Copyright: IEEE International Conference on Computer Vision (ICCV), 2015, DOI: 10.1109/ICCV.2015.428

The essence of scientific discoveries was and will be structure. Not surprisingly, the mathematical formulas revolve around relations between variables – information, in general. For example, Galileo derived the law of falling balls from measuring the successive hight of a falling ball. The main difficulty was to obtain measurements at regular time intervals. What about if the data is not structured, which mathematical formula should be applied then? There is a distribution of people’s height, but no distribution for the pictures taken in all holidays for the last year, there is an amplitude for acoustic signals, but no function that detects the similarity between two songs. This is one of the reasons why machine learning focuses heavily on clustering and classification.

Roughly speaking, these simple examples are enough to categorize the difference between scientific discovery and machine learning. Science is about discovering relationships between different variables, Machine Learning tries to automatize processes. Every technical improvement is part of the automation, so why is everything different in this case? Because the current automation deals with human intelligence. The car automates the walking, the kitchen stove the fire, but Machine Learning parts of the human intelligence. There is a difference between the previous automation steps and those of human intelligence. All the previous ones are either outside the human body – such as Fire – or unconsciously executed (once learned) – walking, spinning, etc. The automation induced by Machine Learning affects a part of the human intelligence that we consciously perceive. Of course, today’s machine learning tools are unable to automate all human intelligence, but it is a fascinating step in that direction.

A breakthrough in Machine Learning tasks was achieved in 2012 when the first Deep Learning algorithm for detecting types of images, reached near-human accuracy. It could appreciate the likelihood that the image is a human face, a train, a ball or a fish without having “seen” the picture before. Such an algorithm can be used in various areas:  personally – facial recognition in pictures and/or social media – as tagging of images or videos, medicine – cancer detection, etc. For understanding such cutting-edge issues of classification, one cannot avoid understanding how Deep Learning works. To see the beauty of such algorithms and, at the same time, to be able to comprehend the difficulty of working with them, an example will be the best guide.

The building blocks of Deep Learning are neurons, operational units, which perform mathematical operations or logical operations like AND, OR, etc., and are modelled after the neurons in the brain. Already in the 1950’s two neuroscientist, Hubel and Wiesel, observed that not all neurons in the brain are responding in the same fashion to visual stimuli. Some responded only to horizontal lines, whereas others to vertical lines, with other words, the brain is constructed with specialized neurons. Groups of such neurons are called, in the Machine Learning community, layers. Like in the brain, neurons with different properties are clustered in different layers. This implies that layers have also specific properties and have to be arranged in a specific way, called architecture. It is this architecture which differentiates Deep Learning from Artificial Neuronal Networks (ANN are similar to a layer).

Unfortunately, scientists still haven’t figured out how the brain works, thus to discover how to train Deep Learning from data was not an easy task, and is also the reason why another example is used to explain the training of Deep Learning: the eye. One has always to remember: once it is known how Deep Learning works, it is simple to find example which illustrates the working mechanism.  For such an analogy, it is sufficient for someone without any knowledge about Deep Learning, to keep in mind only the elements that compose such architectures: input data, different layers of neurons, output layers, ReLu’s.

Input data are any type of information, in our example it is light. Of course, that Deep Learning is not limited only to images or videos, but also to sound and/or time series, which would imply that the example would be the ear and sound waves, or the brain and numbers.

Layers can be seen as cells in the eye. It is well known that the eye is formed of different layers connected to each other with each of them having different properties, functionalities. The same is true also for the layers of a Deep Learning architecture: one can see the neurons as cells of the layer as the tissue. While, mathematically, the neurons are nothing more than simple operations, usually linear weight functions, they can be seen as the properties of individual cells. Each layer has one weight matrix, which gives the neuron (and layer) specific properties depending on the data and the task at hand.

It is here that the architecture becomes very important. What Deep Learning offers is a default setting of the layers with unknown weights. One can see this as trying to build an eye knowing that there are different types of cells and different ways how tissues of such cells can be arranged, but not which cell exactly is needed (with what properties) and which arrangement of layers works best. Such an approach has the advantage that one is capable of building any type of organ desired, but the disadvantage is also very obvious: it is time consuming to find the appropriate cell properties and layers arrangements.

Still, the strategy of Deep Learning is a significant departure from the Machine Learning approaches. The performance of Machine Learning methods is as good as the features engineering performed by Data Scientists, and thus depending on the creativity of the Data Scientist. In the case of Deep Learning the engineers of the features is performed automatically as part of the model building. This is a huge improvement, as the only difficult task is to have enough data and computer power to find the right weights matrices. Such an endeavor was performed also by nature for the eye — and is also the reason why one can choose it as an example for Deep Learning — evolution. It is not surprising that Deep Learning is one of the best direction scientists have of Artificial Intelligence today.

The evolution of the eye can be seen, from the perspective of Data Scientists, as the continuous training of a Deep Learning architecture which enables to recognize and track one or more objects. The performance of the evolutional process can be summed up as the fine tuning of the cells which are getting more and more susceptible to light and the adaptation of layers to enable a better vision. Different animals in different environments and different targets — as the hawk and the fly — developed different eyes than humans, but they all work according to the same principle. The tasks that Deep Learning is performing today are similar, for example it can be used to drive cars but there is still a difference:  there is no connection to other organs. Deep Learning is not the approximation of an Artificial Organism, like an android, but a simplified Artificial Organ that can work on its own.

Returning to the working mechanism of the Deep Learning architecture, we can already follow the analogy of what happens if a ray of light is hitting the eye. Once the eye is fully adapted to the task, one can followed how the information enters the Deep Learning architecture (Artificial Eye) by penetrating the input layer. already here arises the question, what kind of eye is the best? One where a small source of light can reach as many neurons as possible, or the one where the light sources reaches only few neurons? In order to take such a decision, a last piece of the puzzle is required: ReLu. One can see them as synapses between neurons (cells) and/or similarly for tissue. By using continuous functions, such as the shape of the latter ‘S’ (called sigmoid), the information from one neuron will be distributed over a large number of other neurons. If one uses the maximum function, then only few neurons are updated with processed information from earlier layers.

Such sparse structures between neurons, was a major improvement in the development of the technique of training Deep Learning architectures. Again, it has a strong evolutionary analogy: energy efficiency. By needing less neurons, the tissues and architecture are both kept to a minimal size which enables flexibility in development and less energy. As the information is process by the different layers, the Artificial Eye is gathering more and more complex (non-linear) structures — the adapted features –, which help to decide, from past experience, what kind of object is detected.

This was part 1 of 2 of the article series. Continue with Part 2.

Benjamin Aunkofer

Interview – Die Herausforderungen der Sensor-Datenanalyse für die Automobilindustrie

/in , , , , /by

Interview mit Andreas Festl von VIRTUAL VEHICLE

Andreas Festl ist Data Scientist bei VIRTUAL VEHICLE, ein führendes F&E Zentrum für die Automobil- und Bahnindustrie mit Sitz in Graz, Österreich. Das Zentrum konzentriert sich auf die konsequente Virtualisierung der Fahrzeugentwicklung. Wesentliches Element dabei ist die Verknüpfung von numerischer Simulation und Hardware-Testen, welche ein umfassendes HW-SW Systemdesign sicherstellt. Herr Festl forscht dort an Kontext-basierten Informationssystemen für den Einsatz im Fahrzeug und in der Entwicklung. Er ist ausgebildeter Mathematiker, der sich schon früh dem Thema Data Science verschrieben hat. Zusätzlich ist Herr Festl in der Lehre für Data and Information Science an der Fachhochschule Joanneum tätig.

Data Science Blog: Herr Festl, Sie sind technischer Data Scientist und arbeiten mit Daten, die zum großen Teil von Maschinen generiert werden. Was unterscheidet Ihren Arbeitsalltag vermutlich von den Data Scientists, die sich mit geschäftlichen Daten befassen?

Das wesentliche Merkmal an den Daten, mit denen wir arbeiten, ist die nicht vernachlässigbare zeitliche Komponente. Stellen Sie sich zum Beispiel eine Messung der Fahrzeuggeschwindigkeit vor: Dieses Messsignal kann natürlich nur dann sinnvoll interpretiert und verarbeitet werden, wenn die Zeit mitberücksichtigt wird. Die bloße Kenntnis der einzelnen Geschwindigkeitswerte hilft Ihnen ohne die korrekte Abfolge nicht weiter. Das führt dazu, dass viele Algorithmen aus dem Bereich des maschinellen Lernens nicht direkt auf diesen Daten arbeiten können.

Es existieren hier natürlich dennoch viele Möglichkeiten und Ansätze dafür, Wissen aus den Daten zu gewinnen; diese werden jedoch scheinbar noch nicht so oft verwendet, weshalb die verfügbare Software meist nicht für industrielle, sondern für akademische Nutzer ausgelegt ist. Ein wesentlicher Teil meiner Arbeit besteht deshalb darin, die passenden Libraries zu finden und diese für unsere Use-Cases anzupassen oder die Methode neu zu implementieren. Es gibt durchaus immer wieder Zeiten in denen meine Job-Beschreibung „mathematischer Programmierer“ lauten sollte und nicht “Data Scientist“. Ich denke, das ist im klassischen Bereich, der sich geschäftlichen Daten beschäftigt, vielleicht nicht mehr so häufig, da dort die verfügbare Software schon sehr ausgreift ist.

Außerdem beschreiben unsere Daten oft komplexe technische Prozesse in Fahrzeugkomponenten. Hier ist eine rege Kommunikation mit den jeweiligen Domänenexperten unerlässlich, damit ich auch als fachfremder Data Scientist den Prozess, der die Daten erzeugt, zumindest in Grundzügen verstehen kann. Dieser kommunikative Teil, in dem man sehr viel über verschiedenste Fachbereiche erfährt, ist für mich einer der schönsten Aspekte meiner Arbeit.

Data Science Blog: Wenn Data Science einem Laien erklärt wird, kommen häufig Beispiele von Kaufempfehlungen oder Gesundheitsprognosen von Fitness-Apps zur Sprache. Welches Beispiel würden Sie im Kontext von Automotive verwenden?

Die Möglichkeiten für den Einsatz von Data Science im Automotive Bereich sind extrem vielfältig – sie kann eigentlich über den gesamten Lebenszyklus eines Fahrzeugs gewinnbringend eingesetzt werden. Ein Einsatzbeispiel, das der Fahrer direkt positiv erleben kann, wäre die Predictive Maintenance von Fahrzeugteilen. Ähnlich zu den von Ihnen angesprochenen Fitness-Apps geht es hier darum eine „Gesundheitsprognose“ für die einzelnen Fahrzeugteile anhand von Messwerten zu erstellen. Im Idealfall müssen Sie Ihr Auto dann nicht mehr in fixen Service-Intervallen in die Werkstatt stellen, sondern das Auto meldet sich automatisch kurz bevor ein Teil ausgetauscht werden muss. Diese Meldung erschiene dann deshalb, weil die Messwerte darauf schließen lassen, dass es bald zu einem Defekt kommen wird und nicht einfach nach einem fixen, vorher definierten Zeitraum. Heute werden ja Teile oft einfach deswegen ausgetauscht, weil es der Wartungsplan so vorsieht – unabhängig von ihrer tatsächlichen Abnutzung.

Data Science Blog: Was sind denn gegenwärtig besonders interessante Anwendungsfälle und an welchen arbeiten Sie für die Zukunft?

Aus Sicht der Anwendung finde ich es besonders spannend durch Sensor-Signale auf Eigenschaften des Fahrers zu schließen. Die Methodik dazu entwickeln wir gerade in aktuellen Projekten. Es ist zum Beispiel durchaus denkbar, sicherheitsrelevante Ereignisse und Fahrmanöver zu identifizieren. Diese Informationen können dann vielseitig verwendet werden. Einige Beispiele dazu: Verkehrsplaner könnten damit automatisiert besonders gefährliche Kreuzungen angezeigt bekommen, Versicherer könnten ihren Kunden auf das individuelle Risikoverhalten abgestimmte Produkte anbieten oder Kunden könnten sich Ihren Taxifahrer über eine App nach seinem Fahrstil aussuchen. Denkbar wäre auch eine Diebstahlsicherung: Das Fahrzeug erkennt über den Fahrstil, dass es von einer unbefugten Person benutzt wird und löst daraufhin einen Alarm aus. Hier eröffnen sich viele Möglichkeiten.

Aus Sicht der Datenanalyse finde ich es besonders interessant, Algorithmen, die für ganz andere Aufgabenstellung entwickelt wurden, auf Probleme aus dem Automotive-Bereich anzuwenden. In einem unserer Projekte analysieren wir beispielsweise Software-Logfiles von Prüfständen und verwenden dazu Association Rules (eine Technik aus der Warenkorbanalyse) und Methoden, die normalerweise für das Untersuchen von Interaktionen in sozialen Netzwerken verwendet werden. Dass diese Übertragbarkeit gegeben ist finde ich extrem spannend.

Data Science Blog: Über welche Datenquellen verfügen Sie? Gibt es auch fahrzeugexterne Datenquellen, die sinnvoll sein könnten?

Da sprechen Sie natürlichen einen kritischen Punkt in jedem Data Science Projekt an: Ohne Daten geht nichts. Zusätzlich müssen die verwendeten Daten eine gewisse Qualität aufweisen und natürlich mit dem zu lösenden Problem in möglichst direktem Zusammenhang stehen.

Welche Datenquellen wir genau verwenden, hängt natürlich sehr stark vom konkretem Projekt ab. In industrienahen Projekten werden die Daten in der Regel vom Industriepartner bereitgestellt. Das kann dann alles Mögliche sein: Messungen von Prüfständen, Fertigungs-Protokolle, Wartungsdaten und vieles mehr.

Diese „Industrie-Daten“ unterliegen dann aber üblicherweise einer strengen Geheimhaltung und dürfen nicht in anderen Projekten verwendet werden. Deshalb haben wir im Unternehmen einen eigenen Datenlogger entwickelt, mit dem wir selber Daten aufnehmen können, die dann uns gehören. Diese Daten verwenden wir hauptsächlich in forschungsnahen Projekten, in denen die Ergebnisse publiziert werden sollen.

Fahrzeugexterne Datenquellen sind definitiv sinnvoll und werden immer mehr mit den klassischen Sensor-Daten fusioniert; oft ergibt sich dann durch eine Kombination von proprietären und offen verfügbaren Daten ein großer Mehrwert. In der vorhin angesprochenen Erkennung von sicherheitsrelevanten Ergebnissen spielt zum Beispiel das Wetter eine wesentliche Rolle: Eine zu schnell gefahrene Kurve ist bei Nässe oder Glätte deutlich gefährlicher als auf trockener Fahrbahn. Generell werden Daten über Umwelt und Infrastruktur immer wichtiger. Praktisch jeder fahrerzentrierte Dienst benötigt sie. Denken Sie zum Beispiel an Google Maps, das bereits heute die Bewegungsdaten von vielen Verkehrsteilnehmern gemeinsam analysiert um Vorhersagen über die Verkehrsdichte und damit über die optimale Route zu treffen.

Data Science Blog: Wie aufwändig gestaltet sich das Data Engineering, also die Datenbereitstellung und -zusammenführung?

Das ist definitiv ein schwieriges Unterfangen. Gerade Sensordaten erreichen schnell eine beachtliche Größe, die den Einsatz eines Big Data Technologie-Stacks erforderlich macht. Hier macht uns aber wieder die bereits angesprochene zeitliche Komponente unserer Daten zu schaffen. Die meisten Big Data Technologien skalieren ja, indem sie die Datenpunkte mehr oder weniger zufällig auf mehrere Rechner verteilen. Das ist bei unseren Daten aber nicht zulässig, die Reihenfolge der Daten ist hochrelevant! Hier müssen wir also entweder auf einer anderen Ebene parallelisieren oder Technologie mit spezieller Funktionalität für Zeitreihen verwenden.

Data Science Blog: Welche Technologien setzen Sie für die Datenbereitstellung und -analyse ein? Was halten Sie vom Einsatz von Open Source Software?

Wir implementieren unsere Analysen meist in R oder Python, manchmal kommen auch Matlab oder C# (letzteres meist für User Interfaces) zum Einsatz. Für Big Data Analysen verwenden wir meist Apache Spark über die R und Python APIs. Für die Datenablage und Bereitstellung verwenden wir hauptsächlich PostgreSQL mit Timescale Erweiterung, InfluxDB sowie Apache Hadoop. Grundsätzlich sind wir jedoch nicht auf bestimmte Technologien fixiert, sondern versuchen immer das jeweils beste Tool für den jeweiligen Einsatzzweck zu verwenden.

Ich finde es spricht nichts gegen den Einsatz von Open Source Software – wie Sie ja auch an unserem Technologie-Stack erkennen können. Ich habe aber auch nichts gegen Closed Source Software – es gibt in beiden Bereichen genug gute und schlechte Software. Worauf ich aber achte, ist keine neue Technologie zu verwenden, hinter der ein zu kleines Entwicklerteam oder gar nur ein einzelner Entwickler steht. Hier ist mir die Gefahr zu groß, dass die Entwicklung bald eingestellt wird und die Ergebnisse meiner Analysen nicht mehr nachvollziehbar sind.

Data Science Blog: Zum Abschluss noch eine Frage von jungen Nachwuchskräften, die davon träumen, eine Karriere als Data Scientist im Ingenieurwesen zu machen: Welche Voraussetzungen bzw. Eigenschaften sollte ein Data Scientist in Ihrem Bereich mitbringen?

Neben einer fundierten fachlichen Ausbildung sind Neugier und der Wille, Zusammenhänge zu verstehen, Eigenschaften, die für jeden Data Scientist sehr wichtig sind. Zusätzlich hilft es durchaus eine kommunikative Persönlichkeit zu sein: Es gilt in Workshops die richtigen Informationen über die Daten einzuholen – das ist nicht immer ganz leicht. Zusätzlich müssen natürlich regelmäßig die Resultate der jeweiligen Analysen einem oft fachfremden Publikum präsentiert werden.

Christopher Kipp

Analyse der Netzwerktopologie des Internets auf Basis des IPv4-Protokolls

/in , , , , , , , , , , , , /by

Wie kommen Daten die man via Internet quer durch die Welt sendet eigentlich an ihr Ziel? Welchen Weg nehmen beispielsweise die Datenpakete, wenn ich von mir zu Hause eine Datei an meinen Nachbarn ein Haus weiter sende? Wie groß ist der “Umweg”, den die Daten nehmen? Und macht es eigentlich einen Unterschied, ob ich www.google.de, www.google.com oder www.google.nl aufrufe, oder gehen alle Suchanfragen sowieso an dasselbe Ziel?

Fragen wie diese lassen sich durch eine Kombination von Tools wie traceroute oder tracepath und geoiplookup beantworten und unter Verwendung des Python-Paketes geoplotlib sogar graphisch auf einer Weltkarte darstellen. Die so gewonnenen Ergebnisse zeigen Teile der Netzwerktopologie des Internets auf und führen zu interessanten, teils unerwarteten Erkenntnissen.

Ziel dieses Artikels soll sein, ein möglichst einfaches Tutorial zum selber mitbasteln bereit zu stellen. Die einzelnen Schritte die hierfür notwendig sind, werden möglichst einfach verständlich dargestellt und erklärt, trotzdem sind zum vollständigen Verständnis grundlegende Kenntnisse in Python sowie der Kommandozeile hilfreich. Er richtet sich aber auch an alle, die sich einfach einmal etwas in ihrer virtuellen Umgebung „umschauen“ möchten oder einfach nur an den Ergebnissen interessiert sind, ohne sich mit den Details und wie diese umgesetzt werden, auseinander setzen zu wollen.  Am Ende des Artikels werden die einzelnen Skripte des Projekts als zip-Datei bereitgestellt.

Hinweis: Diese Anleitung bezieht sich auf ein Linux-System und wurde unter Ubuntu getestet. Windows-User können beispielsweise mit dem Befehl tracert (als Ersatz für traceroute) ähnliche Ergebnisse erziehlen, jedoch muss dann das Parsing der IP-Adressen abgeändert werden.

1. Grundsätzliches Erkunden der Route, die ein Datenpaket nimmt

Hierfür wird ein Programm wie traceroute, tracepath oder nmap benötigt, welches durch Versenden von „abgelaufenen Datenpaketen“ die Hosts „auf dem Weg“ zum Ziel dazu bringt, ihre IPv4-Adresse zurück zu geben. In diesem Artikel wird beispielhaft traceroute verwendet, da dieses unter den meisten Linux-Versionen bereits zur „Grundausstattung“ gehört und somit für diesen Schritt keine weitere Software installiert werden muss. Die Verwendung von traceroute folgt der Syntax:

Als Ziel muss hier die IP-Adresse bzw. der Domainname des Zielrechners angegeben werden. Ein Beispiel soll dies vereinfachen:

Im Beispiel wird die Route zum Hostrechner mit der Domain www.google.de ermittelt. In der ersten Spalte der Ausgabe ist die Nummer des jeweiligen „Hops“ zu sehen. Wichtig ist insbesondere die zweite Spalte, welche die IPv4-Adresse des jeweiligen Rechners auf dem Weg zum Ziel darstellt. Die folgenden Spalten enthalten weitere Informationen wie Antwortzeiten der jeweiligen Server und die IP-Adressen der Folge-Server.

Um die Ausgabe in eine Form umzuwandeln, welche später einfacher von Python gelesen werden kann, muss diese noch ausgelesen werden (Parsing). zuerst soll die erste Zeile der Ausgabe herausgeschnitten werden, da diese zwar informativ, jedoch kein Teil der eigentlichen Route ist. Dies kann sehr einfach durchgeführt werden, indem die Ausgabe des traceroute-Befehls an einen Befehl wie beispielsweise sed „gepiped“ (also weitergeleitet) wird. Die dabei entstehende Pipe sieht dann wie folgt aus:

Um bei unserem Beispiel mit der Route zu www.google.de zu bleiben, sieht der Befehl und die Entsprechende Ausgabe wie folgt aus:

Anschließend soll die zweite Spalte der Ausgabe herausgeschnitten werden. Dies ist am einfachsten mit dem Befehl awk zu bewerkstelligen. Das Prinzip dahinter ist das gleiche wie im obigen Schritt: die Ausgabe des vorherigen Befehls wird dem Befehl awk als Eingabe weitergeleitet, womit der gesamte Befehl nun wie folgt aussieht:

Bezogen auf das google-Beispiel sehen Ein- und Ausgabe nun so aus:

Im letzten Schritt sollen die einzelnen IP-Adressen durch Leerzeichen getrennt in eine einzelne Zeile geschrieben werden. Sinn dieses Schrittes ist, dass später viele Zielrechner nacheinander aus einer Datei eingelesen werden können und jede Route zu einem Zielrechner als eine einzelne Zeile in eine Zieldatei geschrieben wird.
Auch dieser Schritt funktioniert ähnlich wie die obigen Schritte, indem die Ausgabe des letzten Schrittes an einen weiteren Befehl weitergeleitet wird, der diese Funktion erfüllt. Dieser Schritt könnte wieder mit dem Befehl sed durchgeführt werden, da aber nur ein einzelnes Zeichen (nämlich das Zeilenumbruch-Zeichen bzw. Newline) durch ein Leerzeichen ersetzt werden soll, wird hier aufgrund der einfacheren Syntax der Befehl tr verwendet.
Der fertige Befehl sieht nun wie folgt aus:

Oder im fertigen Beispiel mit www.google.de:

Hiermit ist das Parsen abgeschlossen und die fertige Ausgabe kann nun in eine Ergebnisdatei geschrieben werden. Um automatisch viele Zielrechner aus einer Datei einzulesen und alle gefundenen Routen in eine Zieldatei zu schreiben, wird der obige Befehl in eine Schleife „verpackt“ welche die Zielrechner Zeile für Zeile aus der Datei zieladressen.txt ausliest und die gefundenen Routen ebenso Zeile für Zeile in die Datei routen.csv schreibt. Die Datei routen.csv kann später zur Ermittlung verschiedener Informationen zu den gefunden IP-Adressen einfach mit einem Python-Skript eingelesen und geparst werden.

In diesem Artikel wird das fertige Skript ohne weitere Erklärung in der beiliegenden zip-Datei bereitgestellt. Wen die genaue Funktionsweise der Schleife interessiert, sei angehalten sich generell über die Funktionsweise von Shellskripten einzulesen, da dies den Rahmen des Artikels sprengen würde.

Dieses Skript benötigt die Datei zieladressen.txt welche wie folgt aussehen muss (anstatt Domainnamen können auch direkt IPv4-Adressen verwendet werden):

2. Sammeln von (Geo-)Informationen zu bestimmten IPv4-Adressen

Die gefundenen IPv4-Adressen können anschließend mit dem Befehl geoiplookup oder über die Internetseite http://geoiplookup.net/ relativ genau (meißtens auf Städteniveau) lokalisiert werden. Dies funktioniert, da einzelne Subnets in der Regel bestimmten Regionen und Internetprovidern zugeordnet sind.

Der Befehl geoiplookup greift hierbei auf eine vorher installierte und lokal gespeicherte Datenbank zu, welche je nach installierter Version als Country- oder City-Edition vorliegt. Da geoiplookup nicht zu den Standartbordmitteln unter Linux gehört und um die weiteren Schritte auch Benutzern anderer Betriebssysteme zu ermöglichen, wird hier nur ein kurzes Beispiel der Benutzung dieses Befehls und dessen Ausgabe gegeben und im weiteren die Online-Abfrage mittels eines Python-Skriptes beschrieben.

Die Internetseite http://geoiplookup.net bietet einen Onlineservice welcher Geo- und weitere Informationen zu gegebenen IPv4-Adressen bereitstellt. Öffnet man die Seite ohne Angabe einer IP-Adresse in einem Browser, so erhält man die entsprechenden Informationen über die eigene IP-Adresse. (Achtung: die Verwendung eines Proxies oder gar Tor führt zwangsläufig zu falschen Ergebnissen.)

Da die Seite auch über eine API (also eine automatisierte Abfrageschnittstelle) unter der Adresse “http://api.geoiplookup.net/?query=${IPADRESSE}” verfügt, kann man die entsprechenden Informationen zu den IP-Adressen mittels eines Pythonskriptes abfragen und auswerten. Als Antwort erhält man eine XML‑Datei welche beispielsweise folgendermaßen aussieht:

Diese kann im Browser z. B. unter der Adresse http://api.geoiplookup.net/?query=77.20.253.87 aufgerufen werden (oder unter: http://api.geoiplookup.net/ für die eigene Adresse).

Um die hierin enthaltenen Informationen mit Hilfe von Python auszulesen lässt sich ElementTree aus aus dem Modul xml.etree, das in der Python-Standartbibliothek vorhanden ist, verwenden. Dies wird im beiliegenden Skript mit der Funktion get_hostinfo() bewerkstelligt:

Diese parst die XML-Datei automatisch zu einem Python-DefaultDict das dann die entsprechenden Informationen enthält (das DefaultDict wird verwendet da normale Python Dictionaries zu Fehlern führen, wenn nicht gesetzte Werte abgefragt werden). Die Ausgabe der Funktion sieht dann wie folgt aus:

3. Plotten der gefundenen Routen mit geoplotlib auf einer Weltkarte

Wichtig für das anschließende Plotten ist hierbei die Geolocation also ‘latitude’ und ‘longitude’. Mit den Werten kann man anschließend die mit traceroute gefundenen Pfade als Basemap plotten. Dies funktioniert mit der Funktion drawroutes2map():

Der Plot einer Verbindungsanfrage an www.google.de aus Berlin sieht beispielsweise folgendermaßen aus:

Hier wird deutlich, dass Datenpakete durchaus nicht immer den kürzesten Weg nehmen, sondern teilweise rund um die Welt gesendet werden (Deutschland – USA – Sydney(!) – USA), bevor sie an ihrem Ziel ankommen und dass das Ziel einer Verbindung zu einer Domain mit der Endung „de“ nicht unbedingt in Deutschland liegen muss.

Mit Default-Einstellungen werden von der Funktion drawroutes2map() alle Routen in zufälligen Farben geplottet, welche in der Datei routen.csv gefunden werden.

Lässt man viele Routen plotten wird hierbei die Netzwerkstruktur deutlich, über die die Daten im Internet verteilt werden. Auf dem obigen Plot kann man recht gut erkennen, dass die meisten Internetseiten in Europa oder den USA gehostet werden, einige noch in China und Japan, dagegen beispielsweise Afrika praktisch unbedeutend ist.

Auf dem nächsten Plot wiederum ist zu erkennen, dass es tatsächlich eine Art “Hotspots” gibt über die fast alle Daten laufen, wie z. B. Frankfurt am Main, Zürich und Madrid.

4. Schematische Darstellung der Routen als directed Graph mit graphviz

Mit graphviz lassen sich schematische Graphen darstellen. Mit dem Paket pygraphviz existiert hiefür auch eine Python-Anbindung. Die schematische Darstellung als Graph ist in vielen Fällen deutlich übersichtlicher als die Darstellung auf einer Weltkarte und die Topologie des Netzwerkes wird besser sichtbar.

Die entsprechende Python-Funktion, die alle Routen aus der Datei routes.csv als geplotteten Graph ausgibt ist drawroutes2graph():

Die Funktion schreibt den erstellten Graph in der Dot-Language in die Datei routes.dot und erstellt zwei verschiedene visuelle Darstellungen als png-Dateien.

Da mit der Funktion get_hostinfo() auch weitere Informationen zu den jeweiligen IP-Adressen verfügbar sind  können diese auch visuell im Graph dargestellt werden. So sind in der folgenden Darstellung Hosts in verschiedenen Ländern in unterschiedlichen Farben dargestellt. (Deutschland in grün, USA in rot, Spanien in gelb, Schweiz in blau, China in magenta und alle übrigen Länder und Hosts ohne Länderinformation in schwarz).

Diese Art der Darstellung vereint damit die Vorteile der schematischen Darstellung mit der Geoinformation zu den jeweiligen Hosts. Aus der Grafik lässt sich beispielsweise sehr gut erkennen, dass, trotz oft vieler Zwischenstationen innerhalb eines Landes, Landesgrenzen überschreitende Verbindungen relativ selten sind.

Auch interessant ist, dass das Netzwerk durchaus Maschen aufweist – mit anderen Worten: Dass ein und dieselbe Station bei verschiedenen Verbindungsanfragen über verschiedene Zwischenstationen angesprochen wird und Daten, die von Punkt A nach Punkt B gesendet werden, nicht immer denselben Weg nehmen.

5. Schlussfolgerung

Was kann man hieraus denn nun letztendlich an Erkenntnissen ziehen? Zum einen natürlich, wie Daten via Internet über viele Zwischenstationen rund um die Welt gesendet und hierbei mit jeder Station neu sortiert werden. Vor allem aber auch, dass mit dem entsprechenden Know-How und etwas Kreativität mit bemerkenswert wenig Code bereits Unmengen an Daten gesammelt, geordnet und ausgewertet werden können. Alle möglichen Daten werden in unserer heutigen Welt gespeichert und sind zu einem nicht unbeträchtlichen Teil auch für jeden, der weiß, wer diese Daten hat oder wie man sie selber ermitteln kann, verfügbar und oft lassen sich hier interessante Einblicke in die Funktionsweise unserer Welt gewinnen.

Benjamin Aunkofer

Interview – Python as productive data science environment

/in , /by

Miroslav Šedivý is a Senior Software Architect at UBIMET GmbH, using Python to make the sun shine and the wind blow. He is an enthusiast of both human and programming languages and found Python as his language of choice to setup very productive environments. Mr. Šedivý was born in Czechoslovakia, studied in France and is now living in Germany. Furthermore, he helps in the organization of the events PyCon.DE and Polyglot Gathering.

On 26th June 2018 he will explain at the Python@DWX conference why “Lifelong Text Hackers Use Vim and Python”. Insert the promotion code PY18science to unlock your 10% discount on all tickets. More info and tickets on python-con.com.

Data Science Blog: Mr. Šedivý, how did you find the way to Python as your favorite programming language?

Apart from traditional languages taught at school (Basic, Pascal, C, Java), some twenty years ago I learned Perl to hack a dynamic web site and used it to automate my daily tasks. Later I used it professionally for scientific calculations in the production. This was later replaced by Python, its newer versions and more advanced libraries. Nowadays Python has almost completely replaced Perl as my principal language and I use Perl just to hack some command line filters and to impress colleagues.

Data Science Blog: Python is one of the most popular programming language for data scientists. This is remarkable as it is originally not designed for doing data science with it. What made it a competitor to languages like R or Julia?

Python is the most powerful programming language that is still legible. This appeals to data scientists who can enter each line interactively, and immediately see what happens, because each line actually does something. They can inspect their data easily and build automating systems to process their data transparently.

Data Science Blog: Is there anything you could do better with another programming language?

Sometimes I’m playing with some functional languages that would allow me to write code that is easier to test and parallelize.

Data Science Blog: Which libraries are the most important ones for your daily business?

The whole Pandas ecosystem with Numpy and Scipy. Matplotlib for plots, PyTables and Psycopg2 for storage. I’m also importing a few async libs for webservices and similar network-based software.

I also enjoy discovering the world of Unicode and Timezones – both of them are the spots where the programmers absolutely have to obey the chaotic reality of the outside world.

Data Science Blog: Which editor do you use? And how to set it up as a productive environment?

I tried several editors and IDEs, but always came back to Vi or Vim. This is an extremely powerful editor that is around since over forty years, which was probably before most of today’s active developers learned to type. I’m using it for all text editing tasks, which I’m actually going to show in my talk at DWX [Lifelong Text Hackers Use Vim and Python]. Steep learning curve is not an argument against a tool you can grok during your entire career.

Data Science Blog: In your opinion: For all developers and data scientists, who are used to Java, Scala, R oder Perl, is Python easy to learn? Could it be too late to switch for somebody?

Python is a great general language that can be learned rapidly to a usable level. It’s different from the aforementioned languages. I remember my switching process from Perl to Python over ten years ago with a book “Perl to Python Migration”, which forced me to switch my way of thinking. From the question “Why do I have to import ‘re’ for regular expressions if Perl uses them natively?” to “Actually, I can solve this problem without regular expressions.”.

Benjamin Aunkofer

Machine Learning vs Deep Learning – Wo liegt der Unterschied?

/in , , , , , /by

Machine Learning gehört zu den Industrie-Trends dieser Jahre, da besteht kein Zweifel. Oder war es Deep Learning? Oder Artificial Intelligence? Worin liegt da eigentlich der Unterschied? Dies ist Artikel 1 von 6 der Artikelserie –Einstieg in Deep Learning.

Machine Learning

Maschinelles Lernen (ML) ist eine Sammlung von mathematischen Methoden der Mustererkennung. Diese Methoden erkennen Muster beispielsweise durch bestmögliche, auf eine bestmögliche Entropie gerichtete, Zerlegung von Datenbeständen in hierarchische Strukturen (Entscheidungsbäume). Oder über Vektoren werden Ähnlichkeiten zwischen Datensätzen ermittelt und daraus trainiert (z. B. k-nearest-Neighbour, nachfolgend einfach kurz: k-nN) oder untrainiert (z.B. k-Means) Muster erschlossen.

Algorithmen des maschinellen Lernens sind tatsächlich dazu in der Lage, viele alltägliche oder auch sehr spezielle Probleme zu lösen. In der Praxis eines Entwicklers für Machine Learning stellen sich jedoch häufig Probleme, wenn es entweder zu wenige Daten gibt oder wenn es zu viele Dimensionen der Daten gibt. Entropie-getriebene Lern-Algorithmen wie Entscheidungsbäume werden bei vielen Dimensionen zu komplex, und auf Vektorräumen basierende Algorithmen wie der k-nächste-Nachbarn-Algorithmus sind durch den Fluch der Dimensionalität in ihrer Leistung eingeschränkt.

Der Fluch der Dimensionalität

Datenpunkte sind in einem zwei-dimensionalen Raum gut vorstellbar und auch ist es vorstellbar, das wir einen solchen Raum (z. B. ein DIN-A5-Papierblatt) mit vielen Datenpunkten vollschreiben. Belassen wir es bei der Anzahl an Datenpunkten, nehmen jedoch weitere Dimensionen hinzu (zumindest die 3. Dimension können wir uns noch gut vorstellen), werden die Abstände zwischen den Punkten größer. n-dimensionale Räume können gewaltig groß sein, so dass Algorithmen wie der k-nN nicht mehr gut funktionieren (der n-dimensionale Raum ist einfach zu leer).

Auch wenn es einige Konzepte zum besseren Umgang mit vielen Dimensionen gibt (z. B. einige Ideen des Ensemble Learnings)

Feature Engineering

Um die Anzahl an Dimensionen zu reduzieren, bedienen sich Machine Learning Entwickler statistischer Methoden, um viele Dimensionen auf die (wahrscheinlich) nützlichsten zu reduzieren: sogenannte Features. Dieser Auswahlprozess nennt sich Feature Engineering und bedingt den sicheren Umgang mit Statistik sowie idealerweise auch etwas Fachkenntnisse des zu untersuchenden Fachgebiets.
Bei der Entwicklung von Machine Learning für den produktiven Einsatz arbeiten Data Scientists den Großteil ihrer Arbeitszeit nicht an der Feinjustierung ihrer Algorithmen des maschinellen Lernens, sondern mit der Auswahl passender Features.

Deep Learning

Deep Learning (DL) ist eine Disziplin des maschinellen Lernes unter Einsatz von künstlichen neuronalen Netzen. Während die Ideen für Entscheidungsbäume, k-nN oder k-Means aus einer gewissen mathematischen Logik heraus entwickelt wurden, gibt es für künstliche neuronale Netze ein Vorbild aus der Natur: Biologische neuronale Netze.

Prinzip-Darstellung eines künstlichen neuronalen Netzes mit zwei Hidden-Layern zwischen einer Eingabe- und Ausgabe-Schicht.

Wie künstliche neuronale Netze im Detail funktionieren, erläutern wir in den nächsten zwei Artikeln dieser Artikelserie, jedoch vorab schon mal so viel: Ein Eingabe-Vektor (eine Reihe von Dimensionen) stellt eine erste Schicht dar, die über weitere Schichten mit sogenannten Neuronen erweitert oder reduziert und über Gewichtungen abstrahiert wird, bis eine Ausgabeschicht erreicht wird, die einen Ausgabe-Vektor erzeugt (im Grunde ein Ergebnis-Schlüssel, der beispielsweise eine bestimmte Klasse ausweist: z. B. Katze oder Hund). Durch ein Training werden die Gewichte zwischen den Neuronen so angepasst, dass bestimmte Eingabe-Muster (z. B. Fotos von Haustieren) immer zu einem bestimmten Ausgabe-Muster führen (z. B. “Das Foto zeigt eine Katze”).

Der Vorteil von künstlichen neuronalen Netzen ist die sehr tiefgehende Abstraktion von Zusammenhängen zwischen Eingabe-Daten und zwischen den abstrahierten Neuronen-Werten mit den Ausgabe-Daten. Dies geschieht über mehrere Schichten (Layer) der Netze, die sehr spezielle Probleme lösen können. Aus diesen Tatsachen leitet sich der übergeordnete Name ab: Deep Learning

Deep Learning kommt dann zum Einsatz, wenn andere maschinelle Lernverfahren an Grenzen stoßen und auch dann, wenn auf ein separates Feature Engineering verzichtet werden muss, denn neuronale Netze können über mehrere Schichten viele Eingabe-Dimensionen von selbst auf die Features reduzieren, die für die korrekte Bestimmung der Ausgabe notwendig sind.

Convolutional Neuronal Network

Convolutional Neuronal Networks (CNN) sind neuronale Netze, die vor allem für die Klassifikation von Bilddaten verwendet werden. Sie sind im Kern klassische neuronale Netze, die jedoch eine Faltungs- und eine Pooling-Schicht vorgeschaltet haben. Die Faltungsschicht ließt den Daten-Input (z. B. ein Foto) mehrfach hintereinander, doch jeweils immer nur einen Ausschnitt daraus (bei Fotos dann einen Sektor des Fotos), die Pooling-Schicht reduzierte die Ausschnittsdaten (bei Fotos: Pixel) auf reduzierte Informationen. Daraufhin folgt das eigentliche neuronale Netz.

CNNs sind im Grunde eine spezialisierte Form von künstlichen neuronalen Netzen, die das Feature-Engineering noch geschickter handhaben.

Deep Autoencoder

Gegenwärtig sind die meisten künstlichen neuronalen Netze ein Algorithmen-Modell für das überwachte maschinelle Lernen (Klassifikation oder Regression), jedoch kommen sie auch zum unüberwachten Lernen (Clustering oder Dimensionsreduktion) zum Einsatz, die sogenannten Deep Autoencoder.

Deep Autoencoder sind neuronale Netze, die im ersten Schritt eine große Menge an Eingabe-Dimensionen auf vergleichsweise wenige Dimensionen reduzieren. Die Reduktion (Encoder) erfolgt nicht abrupt, sondern schrittweise über mehrere Schichten, die reduzierten Dimensionen werden zum Feature-Vektor. Daraufhin kommt der zweite Teil des neuronalen Netzes zum Einsatz: Die reduzierten Dimensionen werden über weitere Schichten wieder erweitert, die ursprünglichen Dimensionen als abstrakteres Modell wieder rekonstruiert (Decoder). Der Sinn von Deep Autoencodern sind abstrakte Ähnlichkeitsmodelle zu erstellen. Ein häufiges Einsatzgebiet sind beispielsweise das maschinelle Identifizieren von ähnlichen Bildern, Texten oder akkustischen Signalmustern.

Artificial Intelligence

Artificial Intelligence (AI) oder künstliche Intelligenz (KI) ist ein wissenschaftlicher Bereich, der das maschinelle Lernen beinhaltet, jedoch noch weitere Bereiche kennt, die für den Aufbau einer KI von Nöten sind. Eine künstliche Intelligenz muss nicht nur Lernen, sie muss auch Wissen effizient abspeichern, einordnen bzw. sortieren und abrufen können. Sie muss ferner über eine Logik verfügen, wie sie das Wissen und das Gelernte einsetzen muss. Denken wir an biologische Intelligenzen, ist es etwa nicht so, dass jegliche Fähigkeiten erlernt wurden, einige sind mit der Geburt bereits ausgebildet oder liegen als sogenannter Instinkt vor.

Ein einzelner Machine Learning Algorithmus würde wohl kaum einen Turing-Test bestehen oder einen Roboter komplexe Aufgaben bewältigen lassen. Daher muss eine künstliche Intelligenz weit mehr können, als bestimmte Dinge zu erlernen. Zum wissenschaftlichen Gebiet der künstlichen Intelligenz gehören zumindest:

  • Machine Learning (inkl. Deep Learning und Ensemble Learning)
  • Mathematische Logik
    • Aussagenlogik
    • Prädikatenlogik
    • Default-Logik
    • Modal-Logik
  • Wissensbasierte Systeme
    • relationale Algebra
    • Graphentheorie
  • Such- und Optimierungsverfahren:
    • Gradientenverfahren
    • Breitensuche & Tiefensuche

AI(ML(DL))

Buch-Empfehlungen

Grundkurs Künstliche Intelligenz: Eine praxisorientierte Einführung (Computational Intelligence) Praxiseinstieg Deep Learning: Mit Python, Caffe, TensorFlow und Spark eigene Deep-Learning-Anwendungen erstellen
Robert Schmitz

Ständig wachsende Datenflut – Muss nun jeder zum Data Scientist werden?

/in , , , , , , , /by

Weltweit rund 163 Zettabyte – so lautet die Schätzung von IDC für die Datenmenge weltweit im Jahr 2025. Angesichts dieser kaum noch vorstellbaren Zahl ist es kein Wunder, wenn Anwender in Unternehmen sich überfordert fühlen. Denn auch hier muss vieles analysiert werden – eigene Daten aus vielen Bereichen laufen zusammen mit Daten Dritter, seien es Dienstleister, Partner oder gekaufter Content. Und all das wird noch ergänzt um Social Content – und soll dann zu sinnvollen Auswertungen zusammengeführt werden. Das ist schon für ausgesprochene Data Scientists keine leichte Aufgabe, von normalen Usern ganz zu schweigen. Doch es gibt eine gute Nachricht dabei: den Umgang mit Daten kann man lernen.

Echtes Datenverständnis – Was ist das?

Unternehmen versuchen heute, möglichst viel Kapital aus den vorhandenen Daten zu ziehen und erlauben ihren Mitarbeitern kontrollierten, aber recht weit gehenden Zugriff. Das hat denn auch etliche Vorteile, denn nur wer Zugang zu Daten hat, kann Prozesse beurteilen und effizienter gestalten. Er kann mehr Informationen zu Einsichten verwandeln, Entwicklungen an den realen Bedarf anpassen und sogar auf neue Ideen kommen. Natürlich muss der Zugriff auf Informationen gesteuert und kontrolliert sein, denn schließlich muss man nicht nur Regelwerken wie Datenschutzgrundverordnung gehorchen, man will auch nicht mit den eigenen Daten dem Wettbewerb weiterhelfen.

Aber davon abgesehen, liegt in der umfassenden Auswertung auch die Gefahr, von scheinbaren Erkenntnissen aufs Glatteis geführt zu werden. Was ist wahr, was ist Fake, was ein Trugschluss? Es braucht einige Routine um den Unsinn in den Daten erkennen zu können – und es braucht zuverlässige Datenquellen. Überlässt man dies den wenigen Spezialisten im Haus, so steigt das Risiko, dass nicht alles geprüft wird oder auf der anderen Seite Wichtiges in der Datenflut untergeht. Also brauchen auch solche Anwender ein gewisses Maß an Datenkompetenz, die nicht unbedingt Power User oder professionelle Analytiker sind. Aber in welchem Umfang? So weit, dass sie fähig sind, Nützliches von Falschem zu unterscheiden und eine zielführende Systematik auf Datenanalyse anzuwenden.

Leider aber weiß das noch nicht jeder, der mit Daten umgeht: Nur 17 Prozent von über 5.000 Berufstätigen in Europa fühlen sich der Aufgabe gewachsen – das sagt die Data-Equality-Studie von Qlik. Und für Deutschland sieht es sogar noch schlechter aus, hier sind es nur 14 Prozent, die glauben, souverän mit Daten umgehen zu können. Das ist auch nicht wirklich ein Wunder, denn gerade einmal 49 Prozent sind (in Europa) der Ansicht, ausreichenden Zugriff auf Daten zu haben – und das, obwohl 85 Prozent glauben, mit höherem Datenzugriff auch einen besseren Job machen zu können.

Mit Wissens-Hubs die ersten Schritte begleiten

Aber wie lernt man denn nun, mit Daten richtig oder wenigstens besser umzugehen? Den Datenwust mit allen Devices zu beherrschen? An der Uni offensichtlich nicht, denn in der Data-Equality-Studie sehen sich nur 10 Prozent der Absolventen kompetent im Umgang mit Daten. Bis der Gedanke der Datenkompetenz Eingang in die Lehrpläne gefunden hat, bleibt Unternehmen nur die Eigenregie  – ein „Learning by Doing“ mit Unterstützung. Wie viel dabei Eigeninitiative ist oder anders herum, wieviel Weiterbildung notwendig ist, scheint von Unternehmen zu Unternehmen unterschiedlich zu sein. Einige Ansätze haben sich jedoch schon bewährt:

  • Informationsveranstaltungen mit darauf aufbauenden internen und externen Schulungen
  • Die Etablierung von internen Wissens-Hubs: Data Scientists und Power-User, die ihr Know-how gezielt weitergeben: ein einzelne Ansprechpartner in Abteilungen, die wiederum ihren Kollegen helfen können. Dieses Schneeball-Prinzip spart viel Zeit.
  • Eine Dokumentation, die gerne auch informell wie ein Wiki oder ein Tutorial aufgebaut sein darf – mit der Möglichkeit zu kommentieren und zu verlinken. Nützlich ist auch ein Ratgeber, wie man Daten hinterfragt oder wie man Datenquellen hinter einer Grafik bewertet.
  • Management-Support und Daten-Incentives, die eine zusätzliche Motivation schaffen können. Dazu gehört auch, Freiräume zu schaffen, in denen sich Mitarbeiter mit Daten befassen können – Zeit, aber auch die Möglichkeit, mit (Test-)Daten zu spielen.

Darüber hinaus aber braucht es eine Grundhaltung, die sich im Unternehmen etablieren muss: Datenkompetenz muss zur Selbstverständlichkeit werden. Wird sie zudem noch spannend gemacht, so werden sich viele Mitarbeiter auch privat mit der Bewertung und Auswertung von Daten beschäftigen. Denn nützliches Know-how hat keine Nutzungsgrenzen – und Begeisterung steckt an.

Dario Zocholl

Lexoro Data Science Survey

/in , , , /by

Wir von lexoro möchten die Community mit informativen Beiträgen fördern und erstellen dazu regelmäßige Mini-Studien. Die aktuelle Umfrage finden Sie in diesen Artikel eingebettet (siehe unten) oder mit einem Klick auf diesen Direktlink.

Data Science…more than Python, TensorFlow & Neural Networks

Künstliche Intelligenz, Data Science, Machine Learning – das sind die Schlagwörter der Stunde. Man kann sich den Berichten und Artikeln über die technologischen Entwicklungen, Trends und die Veränderungen, die uns bevorstehen kaum entziehen. Viele sind sich einig: Wir stehen vor einem Paradigmenwechsel vorangetrieben durch einen technologischen Fortschritt, dessen Geschwindigkeit – auch wenn es vielen zu schnell geht – exponentiell zunimmt. Und auch wenn wir noch am Anfang dieses neuen Zeitalters stehen, so sind die Veränderungen jetzt schon zu spüren – in den Unternehmen, in unserem Alltag, in unserer Kommunikation…

Der Arbeitsmarkt im Speziellen sieht sich auch einem starken Veränderungsprozess unterworfen. Berufe, die noch vor nicht allzu langer Zeit als nicht durch Maschinen ersetzbar galten, sind dabei zu verschwinden oder zumindest sich zu verändern. Gleichzeitig entstehen neue Jobs, neue Rollen, neue Verantwortungsbereiche. Kaum ein Unternehmen kommt daran vorbei sich den Herausforderungen dieses technologischen Wandels zu stellen. Neue Strukturen, Abteilungen, Arbeitsmodelle und Jobs entstehen.

Doch um auf die anfangs genannten Hype-Begriffe zurückzukommen – was verbirgt sich eigentlich hinter Data Science, Machine Learning und Artificial Intelligence?! Was macht einen guten Data Scientist eigentlich aus?

Die Antwort scheint aus Sicht vieler Manager einfach: im Studium Python lernen, regelmäßig Big Data Tools von Hadoop nutzen, sich in TensorFlow einarbeiten und etwas über Neural Networks lesen – und fertig ist der Data Scientist. Doch so einfach ist es leider nicht. Oder eher zum Glück?! Neue Job-Rollen erfordern auch neue Denkweisen im Recruiting! Wir entfernen uns von einem strikten Rollen-basiertem Recruiting und fokussieren uns immer mehr auf die individuellen Kompetenzen und Stärken der einzelnen Personen. Wir sind davon überzeugt, dass die treibenden Köpfe hinter der bereits laufenden Datenrevolution deutlich facettenreicher und vielschichtiger sind als sich das so mancher vielleicht wünschen mag.

Diesem Facettenreichtum und dieser Vielschichtigkeit wollen wir auf den Grund gehen und dieser Survey soll einen Beitrag dazu leisten. Welche Kompetenzen sollte ein guter Data Scientist aus Ihrer Sicht mitbringen? In welchen Bereichen würden Sie persönlich sich gerne weiterentwickeln? Haben Sie die Möglichkeiten dazu? Sind Sie auf dem richtigen Weg sich zu einem Data Scientist oder Machine Learning Expert zu entwickeln? Oder suchen Sie nach einem ganz anderen Karriereweg?
Mit einem Zeit-Investment von nur 5 Minuten leisten Sie einen wertvollen Beitrag zur Entwicklung unseres A.I.-Skillprints, der es ermöglichen wird, eine automatische, datengestützte Analyse Ihrer A.I.-bezogenen Fähigkeiten durchzuführen und Empfehlungen für eine optimale Karriereentwicklung zu erhalten.

Vielen Dank im Voraus für Ihre Teilnahme!

Das lexoro-Team


Benjamin Aunkofer

Distributed Computing – MapReduce Algorithmus

/in , , , , , , , /by

Sollen große Datenmengen analysiert werden, ist die Hardware eines leistungsfähigen Computers schnell überfordert und die Analysezeiten werden zu lang. Die Lösung zur Bewältigung von Big Data Analytics sind Konzepte des verteilten Rechnens (Distributed Computing).

Vertikale Skalierung – Der Klassiker der leistungsstarken Datenverarbeitung

Die meisten Unternehmen setzen heute noch auf leistungsstarke und aufrüstbare Einzelserver. Sollten Datenmengen größer und Analysen rechenaufwändiger werden, werden Festplatten (Storage), Arbeitsspeicher (RAM) und Prozessoren (CPU) aufgerüstet oder der Server direkt durch einen leistungsstärkeren ersetzt.

Diese Form der sogenannten vertikalen Skalierung (Vergrößerung der Server-Komponenten) ist für viele Unternehmen heute noch gängige Praxis, auch weil sie leicht zu administrieren ist und sie mit nahezu jeder Software funktioniert. Jedoch sind der Erweiterbarkeit gewisse Grenzen gesetzt und auch der Wechsel zu noch leistungsfähigerer Hardware würde den Einsatz von neuester High-End-Hardware bedeuten, der Kostenanstieg wäre exponentiell. Ferner bedarf es einer durchdachten Backup-Strategie mit gespiegelten Festplatten oder einem ganzen Backup-Server.

Leistungsstarke Server sind teuer und können zwar große Datenmengen weitaus schneller auswerten als Consumer-Computer, jedoch sind auch sie eher nicht dazu in der Lage, Big Data zu verarbeiten, also beispielsweise 100 Terabyte Daten binnen Sekunden statistisch auszuwerten.

Horizontale Skalierung – Skalierbare Speicher-/Rechenleistung

Ein alternatives Konzept zur vertikalen Skalierung ist die horizontale Skalierung. Dabei werden mehrere Computer, die im Vergleich oftmals über nur mittelmäßige Leistungsmerkmale verfügen, über ein Computer-Netzwerk verbunden und parallel angesteuert.

Der große Vorteil der horizontalen Skalierung ist der kostengünstige Einstieg, denn praktisch könnte bereits mit einem einzelnen Computer (Node) begonnen werden und dann nach und nach mit weiteren Nodes die Leistungsfähigkeit des Clusters (Verbund von Nodes) linear gesteigert werden. Ungefähr linear wachsen auch die Kosten an, so dass diese weitaus besser planbar sind. Cluster können weitaus höhere Leistungen erreichen als es einzelne Server könnten, daher gibt die horizontale Skalierung als diejenige, die sich für Big Data Analytics eignet, denn sie ermöglicht verteiltes Rechnen (Distributed Computing). Mit einem ausreichend großen Cluster lassen sich auch 100 Terabyte und mehr in wenigen Augenblicken statistisch auswerten.

Ferner ermöglichen horizontale Lösungen integrierte Backup-Strategien, indem jeder Node des Clusters über ein Backup der Daten eines anderen Nodes verfügt. Verfügt ein Node sogar über mehrere Backups, lässt sich eine sehr hohe Ausfallsicherheit – Datenverfügbarkeit im Cluster – erzielen.

Jedoch gibt es auch Nachteile der horizontalen Skalierung: Die Administration eines Clusters ist weitaus herausfordernder als ein einzelner Server, egal wie leistungsstark dieser sein mag. Auch Bedarf es viel räumlichen Platz für einen (oder gar mehrere) Cluster. Die Kompatibilität der Nodes sollte auch für die nächsten Jahr gesichert sein und nicht zuletzt ist es eine große Hürde, dass die einzusetzende Software (Datenbank- und Analyse-Software) für den Einsatz auf Clustern geeignet sein muss. Verbreite Software-Lösungen für verteiltes Speichern und Rechnen kommen beispielsweise von der Apache Foundation als Open Source Software: Hadoop, Spark und Flink.

Map Reduce Processing

Damit verteiltes Rechnung funktioniert, bedarf es der richtigen Software, die wiederum Algorithmen einsetzt, die sich dafür eignen. Der bekannteste und immer noch am weitesten verbreitete Algorithmus ist MapReduce. MapReduce ist ein sehr einfacher Algorithmus und dürfte von der grundsätzlichen Vorgehensweise jedem Software-Entwickler oder Analyst vertraut sein. Das Prinzip entspricht dem folgenden SQL-Statement, dass die am häufigsten vorkommende Sprache aus dem Datensatz (Tabelle Customers) abfragt:

Es gibt eine Tabelle (es könnte eine Tabelle in einer relationalen Datenbank sein oder eine CSV-Datei), die durch eine SELECT-Query abgefragt (map), groupiert (combine) und sortiert (sort). Dieser Schritt kann vereinfacht als Map-Funktion betrachtet werden, die in einer Liste Paaren aus Schlüssel (Keys) und Werten (Values) resultiert. Ist diese Liste vorhanden, kann diese auf die gewünschten Ergebnisse entspechend einer Logik (z. B. max(), min(), mean(), sum()) auf wenige oder nur einen einzigen Wert reduziert werden (Reduce-Funktion). Zu beachten ist dabei, dass der Map-Prozess sehr viel speicher- und rechen-aufwändiger als der Reduce-Prozess ist. Führen wir diese Abfrage auf einer Maschine aus, fassen wir die beiden Abfragen als ein Statement aus:

Betrachten wir jedoch die einzelnen Schritte, können wir sie wieder zumindest in einen Map- und einen Reduce-Schritt unterteilen. Diese Aufteilung machen wir uns für das verteilte Rechnen zunutze: Wenn jeder Computer (Node; oft auch Client Node oder Data Node) einen Teil der Daten besitzt, kann jeder Node für sich einen Map-Prozess durchführen, die Ergebnisse dann an einen Master-Node (oder in Hadoop-Sprache: Name Node) senden, der den Reduce-Prozess durchführt. Der Großteil der Aufgabe findet somit auf dem Cluster statt, nur der simple Reduce-Schritt auf einem einzelnen Computer.

Oftmals reicht ein parallel ablaufender Map-Prozess auf dem Cluster nicht aus, um Daten effizient auswerten zu können. Die Maßgabe sollte stets sein, den Reduce-Aufwand so gering wie möglich zu halten und soviel Arbeit wie möglich auf den Cluster zu verlagern. Daher sollte jeder Node im Cluster soweit aggregieren wie möglich: Dafür gibt es den Combine-Schritt.

Die zuvor erwähnte SQL-Abfrage als MapReduce würde bedeuten, dass ein Node über den Datensatz verfügt (und andere Nodes über weitere Datensätze) und jeder Node für sich seine Daten über einen Map-Prozess herausarbeitet, über einen Combine-Prozess aggregiert und die Aggregationsergebnisse an den Master-Node (Name Node) sendet. Hat der Master-Node alle Ergebnisse erhalten, berechnet dieser daraus das Endergebnis (Reduce).

Zusammenfassung: Map Reduce

MapReduce ist der bekannteste Algorithmus zur verteilten Verarbeitung von Daten und eignet sich für die Durchführung von komplexen Datenanalysen. Liegen Datensätze auf mehreren Computern (Client Nodes) vor, läuft der Algorithmus in der Regel in drei Schritten ab:

  1. Map – Selektierung der Datensätze auf den Computern im gewünschten Format und Durchführung einer Berechnung, beispielsweise der Bildung einer Summe. Dieser Schritt ist ermöglich das Prinzip Schema on Read, das aus Hadoop ein Tool zur Verarbeitung von unstrukturierten Daten macht.
  2. Combine – Durchführung einer Aggregation, die ebenfalls auf jeden Client Node durchgeführt wird, zur Zusammenfassung von Map-Ergebnissen.
  3. Reduce – Aggregation aller Ergebnisse auf dem zentralen Rechner (Name Node)

MapReduce ist dazu geeignet, unstrukturierte Daten zu verarbeiten, denn das Format der Daten wird über einen Map-Algorithmus bestimmt, der sehr flexibel programmiert werden kann. MapReduce ist kein eng definierter Algorithmus, sondern eine Hülle, die mit Inhalt befüllt werden muss. So müssen MapReduce-Algorithmen individuell über eine Programmiersprache wie Java, Scala oder Python programmiert werden.

Ein Beispiel eines in Java programmierten Word-Count-Algorithmus nach der MapReduce-Logik in Hadoop findet sich hier:

MapReduce und Advanced Analytics

MapReduce spielt seine Vorteile auf Computer-Clustern aus und eignet sich sehr zur Analyse von Daten nach dem Schema on Read. Für kompliziertere Analysealgorithmen ist MapReduce jedoch nur bedingt geeignet, denn bereits einfache Join-Anweisungen benötigen mehrere MapReduce-Ketten.

Während statistische Auswertungen und Join-Anweisungen mit MapReduce noch gut möglich sind, werden Algorithmen des maschinellen Lernens schwierig bis kaum möglich, da diese viele Iterationen, z. B. zur Anpassung von Gewichten, benötigen.

Benjamin Aunkofer

Machine Learning: Online vs Offline

/in , , , /by

Das ist Artikel 4 von 4 aus der Artikelserie – Was ist eigentlich Machine Learning?

Die Begriffe online und offline sind mit vielen Bedeutungen versehen und so ist – wie bei vielen Unterscheidungsmöglichkeiten des maschinellen Lernens – die Verwirrung vorprogrammiert. Diese Unterscheidung betrifft die Trainingsphasen der parametrischen Verfahren des maschinellen Lernens.

Offline Learning

Mit Offline Learning ist nicht gemeint, dass der Algorithmus nicht ans Internet angebunden ist, sondern dass es sich bei der Trainingsprozedure um eine Stapelverarbeitung handelt. Daher wird manchmal auch vom Batch Learning gesprochen. Beim Batch Learning werden die Parameter bzw. das Modell erst angepasst, nachdem der gesamte Batch (Stapel an Datensätzen) das Training durchlaufen hat. Die gewöhnliche Gradientenmethode als ein Optimierungsverfahren ist das Gradientenabstiegsverfahren als Stapelverarbeitung. Dabei wird der Gradient, der die Richtung für die Anpassung der Gewichtungen der Funktionsparameter vorgibt, anhand der gesamten Trainingsdatenmenge berechnet.

Der Vorteil dieser Vorgehensweise ist, dass das Training als Prozess sehr schnell läuft und die Funktionsparameter direkt aus dem gesamten Datenbestand heraus bestimmt werden.

Demgegenüber steht der Nachteil, dass der ganze Stapel in den Arbeitsspeicher geladen werden muss, was eine entsprechend leistungsfähige Hardware voraussetzt. Soll das Lern-System für das Training live an einer Datenquelle (z. B. ein Data Stream aus dem Social Media) angebunden werden, müssen die Daten erstmal gespeichert werden (Bildung des Stapels), bevor sie verarbeitet und dann verworfen werden können, was den dafür nötigen Speicherplatz bedingt.

Online Learning

Beim Online-Learning wird nicht über einen Stapel (Batch) trainiert, sondern jeder einzelne Datensatz (aus einer großen Menge an Datensätzen oder live hinzugefügte Datensätze) wird dem Training einzeln hinzugefügt, trainiert und umgehend in eine Parameteranpassung (Modellanpassung) umgesetzt. Dies lässt sich beispielsweise mit der stochastischen Gradientenmethode realsieren, die iterativ arbeiten und den Gradienten zur Gewichtungsanpassung für jeden einzelnen Datensatz bestimmt, statt einen ganzen Batch zu verarbeiten und daraus einen Fehler zu berechnen. Online-Learning ist ein inkrementell arbeitendes Lernen, welches das Modell kontinuierlich – nämlich nach jedem Datensatz (Sample) – anpasst.

Die Optimierung läuft somit – wenn auf eine große Datenmenge angewendet wird – natürlich langsamer und ist eher nicht geeignet, wenn ein Training schnell verlaufen muss oder eine große Datenmenge die Hardware sowieso schon auslastet. Dafür wird das Modell beim Online-Learning in Echtzeit trainiert, wenn neue Daten zur Verfügung stehen. Neu hinzugefügte Daten fließen sofort ins Modell ein, so kann ein Lern-System als ein Live-System gleich auf Änderungen reagieren und die Trainingsdaten wieder verworfen werden (da sie bereits ins Training eingeflossen sind).

Mini-Batch-Verfahren

Während beim Online Learning alle Datensätze einzeln durchgegangen werden (dauert lange) und beim Offline Learning der gesamte Stapel an Datensätzen durchgearbeitet wird (viel Speicherplatzbedarf), ist der sogenannte Mini-Batch der Mittelweg. Wie der Name bereits andeutet, wird ein kleinerer Stapel (z. B. 50 Datensätze) gesammelt und verarbeitet.

Derry Holding

Applying Data Science Techniques in Python to Evaluate Ionospheric Perturbations from Earthquakes

/in , , , , , , , /by

Multi-GNSS (Galileo, GPS, and GLONASS) Vertical Total Electron Content Estimates: Applying Data Science techniques in Python to Evaluate Ionospheric Perturbations from Earthquakes

1 Introduction

Today, Global Navigation Satellite System (GNSS) observations are routinely used to study the physical processes that occur within the Earth’s upper atmosphere. Due to the experienced satellite signal propagation effects the total electron content (TEC) in the ionosphere can be estimated and the derived Global Ionosphere Maps (GIMs) provide an important contribution to monitoring space weather. While large TEC variations are mainly associated with solar activity, small ionospheric perturbations can also be induced by physical processes such as acoustic, gravity and Rayleigh waves, often generated by large earthquakes.

In this study Ionospheric perturbations caused by four earthquake events have been observed and are subsequently used as case studies in order to validate an in-house software developed using the Python programming language. The Python libraries primarily utlised are Pandas, Scikit-Learn, Matplotlib, SciPy, NumPy, Basemap, and ObsPy. A combination of Machine Learning and Data Analysis techniques have been applied. This in-house software can parse both receiver independent exchange format (RINEX) versions 2 and 3 raw data, with particular emphasis on multi-GNSS observables from GPS, GLONASS and Galileo. BDS (BeiDou) compatibility is to be added in the near future.

Several case studies focus on four recent earthquakes measuring above a moment magnitude (MW) of 7.0 and include: the 11 March 2011 MW 9.1 Tohoku, Japan, earthquake that also generated a tsunami; the 17 November 2013 MW 7.8 South Scotia Ridge Transform (SSRT), Scotia Sea earthquake; the 19 August 2016 MW 7.4 North Scotia Ridge Transform (NSRT) earthquake; and the 13 November 2016 MW 7.8 Kaikoura, New Zealand, earthquake.

Ionospheric disturbances generated by all four earthquakes have been observed by looking at the estimated vertical TEC (VTEC) and residual VTEC values. The results generated from these case studies are similar to those of published studies and validate the integrity of the in-house software.

2 Data Cleaning and Data Processing Methodology

Determining the absolute VTEC values are useful in order to understand the background ionospheric conditions when looking at the TEC perturbations, however small-scale variations in electron density are of primary interest. Quality checking processed GNSS data, applying carrier phase leveling to the measurements, and comparing the TEC perturbations with a polynomial fit creating residual plots are discussed in this section.

Time delay and phase advance observables can be measured from dual-frequency GNSS receivers to produce TEC data. Using data retrieved from the Center of Orbit Determination in Europe (CODE) site (ftp://ftp.unibe.ch/aiub/CODE), the differential code biases are subtracted from the ionospheric observables.

2.1 Determining VTEC: Thin Shell Mapping Function

The ionospheric shell height, H, used in ionosphere modeling has been open to debate for many years and typically ranges from 300 – 400 km, which corresponds to the maximum electron density within the ionosphere. The mapping function compensates for the increased path length traversed by the signal within the ionosphere. Figure 1 demonstrates the impact of varying the IPP height on the TEC values.

Figure 1 Impact on TEC values from varying IPP heights. The height of the thin shell, H, is increased in 50km increments from 300 to 500 km.

2.2 Phase Smoothing

For dual-frequency GNSS users TEC values can be retrieved with the use of dual-frequency measurements by applying calculations. Calculation of TEC for pseudorange measurements in practice produces a noisy outcome and so the relative phase delay between two carrier frequencies – which produces a more precise representation of TEC fluctuations – is preferred. To circumvent the effect of pseudorange noise on TEC data, GNSS pseudorange measurements can be smoothed by carrier phase measurements, with the use of the carrier phase smoothing technique, which is often referred to as carrier phase leveling.

Figure 2 Phase smoothed code differential delay

2.3 Residual Determination

For the purpose of this study the monitoring of small-scale variations in ionospheric electron density from the ionospheric observables are of particular interest. Longer period variations can be associated with diurnal alterations, and changes in the receiver- satellite elevation angles. In order to remove these longer period variations in the TEC time series as well as to monitor more closely the small-scale variations in ionospheric electron density, a higher-order polynomial is fitted to the TEC time series. This higher-order polynomial fit is then subtracted from the observed TEC values resulting in the residuals. The variation of TEC due to the TID perturbation are thus represented by the residuals. For this report the polynomial order applied was typically greater than 4, and was chosen to emulate the nature of the arc for that particular time series. The order number selected is dependent on the nature of arcs displayed upon calculating the VTEC values after an initial inspection of the VTEC plots.

3 Results

3.1 Tohoku Earthquake

For this particular report, the sampled data focused on what was retrieved from the IGS station, MIZU, located at Mizusawa, Japan. The MIZU site is 39N 08′ 06.61″ and 141E 07′ 58.18″. The location of the data collection site, MIZU, and the earthquake epicenter can be seen in Figure 3.

Figure 3 MIZU IGS station and Tohoku earthquake epicenter [generated using the Python library, Basemap]

Figure 4 displays the ionospheric delay in terms of vertical TEC (VTEC), in units of TECU (1 TECU = 1016 el m-2). The plot is split into two smaller subplots, the upper section displaying the ionospheric delay (VTEC) in units of TECU, the lower displaying the residuals. The vertical grey-dashed lined corresponds to the epoch of the earthquake at 05:46:23 UT (2:46:23 PM local time) on March 11 2011. In the upper section of the plot, the blue line corresponds to the absolute VTEC value calculated from the observations, in this case L1 and L2 on GPS, whereby the carrier phase leveling technique was applied to the data set. The VTEC values are mapped from the STEC values which are calculated from the LOS between MIZU and the GPS satellite PRN18 (on Figure 4 denoted G18). For this particular data set as seen in Figure 4, a polynomial fit of  five degrees was applied, which corresponds to the red-dashed line. As an alternative to polynomial fitting, band-pass filtering can be employed when TEC perturbations are desired. However for the scope of this report polynomial fitting to the time series of TEC data was the only method used. In the lower section of Figure 4 the residuals are plotted. The residuals are simply the phase smoothed delay values (the blue line) minus the polynomial fit line (the red-dashed line). All ionosphere delay plots follow the same layout pattern and all time data is represented in UT (UT = GPS – 15 leap seconds, whereby 15 leap seconds correspond to the amount of leap seconds at the time of the seismic event). The time series shown for the ionosphere delay plots are given in terms of decimal of the hour, so that the format follows hh.hh.

Figure 4 VTEC and residual plot for G18 at MIZU on March 11 2011

3.2 South Georgia Earthquake

In the South Georgia Island region located in the North Scotia Ridge Transform (NSRT) plate boundary between the South American and Scotia plates on 19 August 2016, a magnitude of 7.4 MW earthquake struck at 7:32:22 UT. This subsection analyses the data retrieved from KEPA and KRSA. As well as computing the GPS and GLONASS TEC values, four Galileo satellites (E08, E14, E26, E28) are also analysed. Figure 5 demonstrates the TEC perturbations as computed for the Galileo L1 and L5 carrier frequencies.

Figure 5 VTEC and residual plots at KRSA on 19 August 2016. The plots are from the perspective of the GNSS receiver at KRSA, for four Galileo satellites (a) E08; (b) E14; (c) E24; (d) E26. The y-axes and x-axes in all plots do not conform with one another but are adjusted to fit the data. The y-axes for the residual section of each plot is consistent with one another.

Figure 6 Geometry of the Galileo (E08, E14, E24 and E26) satellites’ projected ground track whereby the IPP is set to 300km altitude. The orange lines correspond to tectonic plate boundaries.

4 Conclusion

The proximity of the MIZU site and magnitude of the Tohoku event has provided a remarkable – albeit a poignant – opportunity to analyse the ocean-ionospheric coupling aftermath of a deep submarine seismic event. The Tohoku event has also enabled the observation of the origin and nature of the TIDs generated by both a major earthquake and tsunami in close proximity to the epicenter. Further, the Python software developed is more than capable of providing this functionality, by drawing on its mathematical packages, such as NumPy, Pandas, SciPy, and Matplotlib, as well as employing the cartographic toolkit provided from the Basemap package, and finally by utilizing the focal mechanism generation library, Obspy.

Pre-seismic cursors have been investigated in the past and strongly advocated in particular by Kosuke Heki. The topic of pre-seismic ionospheric disturbances remains somewhat controversial. A potential future study area could be the utilization of the Python program – along with algorithmic amendments – to verify the existence of this phenomenon. Such work would heavily involve the use of Scikit-Learn in order to ascertain the existence of any pre-cursors.

Finally, the code developed is still retained privately and as of yet not launched to any particular platform, such as GitHub. More detailed information on this report can be obtained here:

Download as PDF

Tag Archive for: Data Science

Nothing Found

Sorry, no posts matched your criteria