3 ms·
Representing numbers in decimal ASCII/Unicode shouldn't be too bad in that regard, should it? If we're representing a sparse matrix, the '0' character occupies
by MaxBarraclough 6y ago
Representing numbers in decimal ASCII/Unicode shouldn't be too bad in that regard, should it? If we're representing a sparse matrix, the '0' character occupies one byte, whereas a 32-bit representation occupies 4 (whether floating point or fixed point).
Both representations should lend themselves to compression.
- jstimpfle 6y agoText requires at least two bytes (it needs a separator), and negative numbers require yet another byte. So it's hard to make a point that they occupy less storage. But there is another advantage: it can represent infinitely large numbers.
- MaxBarraclough 6y ago> Text requires at least two bytes (it needs a separator), and negative numbers require yet another byte. True. > it's hard to make a point that they occupy less storage No, like I said, it would occupy less storage for sparse data. That's true even with separator characters (2 bytes as against 4). Doubtless there are much better solutions for representing sparse data that aren't human readable. A simple (index, value) dictionary, say. > it can represent infinitely large numbers Right, there's no upper bound beyond the limitations of the systems, although again a non-human-readable bignum format could do this more efficiently.
- retrac 6y agoThe algorithm give above is an excellent, extremely fast compression algorithm for ASCII-encoded numbers :)