Impressions and Links from
Crunch 2019

Data Conference.
October 16-18, 2019. Budapest, Hungary.


Railway Museum, Budapest


I had the great pleasure of taking part in Crunch 2019
in Budapest, Hungary

(Data Conference. October 16-18, 2019).

Below you will find impressions from the conference, and links for further reading.





The Crunch conference was held in Budapest (Hungary), inside the Hungarian Railway Museum park.
Railway Museum, Budapest



Tried to follow as many talks as possible. But, well, these notes are, of course, in no way, shape or form complete...
Rather, these notes were written on conference nights, as my way of keeping track of the events that I attended at the conference. And as a way of storing links and references for future reference.

But enough disclaimers, below, you'll find impressions and links from some of the conference talks and seminars, including links for further reading.

Great stuff indeed.


Disclaimer


1. Introduction.

1.1. Page Overview.
- Presentations, Keynotes and Workshops.

Below, in section (2 - 4), you will find impressions and links from the Workshop, Wednesday, and the presentations that I followed Thursday & Friday.
Misc. (post conference) impressions from Budapest can be found in section (5).

Please notice: These notes don't do justice to the often brilliant presentations that initiated them!
So, please read the original presentations to avoid any distortions ...

2. Impressions from Wednesday.
October 16th.

2.1. Hands on Deep Learning with Keras, TensorFlow, and Apache Spark (Official Databricks Workshop).


Budapest Map. My roaming October 16th. The Ericcsson House is in the southern part of the city.


The conference workshops took place in the Ericsson House (Magyar tudósok körútja 11), in the southern end of Budapest, on the Buda side of the river (the side with the hills, opposite the Parliament building).

Ericsson House, Crunch Workshop


Ericsson House, Budapest.

The workshop offered a thorough, hands-on overview of ''deep learning and its integration with Apache Spark''.
The workshop material was taught to us by the friendly and accomplished Zoltan C. Toth.


All in all, the workshop took us through a) Building a neural network with Keras. b) With misc. activation functions and optimizers. c) Tracking experiments with MLflow. d) Building Deep Learning Pipelines. e) Building distributed models with Horovod.

And - what a great day it turned out to be!
First, we started with some Spark Application Setup basics.

Helping us to get started with drivers & executors.
The Driver (aka an application’s driver process) is responsible for converting a user application into smaller execution units called tasks and then schedule them to run on the executors.
Apache Spark Workshop

In order to ease us into using Databricks and Spark, we first worked on setting up a simple linear regression model (Working on Sklearns ''California housing data''):
 
             
             # Setting up a simple linear regression model, for the
             # California housing problem, in sklearn:

from sklearn.datasets.california_housing import fetch_california_housing
from sklearn.model_selection import train_test_split
import warnings
warnings.filterwarnings("ignore")
import numpy as np
np.random.seed(0)
cal_housing = fetch_california_housing()

# split 80/20 train-test
X_train, X_test, y_train, y_test = train_test_split(cal_housing.data,
                                                        cal_housing.target,
                                                        test_size=0.2,
                                                        random_state=1)
             
             
Which was followed by training (of the linear regression model), and using the model to make predictions.

And, it was only then... that we moved forward to more sophisticated Deep Learning Models.



Here, a Keras neural network model.
Ericsson House Crunch Workshop

 
             
from tensorflow.keras.layers import Dense
from tensorflow.keras.models import Sequential
import tensorflow as tf
tf.set_random_seed(42) # For reproducibility
tf.logging.set_verbosity(tf.logging.ERROR)
np.random.seed(42)

model = Sequential()

# Input layer
model.add(Dense(20, input_dim=8, activation='relu')) 

# Automatically infers the input_dim based on the layer before it
model.add(Dense(20, activation='relu')) 

# Output layer
model.add(Dense(1, activation='linear'))
             
             
Including setting up a loss function in Keras.
Followed by the next steps in the pipeline: ''Compile network'', setting the right optimizer (here: Adam) & ''Fitting the network'':
 
             
from tensorflow.keras import metrics
from tensorflow.keras import losses

