another nice one is Inverse Hyperbolic Sine scale, which can reach 0 and plot negative values, whereas log scales cannot. imo it's nicer than a cube root scale, too.
Wow. This is the first time in hearing about the inverse hyperbolic sine scale. I wonder if it's lesser known simply because many kinds of real-world underlying data that needs logarithmic scales simply don't have zeroes or negative values? For example we might be plotting some data that actually comes from an underlying exponential distribution?
i think sometimes it's called symlog, though i'm not sure if that's just a convenient re-naming of arcsinh. i don't see how any kind of "log" scale can do <= 0.
you can always y-flip the result of log(abs(value)) and show neg ticks on the axis, but it will not be a nicely-continuous, single scale that can cross 0.
Symlog is symmetric log. It's not arcsinh, instead it's a normal logarithmic scale, that turns into a linear scale around zero (for example in the range [-1,1]) and then it turns into a negative logarithm on the other side of zero. So similar but slightly different.
how does this actually work? afaik, there is no log() fn that you can run which "becomes linear". i guess you can wrap a call to log() in another fn that simply does linear scaling below the defined threshold, but it's not a smooth transition without a bunch of extra [possibly slow] smoothing code.
what you're describing is exactly how a straight call to Math.asinh() behaves, and what i have implemented in the above demo.
Theres no smoothing involved, it's three distinct domains with different function definitions. Top part is log(x) from [a,\infty), bottom part is -log(-x) from (-\infty,-a] and the middle part is cx from (-a,a). With c chosen to ensure continuity in the transform.
In the example from matplotlib I linked in the earlier comment they call out that the symlog transform has a discontinous gradient at the a's, and that the asinh transform can be used instead if that's a problem.
Edit: On reflection it's probably not entirely correct to talk about it as choosing an appropriate c. Since that transform seems to kinda break apart around a=1. Simpler to consider it a matter of plotting on a logarithmic scale down to some value. Then continuing the plot on a linear scale until you reach the negative value on the other side and then plotting on a negative logarithmic scale (-log(|x|)).
As the other commenter pointed out, symlog is not smooth. But the point about symlog is that it is very simple, has the familiar and intuitive log scaling, and most importantly that you can select the point where it transitions to linear such that it is below the smallest scale you care about.
All in all, for scientists the symlog is much more useful.
It's also harder to interpret. What the heck does `log(x + sqrt(x^2 + 1))` mean?
It's a great transformation for data viz or machine learning / statistical modeling, but its not really obvious what an IHS-transformed variable represents.
> It's also harder to interpret. What the heck does `log(x + sqrt(x^2 + 1))` mean?
once you see the shape plotted, i dont think it's much harder than understanding the shape of logistic functions, which have similar formulations, and are used all over the place in ai/ml for activation, etc.
It's not hard to see that it's sigmoidal, sure. But both the logistic function and the logarithm itself have a lot of nice mathematical properties that are useful for qualitatively interpretation. I'm not aware of equivalent nice properties for the inverse hyperbolic sine, other than those that arise from it being a logarithm of something, but it's not a logarithm of anything particularly meaningful.
I like the asinh scale, I’ve come across it before as “signed pseudolog scale” - your name for it is nice and descriptive, do you have a writeup about it somewhere?
This is brilliant. I used a logarithmic cosine scale in college physics for the degradation of a Cavindish balence. It won me both a guest lecture and an easy A.
There are even wilder triple hyperbolic scales on three dimensions.
Very natural also in money/investing applications. Passing to log scale asset prices follow random walks in several finance applications and behave much better in this scale. Options price formulas by rote memory are a bit of a mess because one does a log-calculate-exp kind of thing that distorts the streamlined rationale of the inner simpler calculations. Geometric means (used in CAGR, compound aggregate growth rates, for yearly returns) become just means (=arithmetic means) in log scale.
Agreed. Any stock app that doesn't plot stock prices in log scale is considered by me to be an amateur app. My favorite litmus test for stock apps is to view the ten-year price history for UVXY. If it doesn't look roughly like a straight line the app is for amateurs. The iOS built in stock app fails this test. The Schwab app passes this test.
I've heard of people who have basically converted all their financial or investment spreadsheets to use log scale, but I've never seen an example or a demo.
It doesn't really matter what log base you use, visually speaking. All log bases are just multiplicative differences from one another: it's like asking whether it matters if you plot height using feet or meters. It just affects where your ticks go.
yep, this was a fun aspect i discovered when doing the implementation as well. the log base just affects the tick/grid selection and where you might want to "nicely" snap the min and max to.
I tried to create a logarithmic widget for the web for anyone to grab. I like logarithmic interfaces — think there are probably a lot of uses for them.
I don't exactly know what I am doing when I venture into Javascript and web stuff but here you go:
As a developer I rarely find the need for log scale, but I was recently analyzing performance data, specifically finding patterns where one operation deviated from the normal.
For example, if an operation usually takes around 20ms, I would want to know if that operation suddenly took 200ms (a factor of 10). But I wouldn't be interested in small deviations; 40ms, even if it's twice the original number, is this within the natural variance seen due to varying levels of load and so on. Conversely, if an operation normally takes 5,000ms, if it took 10s that would actually be terrible, and I really want to know if it exceeded, say, 6,000ms. In other words, the acceptable deviation is dependent on the scale of the original number.
So I ended up choosing a hand-tuned logarithmic function which multiplies the average with a constant divided by the logarithm of the average, the output being the upper bounds on how much deviation from the average we can tolerate. So the larger the number, the lower the tolerance in absolute (linear terms).
The note at the end about different log bases was confused and borderline nonsensical.
It doesn’t matter what the log base is.
0 on the scale will correspond to 1, and 1 will correspond to the base. The shape of the curves will be identical regardless of what you choose as a base, only the labels on the scale will change and generally what you really care about with a log scale is less the values that come out than the shape of the curve.
The graph named “non-linear growth”, is actually showing linear growth. I know, it’s confusing, but as long as the factor is constant (10), growth is linear.
A quick way to check if something grows linearly is to put it on a log-scale and to see whether it’s a straight line.
Nice explanation, though. We should talk about logs more often.
I think you and the author are using terminology differently. That graph is absolutely a logarithmic axis to me. The five ticks on the axis are equidistant but each represents a number 10x of the previous. That's nonlinear to me. My definition of linear growth is that it is bounded above by a linear function. Its first derivative would therefore be bounded above by a constant.
If something is a straight line when you plot it in log scale, you are plotting exponential growth.
Good point. Also "linear convergence" means the residual reduces "linearly", or |r_{k+1}| = \lambda |r_k| with \lambda \in (0, 1). So it is somehow exponentially converging, and an algorithm with linear convergence is neat and fast.
No one will see this because I'm shadowbanned but I've always been confused about exponential vs logarithmic. In the authors example about the ruler i'd have thought this was an example of exponential scale in play.
> Notice how we're not using the ruler for measuring anymore. Instead, we're using it to represent the sizes of different objects.
Viewed like this, the fact that it uses inches vs m isn't significant, because 'inches' translates as 'units'. Even as a Brit, I can't imagine 1000 inches either, but I can tell something about two objects that are respectively 1000 vs 1200 inches/units.
https://leeoniya.github.io/uPlot/demos/arcsinh-scales.html
cube root: https://en.wikipedia.org/wiki/Cube_root#/media/File:Cube-roo...
vs arcsinh: https://upload.wikimedia.org/wikipedia/commons/9/92/Inverse_...
some interactive log scale demos:
https://leeoniya.github.io/uPlot/demos/log-scales.html
https://leeoniya.github.io/uPlot/demos/log-scales2.html