...that every Data Scientist must add in their visualisation toolkit.
TODAY'S ISSUE
Scatter plots, bar plots, line plots, box plots, and heatmaps are the most frequently used plots for data visualization.
Although they are simple and known to almost everyone, I believe they are not the right choice to cover every possible scenario.
Instead, many other plots originate from these standard plots that can be much more suitable, if used appropriately.
Therefore, today, let’s discuss a few alternatives to these popular plots.
I will also explain specific situations where they can be more useful over standard plots.
Let’s begin!
A traditional heatmap represents the values using a color scale. Yet, mapping the cell color to exact numbers is still challenging.
Embedding a size component to heatmaps can be extremely helpful in such cases.
In essence, the bigger the size, the higher the absolute value:
This is especially useful to make heatmaps cleaner, as many values nearer to zero will immediately shrink.
To visualize the change in value over time, a line (or bar) plot may not always be an apt choice.
This is because a line plot (or bar plot) depicts the actual values in the chart. Thus, it is difficult to visually estimate the scale and direction of incremental changes.
Instead, you can use a waterfall chart.
It elegantly depicts these rolling differences, as depicted below:
Here, the start and final values are represented by the first and last bars.
Also, the consecutive changes are automatically color-coded, making them easier to interpret.
When visualizing the change in rank over time of multiple categories, using a bar chart may not be appropriate.
This is because bar charts quickly become cluttered with many categories.
Instead, try Bump Charts. They are specifically used to visualize the rank of different items over time.
Comparing the bar chart and bump chart above, it is far easier to interpret the change in rank with a bump chart rather than a bar chart.
Visualizing data distributions using box plots and histograms can be misleading at times.
This is because:
Thus, to avoid misleading conclusions, it is always recommended to plot the data distribution as precisely as possible.
These include:
With Raincloud plots, you can:
Scatter plots can get too dense to interpret when you have thousands of data points.
Instead, you can replace them with Hexbin plots.
Hexbin plots bin the area of a chart into hexagonal regions. Each region is assigned a color intensity based on the method of aggregation used (the number of points, for instance).
Another choice is a density plot, which illustrates the distribution of points in a two-dimensional space.
A contour is created by connecting points of equal density. In other words, a single contour line depicts an equal density of data points.
As discussed above, bar plots quickly get messy and cluttered as the number of categories increases.
A bubble plot is often a better alternative in such cases.
They are like scatter plots but:
As depicted above:
Another alternative to bar plots in such situations is dot plots.
Both dot plots and bubble charts are based on the idea that, at times, when we have a bar plot with many bars, we’re often not paying attention to the individual bar lengths.
Instead, we mostly consider the individual endpoints that denote the total value.
These plots precisely help us depict that while also eliminating the long bars of little to no use.
One critical problem with the traditional RAG system is that questions are not semantically similar to their answers.
As a result, several irrelevant contexts get retrieved during the retrieval step due to a higher cosine similarity than the documents actually containing the answer.
HyDE solves this.
The following visual depicts how it differs from traditional RAG and HyDE.
We covered this in detail in a newsletter issue published last week →
Versioning GBs of datasets is practically impossible with GitHub because it imposes an upper limit on the file size we can push to its remote repositories.
That is why Git is best suited for versioning codebase, which is primarily composed of lightweight files.
However, ML projects are not solely driven by code.
Instead, they also involve large data files, and across experiments, these datasets can vastly vary.
To ensure proper reproducibility and experiment traceability, it is also necessary to version datasets.
Data version control (DVC) solves this problem.
The core idea is to integrate another version controlling system with Git, specifically used for large files.
Here's everything you need to know (with implementation) about building 100% reproducible ML projects →