loss = "mse" # Or loss = losses.mse
metrics = ["mae", "mse"] # Or metrics = [metrics.mae, metrics.mse]

model.compile(optimizer="sgd", loss=loss, metrics=metrics)
model.fit(X_train, y_train, epochs=10)


Works better with Adam optimizer:

from tensorflow.keras import optimizers

model = build_model()
optimizer = optimizers.Adam(lr=0.001)

model.compile(optimizer=optimizer, loss=loss, metrics=metrics)
history = model.fit(X_train, y_train, epochs=20)
              
             
Throughout the day we tried out different (neural net) models.
Which obviously immediately landed us in the problem: ''Which combination of parameters actually worked best?''.
Not necessarily so easy to remember after a long days work...

MLflow to the rescue...!




A neural network model written in Keras' high-level API for building and training deep learning models (with TensorFlow).

Mlflow. An open source platform for the machine learning lifecycle
MLflow seeks to address three core issues:
- Its difficult to keep track of experiments.
- Its difficult to reproduce code.
- There’s no standard way to package and deploy models.

Experimentation pretty quickly confirmed that MLflow was indeed a very clever way of keeping track of the various setups we had gone through...

Ericsson House Crunch Workshop

Next, we played around with a Convolutional Neural Net Model (VGG16).

More precisely, we used the VGG16 pre-trained Convolutional Neural Network (trained on an image dataset from Image-Net) & Lime to see which parts of an image that contributes most to the label (the neural net assigns it to).

Interestingly, and weirdly, it turns out (Lime tells us) that the systems internal model uses part of the grass to determine that it is looking at a dog...

And that was where this super interesting workshop ended.

A super awesome day. And time to say goodbye to our inspiring & knowledgeable teacher Zoltan!

Ericsson House, Budapest. Apache Spark Workshop




Canteen, Ericsson House. Budapest. Ericsson House, Budapest. Crunch Workshop

Workshop, Ericsson House, October 16th.
Hands on Deep Learning with Keras, TensorFlow, and Apache Spark Databricks.
Ericsson House, Budapest. Apache Spark Workshop. Browser shows www.simonlaub.net

2.2. Misc. workshop related references.


Tools:
- Apache Spark.
- MLflow.

Image-Net:
- Image-Net Challenge.
- Image Kernels.
Data Visualization:
- Setosa.

Neural Net Models:
- VGG16 model for Keras.



Simon Laub - Teaching AI, Economics-IT, March 2019
All in all, interesting, and certainly something to consider for future classes in Deep Learning...

Berlin 2019 - Rise of AI conference

3. Impressions from Thursday. October 17th.


My roaming October 17th. The Crunch Venue (Railway Museum) is in the northern part of the city. On the Pest side.

My roaming in Budapest, October 17th, 2019.

The venue for the Crunch Conference was the Hungarian Railway Museum, in the northern part of the city.

On the Pest side of the river Danube.

3.1. Beyond Interactive: Empowering Everyone with Jupyter Notebooks.

Michelle Ufford (Founder of Noteables.io) talked about ''Beyond Interactive: Empowering Everyone with Jupyter Notebooks''.

Drawing from her experience at Netflix, the talk gave us a number of great insights on what ''Notebook Innovation'' (see Beyond Interactive) is all about:
Notebooks have rapidly grown in popularity among data scientists to become the de facto standard for quick prototyping and exploratory analysis.
According to Ufford:
Data powers Netflix. It permeates our thoughts, informs our decisions, and challenges our assumptions. It fuels experimentation and innovation at unprecedented scale.
Indeed, Netflix is clearly a BigData place...

Crunch 2019

Netflix started back in 1997, and is now responsible for about 15 % of all internet traffic (30 % of all internet traffic in the US).
At Netflix, they must handle 3 trillion (10^12) daily user events involving 12 petabytes of data [1].


Netflix spent $12 billions on content in 2018. Analysts expect that to grow to $15 Billion this year [2].
All Netflix users are unique, and are given different suggestions, including setting up different images for the same products, based on recorded ''events'' for the user.

Crunch 2019


