4 ms·
The charts are horrible 1) The y-axis (time) is logarithmic, while the x-axis(size) is linear. 2) The x-axis begins at 1000, which makes it seem like there's
by rorrr2 13y ago
The charts are horrible
1) The y-axis (time) is logarithmic, while the x-axis(size) is linear.
2) The x-axis begins at 1000, which makes it seem like there's a huge size difference between the slowest programs, which isn't true.
- deleted 13y ago[deleted]
- gus_massa 13y ago1) What' is so bad about log-linear graphic? My rule of thumb is trying to use an scale were the graph looks like a line. Line are easy to understand, and to apply the inverse transformations to get the true form of the curve and an approximate formula. In a graph it's difficult to distinguish the positive part of 1/x, 1/x^2, ..., e^{-x}, ...
- rorrr2 13y agoBecause we don't perceive time logarithmically. 10 sec compression is 10 times worse than 100 sec compression. So looking at the first chart, lpaq9i and durilca4linux points are right next to each other, while in realty durilca4linux is 530sec slower.
- fdej 13y agoI don't see the problem. It's obvious what the chart conveys if you stop to think for a moment (at least speaking for myself, I'm used to looking at graphs with a logarithmic time scale, and didn't think about it). In fact, it's reasonable that a linear improvement in compressed size should require an exponential increase in time and memory.
- mtdewcmu 13y agoIf the size was logarithmic, then the differences would become invisible. There are sharply diminishing returns as size improves.