4 ms·

The big issue I see with these is that the number of bits is dependent on the stored value. It's also not a power of two. This has a lot of problematic conseque

by yoklov 11y ago

The big issue I see with these is that the number of bits is dependent on the stored value. It's also not a power of two. This has a lot of problematic consequences. Indexing into a list of them wouldn't be constant time, for example. You'd need to unpack them (into fixed size unums?) first. That said, information here is sparse and I'm not an expert on numerical computing (although I do graphics at work and know some about the subject).

dnautics 11y ago
For any unum system there's an 'archtecture spec' that puts parameters on the maximum sizes of the exponent and mantissa. You can have values that consume less bits, the format contains a tag that says how many bits you are consuming for each part of your number, a lower size indicates for exact values that less size is needed; for uncertain values it means the uncertainty is higher. You could pad your values to achieve constant time indexing.
- davisourus 11y ago
  This is exactly right - there's an environmental configuration. Think of the way it's ridiculous to play angrybirds with 32 or 64bit precision on your phone, you could set the precision appropriately. Or on the other side, think of how IEEE lops off data from every multiply or divide (any precision) without any point of reference for uncertainty.
jlgustafson 11y ago
There is a whole chapter on "fixed-size unums" and the issues of making them just as easy to index as arrays as are floats. It really is not an obstacle; it's just more work for the CPU to manage pointers and variable sizes, very similar to the way computers made the transition to displaying variable-width fonts in the 1980s at a time when many asserted that it would be horribly difficult and inefficient and require pixel-accurate placement instead of landing letters in 6x8 pixel blocks.
jlgustafson 11y ago
There is a whole chapter on "fixed-size unums" and the issues of making them just as easy to index as arrays as are floats. It really is not an obstacle; it's just more work for the CPU to manage pointers and variable sizes, very similar to the way computers made the transition to displaying variable-width fonts in the 1980s at a time when many asserted that it would be horribly difficult and inefficient and require pixel-accurate placement instead of landing letters in 6x8 pixel blocks.

by yoklov 11y ago

dnautics 11y ago

For any unum system there's an 'archtecture spec' that puts parameters on the maximum sizes of the exponent and mantissa. You can have values that consume less bits, the format contains a tag that says how many bits you are consuming for each part of your number, a lower size indicates for exact values that less size is needed; for uncertain values it means the uncertainty is higher. You could pad your values to achieve constant time indexing.

davisourus 11y ago
This is exactly right - there's an environmental configuration. Think of the way it's ridiculous to play angrybirds with 32 or 64bit precision on your phone, you could set the precision appropriately. Or on the other side, think of how IEEE lops off data from every multiply or divide (any precision) without any point of reference for uncertainty.

jlgustafson 11y ago

There is a whole chapter on "fixed-size unums" and the issues of making them just as easy to index as arrays as are floats. It really is not an obstacle; it's just more work for the CPU to manage pointers and variable sizes, very similar to the way computers made the transition to displaying variable-width fonts in the 1980s at a time when many asserted that it would be horribly difficult and inefficient and require pixel-accurate placement instead of landing letters in 6x8 pixel blocks.

jlgustafson 11y ago