If a user likes science fiction (based on viewing history), such movies will be recommended to the user. A product that contains elements of what the user likes, will be given an image that emphasize what the user likes.
According to Ufford, Netflix don't use the events to tell filmmakers how to make content (yet...?). But all of the events are made available to filmakers, who can then make their own conclusions...

Drowning in data? Well, apparently, all datascientists working for Netflix have access to all the data. Quite a data lake, and quite a headache (as illustrated in the picture above...).

So: Jupyter Notebooks to the rescue! As Ufford explained in this talk, you (data scientist) can then not only make small experiments, but it is also possible to make interactive documentation along the way.
Neat indeed! And a super interesting talk!

Colin Angle, iRobot

3.2. Toward Human-Centered Machine Learning.

Patrick Hall (Senior Director of Product at H2O.ai) talked about ''Toward Human-Centered Machine Learning''.

Clearly: If an autonomous vehicle crashes into a McDonnalds. It isn't super useful if we only know that the vehicle was controlled by a black box model that we can't access...

Crunch 2019
We need to know a little about what is going on inside the model...

Consider models used for giving loans:
I.e. if a bank has a logistic regression model for giving loans (''your credit history is not long enough'', ''debt vs. income is too high'' etc.), it is pretty easy to explain to the customer what is going on.

With neural net models it might not be so easy to explain what is going on though...
Not good, as we still need some ''post hoc'' explanations in most business cases!

So, Hall suggested that we should take a closer look a things like Lime and Shap.
The output of LIME is a list of explanations, reflecting the contribution of each feature to the prediction of a data sample.
Lime: Importance of each feature. Lime. The importance of each feature.

Lime (local interpretable model-agnostic explanation) helps users by explaining what a machine learning classifier (or model) is doing. See ''Why Should I Trust You?'' (Explaining the Predictions of Any Classifier).

We don't want AI models out there that we not understand, and therefore don't really trust...
Good AI models should indeed be explainable, fair, trustable, and accurate.

Remember Amazons ''AI recruiter'' ?
Apparently:
The company’s experimental hiring tool used artificial intelligence to give job candidates scores ranging from one to five stars — much like shoppers rate products on Amazon...
Sounded awesome, here you would :
Literally have an engine that you could give 100 resumes, and it would spit out the top five, which Amazon would then hire.
But, but... human recruiters would never trust a resume alone. And when you screen resumes, it makes sense to give unusual candidates a chance. Diversity of backgrounds and different point of views is valuable in a team.

Not exactly so, with this hiring tool...
By 2015, the company realized the system was not rating candidates for software developer jobs and other technical posts in a gender-neutral way...

Apparently, the systems models were trained to vet resumes based on resumes submitted to the company over a 10-year period. And, as most of these resumes came from men (this being the tech industry), the system had taught itself that male candidates were preferable. And that female resumes should be penalized.

Not good. And certainly unlawful, as US law states that any business model (for dealing with customers) is not allowed to treat any group of people more than 20 % different than any other group...

And it doesn't stop there. AI is apparently also sending people to jail, and getting it wrong...
1 in 38 adult Americans (2.2 million) is under some form of correctional supervision.

Under immense pressure to reduce prison numbers without risking a rise in crime, courtrooms across the US have turned to automated tools in attempts to shuffle defendants through the legal system as efficiently and safely as possible.
Police departments use predictive algorithms to strategize about where to send their ranks.
But the most controversial tool by far comes after police have made an arrest.
Say hello to criminal risk assessment algorithms!

You may have already spotted the problem. Modern-day risk assessment tools are often driven by algorithms trained on historical crime data. As a result, the algorithm could amplify and perpetuate embedded biases and generate even more bias-tainted data to feed a vicious cycle [3].
Again: Not good, and certainly not good, if the tool itself is a ''blackbox'' technology, where you can't ask the model how it came to its conclusion...

Indeed, Explainable AI, where results can be understood by human experts, gives a much higher level of trust.
Super important, if we really want humans to accept algorithmic prescriptions...

3.3. Stories beat Statistics: Master the Art & Science of Data Storytelling.

Brent Dykes (Senior Director of Data Strategy at Domo) talked about ''Stories beat Statistics: Master the Art & Science of Data Storytelling''.

At Domo they want us to:
Tell a story with data
(Curated dashboards help guide data analysis, so your data can tell the story you want it to tell).
Or, at the very least, share our data stories more effectively.

According to Dykes, stories is something we need as humans.
Just as we need shelter and nourishment in order to survive.
People hear statistics, but they feel stories.
Stories are memorable:
Jennifer Aaker, a marketing professor at Stanford’s Graduate School of Business, had each of her students give a 1-minute pitch.
Only one in 10 students used a story within his or her pitch, while the others stuck to more traditional pitch elements, such as facts and figures. The professor then asked the class to write down everything they remembered about each pitch:
5 percent of students cited a statistic, but a whopping 63 percent remembered the story [4].
Rather cleverly, Dykes reminded us that, some, people seem to think that crafting a story around their data seem like an unnecessary, time-consuming effort.
They think that insights and/or facts should be enough.
But, unfortunately, this point of view is based on the flawed assumption that business decisions are based solely on logic and reason.
In fact, neuroscientists have confirmed that decisions are often based on emotion, not logic.
E.g. Antonio Damasio has described patients, who had brain damage in an area that helped to process emotions (prefrontal cortex), that struggled to make (even) basic decisions when choosing between alternatives.
Apparently, their basic decision-making skills were significantly impaired by the lack of emotional judgment [5].
See also Review: ''The Feeling of What Happens'' (d).
In his book Effective Data Storytelling, he drives home the message:
Stories can influence decisions and drive change. Most other books focus only on data visualization, while neglecting the powerful narrative and psychological aspects of telling stories with data.
Here it is shown how the three central elements of data storytelling ―data, narrative, and visuals - can be used for maximum effectiveness
(For more, see Twitter, userprofile AnalyticsHero).
Still, the stories have to based on (our) data. After all, a non-fact based story is basicly a forgery.

All things considered, presenting the story (based on the data) is the all important step.
Here Dykes recommended that we took a look at Gustav Freytags model for a drama:

Freytag. Dramatic structure.


- Exposition (originally called introduction).
- Rising action (rise).
- Climax.
- Falling action (return or fall).
- Catastrophe, denouement, resolution, or revelation.

We should taylor the story to our audience.
Then we should build specific expectations. Before moving on to the rest of the drama (data).

E.g. (now) everyone knows that medics should wash their hands before operations. Why, probably because we know that Ignaz Semmelweis realised that disease was being carried on the hands of medical students to women in labour.

In short: It is a story, not statistics alone, that tell us why medics need to wash their hands...

Crunch 2019

Indeed, it is the data stories out there that help us understand the data...
Just think about Hans Rosling, and his gift for presenting data
(See Roslings presentations on e.g. TED or Youtube...).

As Dykes (AnalyticsHero) writes on Twitter:
You will be the same person in five years as you are today, except for the people you meet and the books you read.
Certainly, this Crunch presentation was a beautiful story.

3.4. Journey of metadata at LinkedIn.

Shirshanka Das (Principal Staff Software Engineer, Analytics Platforms and Applications at Linkedin) talked about ''Journey of metadata at LinkedIn''.

Shirshanka is the architect for LinkedIn’s Data Analytics Infrastructure team. He was among the original authors of a variety of open and closed source projects built at LinkedIn, including Databus, Espresso, and Apache Helix. His current focus at LinkedIn includes all things Hadoop, high-performance distributed OLAP engines, large-scale data... [6].
At Linkedin the mission is to map the ''human graph'' (people, jobs, schools, companies) into the digital world. A huge task!

Linkedin have some 645 million members (2019). Which in itself creates an enormous data lake, but things gets even more complex when you are also interested in keeping track of things like ''someone looked at the profile of so and so'' etc.
I.e. Linkedin have 2 M / Day CRUD operations & 3 M / Day relationship events.

So, surely, in these brave new worlds of BigData, it takes a lot of very clever engineering to make such a huge operation work, - deal with the actual complexities of these massive amounts of data & create value for everyone.

And, obviously, very interesting to hear about Linkedin strategies for being successful in this ''game''.
Shirshanka Das' actual presentation can be seen here.




Tom Chatfield - Writer, broadcaster and tech philosopher

3.5. From Zero to Hero with Kafka Connect.

Robin Moffatt (Developer Advocate at Confluent) talked about ''From Zero to Hero with Kafka Connect''.

Apache Kafka allows users to subscribe and publish data to any number of systems or real-time applications. E.g. it is used for managing passenger and driver matching at Uber. At LinkedIn it is used for providing real-time analytics and numerous real-time services across the LinkedIn backend. Etc. For more, see here.
Apache Kafka

Or. see e.g. Tim Berglund's (Senior Director of Developer Experience at Confluent) introduction to''Apache Kafka'' here.

In the world of databases, we usually talk about things, where we would have one (monolithic) program that would talk to one database. Instead, we are here talking about events, written in logs (where a topic is an ordered collection of events).

The Confluent Event Streaming Platform then builds on Apache Kafka and allow users to easily stream data from (popular formats) data sources and into data sinks.
Taking care of problems with getting data around, from Kafka, to Kafka, scalability, fault tolerance, re-starts etc.

Certainly, given massive amounts of data, it makes sense that the days of monolithic databases (and programs) must be over. Which moves us into other architectures. Probably architectures where swarms of programs can produce and consume events (from each other).
Fascinating stuff indeed!

See the actual presentation here.


Still, truly, truly modelling & making sense of (and understanding) what is going on out there in our super complex real world.... Well, well that is still something else, entirely :)

See the ASSC 23 link here...

ASSC 23. Consciousness - 2019

4. Impressions from Friday, October 18th.


Crunch 2019

Crunch 2019

4.1. Clear and Presentation Danger.

Andy Cotgreave (Technical Evangelist at Tableau Software) talked about ''Clear and Presentation Danger''.

Cotgreave started his presentation by saying that communication is a key part of being a datascientist.
It is simply no good to present data, where no-one understands what the colors, sizes or axis (in the presentation) means.

(Bad) presentation where noone understands colors, sizes or axis. Crunch 2019

So, things like colors, sizes and axis' must be easily understood.

After that, how complex can charts be?
Well, here Cotgreave offered the rule:
A chart must be understandable in under half the time it is on the screen.
Which is tricky, as it is likely that ''Your boss has a big ego, so he is running late by 15 minutes. Meaning that you only have 5 minutes for your entire presentation''. So, better keep it (your presentation) relatively simple.

Many have analyzed ''Minard's Visualization Of Napoleon's 1812 march'', see e.g. Joanne Changs blog.
Here, Cotgreave thought that we should quickly come to the conclusion that Minards visualization is too complex for most purposes... !
A lot simpler chart that tell us something about the number of dead and wounded, shown with intuitive graphics, is better (in almost all presentations)...

Minard's Visualization Of Napoleon's 1812 march
Minard's Visualization of Napoleon's 1812 march.

A much simpler presentation of vital 1812 statistics. Crunch 2019
A much simpler presentation of vital
1812 statistics.

Being able to ''Explain the Data'' is a vital skill. And much more so in the coming years.

And, certainly, a great talk about the importance of giving great presentations (with great slides, that everyone can actually see and understand).

Watch Cotgreaves presentation here.

4.2. Using adversarial samples to robustify your Neural Network Models.

Irina Vidal Migallón (Technical Lead - AI & Computer Vision at Siemens Mobility GmbH) talked about ''Using adversarial samples to robustify your Neural Network Models''.

Crunch 2019

From self-driving cars to smart surveillance cams, society is slowly learning to trust AI over human eyes. But although our new machine vision systems are tireless and ever-vigilant, they’re far from infallible.
Googles AI thinks this turtle looks like a riffle

Google's AI classify this 3D printed turtle as a riffle, which obviously gives you food for thought. Especially, when you are told that very similar systems are used in self-driving cars...

It gets even better in Simen Thys, Wiebe Van Ranst and Toon Goedeme's article ''Fooling Automated Surveillance Cameras: Adversarial Patches to Attack Person Detection''.
By making only subtle changes to the input of a convolutional neural network, the output of the network can be swayed to output a completely different result. The first attacks did this by changing pixel values of an input image slightly to fool a classifier to output the wrong class.
Adversarial patches to attack person detection
Adversarial patches to attack person detection

An adversarial patch that is successfully able to hide persons from a person detector [7].
Adversarial patches to attack person detection


If you print off one of the students specially designed patches and hang it around your neck, from the AIs (YOLOv2) point of view, you may as well have slipped under an invisibility cloak [8].

Certainly, these examples should be more than enough to convince us that these image classifiers aren't perfect.

Perhaps we could then (again) use Lime and Shap to understand what features the classifiers are actually using (Features that must be different from those a human would use).
This information could then be used to retrain the system, and hopefully get it right in the next tests.

Watch the full presentation here.

4.3. Recreating the State of the Player.

Wesley Kerr (Principal Data Scientist at Riot Games) talked about ''Recreating the State of the Player''.

Crunch 2019


Crunch 2019

Riot games have 8 million peak current daily users [9] (Over 100 million gamers play every month [10]).

At Riot games they need to build ML models that are capable of providing personalized in-game offers to their 67M+ monthly gamers. They are dealing with 500M+ datapoints per day. And they have so far collected 26 petabytes about how players interact with the game and their website [11] (Everyday they have to deal with petabytes of streaming network data across 200,000+ cities).

All of this data is used to improve the player experience through projects like ''game balance'' and ''bot detection''.
According to Kerr, they don't worry that much about churn.
But they do want to be able to predict when a player is likely to come back (after leaving the game).

They know that:
No-one likes losing. If a gamers survival rate has dropped below average for a comparable group, the gamer is likely to churn.
- Climbing the ladder of success is always appealing to players. Playing the same online-game as your friends is good. Having spent a lot of time in a game makes it more likely that a player will continue to play the game etc. -
They use things like Kaplan Meier Estimator (to estimate survival function). That is, to understand what ''fraction of players will return after having left the game''.
What is the current hazard rate (The likelihood that an item, gamer, will survive to a certain point in time based on its survival to an earlier time) for the given player?

Which could then be used to find the right interventions? What AI-bots to send into the game to improve player experience. How to match gamers etc.

Indeed, interesting stuff.

Crunch 2019



Crunch 2019, relaxation:
Crunch 2019

4.4. How News Feed Ranking Works.

Ákos Láda (Data Science Manager at Facebook) talked about ''How News Feed ranking works''.

Crunch 2019

Everything you see on Facebook depends on what you have previously seen.
But deciding what a person should see next in his or her NewsFeed is obviously a hard problem. Indeed, personalization is a hard problem.
And, according to Láda, it is ok to make ''experiments'' along the way, to see if a given models predictions are right.

At Facebook, the basic idea is that a users ''meaningful interactions''
(likes, comments) tell us what a user is interested in.
At a given time, then for each of the 2 billion users, there are about 1000 candidate posts that must be given a score. What will the user be most interested in, what has happened since last login etc.

- It also has to be decided, if some of the posts are coming from bad actors, that are trying to deceive other users.
(Btw. should it be left to users to decide whether a story is fake news?).
- Should clickbaits be ranked in the same way as quality stories?
- What about information bubbles? Should the algorithm try to break users free of their bubbles, or not?

Interesting stuff indeed, where the presentation made it clear that it probably isn't so easy to come up with the right, perfect fits all solution...
Indeed, one heck of problem Zuck & co. have here...

4.5. The Paradise Papers: Behind the Scenes with the ICIJ.

Pierre Romera (Chief Technology Officer at ICIJ) talked about ''The Paradise Papers: Behind the Scenes with the ICIJ''.

Because of the Panama Papers, [12], ''More than $1.2 billion in back-taxes and penalties has been publicly collected by governments around the world after the 2016 investigation''.
In the Paradise Papers, [13] more follows. Here we have yet another ''journalistic exposé of the offshore financial industry, that has now triggered tax-related investigations by governments around the world''.

With massive amounts of data to read through, getting the facts out in the open is difficult through
(Here, some 2.6 TB in the ''Panama Papers'', and some 1.4 TB in the ''Paradise Papers'').
I.e. if there are 13.4 million files, and it takes a minute to read a file, then it will take app. 26 years to read through the whole thing.
Using 390 journalists will then obviously get things done quicker, but it will also create a lot of new security risks (390...). In an environment where a lot of people have very good reasons to try to stop the work...

Indeed, working with sensitive data is never easy. And a very interesting case story that we were shown here.
Take a look at Romera's full presentation here.

GrayScott, Futurist
Could AI have helped out more with this kind of crime fighting..? Well, perhaps, but there is still a long way to go here...


DeepLearn 2019
For more about DeepLearning 2019, follow the DeepLearn 2019 link here...

4.6. Misc. Crunch Impressions, Friday Afternoon.


Crunch 2019
EPAM, Engineering the Future, was a Gold+ sponsor for the conference.


Crunch 2019 Many very cool technologies where demo'ed at the conference. Here a YOLOv2-like image detection system.

Hungarian Railway Museum. Crunch 2019 Impressions from the conference venue, the Hungarian Railway Museum.

Hungarian Railway Museum. Crunch 2019

Crunch 2019. The End.
Crunch 2019. The End.

Crunch goodie-bag. Crunch 2019 Crunch 2019. The End.

Railway Park Budapest Friday Afternoon. Conference Fun in the Railway Park.


Railway Park Budapest


In the end, it is, of course, humans, that need to understand what all the data (out there) is all about...

See e.g. CogSci 2013, for more about how humans process data...

For impressions from CogSci 2013 in Berlin, see my CogSci 2013 page

5. Conclusion.

5.1. RyanAir.

Flew with RyanAir from Billund (DK) to Budapest. Completely trouble-free (I.e. no horror-stories [14], [15] on this flight...).

Budapest Airport

Hungary

Budapest Donau

5.2. Crunch Venue: The Hungarian Railway Museum.

The Hungarian Railway Museum has a fleet of more than 100 beautiful old steam locomotives. They even have a restored dinning car from the Orient Expres. So, sure, the museum is in itself, well worth a visit.

Budapest Railway Park Museum

Budapest Railway Park Museum

Budapest Railway Park Museum

Budapest Railway Park Museum

5.3. Budapest Pictures.


Budapest Trams in Budapest.

Budapest Budapest, grandeur on the Danube.

St. Stephens Basilica Budapest
St. Stephen's Basilica, Budapest.
With the inscription across the entrance:
''Ego sum via veritas et vita'' (I am the way, the truth, and the life).

St. Stephens Basilica Budapest
Inside St. Stephen's Basilica, Budapest.

Váci utca. Budapest
Váci utca, Budapest. Restaurant Cyrano.

Hungarian Parliament Building, Budapest
Hungarian Parliament Building.

The Hungarian Parliament Building is the seat of the National Assembly of Hungary and a popular tourist destination in Budapest.
It is situated on the Pest side of the city, and on the banks of the river Danube.

Budapest.
Hungarian Parliament Building.

Budapest. Photo: Simon Laub, October 2019.
Hungarian Parliament Building & The Danube.

Budapesti metró
Budapesti metró.

Dohány utcai zsinagóga. Budapest
Dohány utcai zsinagóga. Budapest.

Dohány utcai zsinagóga. Budapest
Dohány utcai zsinagóga. Budapest.

Széchenyi Chain Bridge. Budapest The Széchenyi Chain Bridge opened in 1849.
The lions at each of the abutments were carved in stone by the sculptor János Marschalkó.

Budapest Sofitel Budapest Chain Bridge.

The Grandeur of Budapest
The Grandeur of Budapest.

St. Stephens Basilica. Budapest
Square in front of St. Stephens Basilica. Budapest.

St. Stephens Basilica. Budapest
Square in front of St. Stephens Basilica. Budapest.


Indeed, the end of a wunderbar conference.
With many memorable talks. Already looking forward to Crunch 2020!


Budapest, October, 2019.


Conference Venue.
Hungarian Railway Museum. Magyar Vasuttorteneti Park.
Budapest, Hungary.



Time to pack up & say goodbye.
And, perhaps, meet again next year..?

The end of great conference !