4 ms·

Related question: what would be the best way to store such a value? A float would only use the mantissa-bits, so it would be rather inefficient. Perhaps as a ui

Related question: what would be the best way to store such a value? A float would only use the mantissa-bits, so it would be rather inefficient. Perhaps as a uint16 with a representation of uint16 / (2^16)?

agrajag 6y ago
Practically? float/double. You probably don’t need any more precision and maintaining easy interoperability is more important. Otherwise you just want the mantissa stored as an int or byte[] until you need it to be converted to a floating point number.
deleted 6y ago
[deleted]
uniqueid 6y ago
I'm not an expert on the ins-and-outs of floating-point numbers, but I've always heard fp types have a disproportionately large amount of their accuracy at values < 1. My guess is that it's not that wasteful sticking with floats or doubles. What I do wish the languages I used had support for, is number types that the user could clamp to a specific range. It would be nice to have my code throw an error if some function resulted in clipped audio, for example. I mean, without the programmer writing any extra code, of course.
- sgtnoodle 6y ago
  You're likely thinking of subnormal or denormal numbers, which helps floating point representation better represent tiny numbers near zero. The typical floating point number is normalized so that it's 1.xxxx*base^exponent. Since the 1 is always there, it is made implicit as a rule and only xxxx and exponent is stored in memory. There's a limit to the range of the exponent, though, and so for very tiny numbers near zero, the exponent is capped at its smallest value and the rule changes to have an implicit 0 instead of 1. Then, you can get a few more orders of magnitude 0xxx, 00xx, 000x, etc. You gradually trade significant digits for more negative exponents. I don't think it really helps for the interval 0 to 1, but rather for the interval 0 to 0.000000000000000000000000000000000001 or whatever. It doesn't give you more significant digits, but rather a gradual degradation of significant digits as they get used for exponents. Subnormal numbers are a bit controversial because of their relative utility vs. added complexity to implement them, especially in hardware.
rocqua 6y ago
I would want to keep this stored as a float. Because chances are, I am going to be multiplying other floats by this number. And the performance penalty (not to mention the maintenance penalty) of converting back-and-forth between whatever you choose and floats will probably out-weigh the gains of storing it efficiently. That said something like a uint would probably be most efficient if you did care. At that point, allignment issues also start cropping up performance wise.
tremon 6y ago
It depends on how you intend to use it. For example, in digital signal processing (audio), most processing is done using uint32 values. It would make no sense to receive the value as a float, only to convert it back to int before using it. Case in point: most software volume controls allow to specify the output volume (or rather, control the attenuation) using the full uint16 range. In this case, the entire volume range is expressed from 0x0000 to 0xFFFF. But in practice, this is just an amplification (multiplier) value between 0 and 1.

agrajag 6y ago

Practically? float/double. You probably don’t need any more precision and maintaining easy interoperability is more important. Otherwise you just want the mantissa stored as an int or byte[] until you need it to be converted to a floating point number.

deleted 6y ago

[deleted]

uniqueid 6y ago

I'm not an expert on the ins-and-outs of floating-point numbers, but I've always heard fp types have a disproportionately large amount of their accuracy at values < 1. My guess is that it's not that wasteful sticking with floats or doubles. What I do wish the languages I used had support for, is number types that the user could clamp to a specific range. It would be nice to have my code throw an error if some function resulted in clipped audio, for example. I mean, without the programmer writing any extra code, of course.

sgtnoodle 6y ago
You're likely thinking of subnormal or denormal numbers, which helps floating point representation better represent tiny numbers near zero. The typical floating point number is normalized so that it's 1.xxxx*base^exponent. Since the 1 is always there, it is made implicit as a rule and only xxxx and exponent is stored in memory. There's a limit to the range of the exponent, though, and so for very tiny numbers near zero, the exponent is capped at its smallest value and the rule changes to have an implicit 0 instead of 1. Then, you can get a few more orders of magnitude 0xxx, 00xx, 000x, etc. You gradually trade significant digits for more negative exponents. I don't think it really helps for the interval 0 to 1, but rather for the interval 0 to 0.000000000000000000000000000000000001 or whatever. It doesn't give you more significant digits, but rather a gradual degradation of significant digits as they get used for exponents. Subnormal numbers are a bit controversial because of their relative utility vs. added complexity to implement them, especially in hardware.

rocqua 6y ago

I would want to keep this stored as a float. Because chances are, I am going to be multiplying other floats by this number. And the performance penalty (not to mention the maintenance penalty) of converting back-and-forth between whatever you choose and floats will probably out-weigh the gains of storing it efficiently. That said something like a uint would probably be most efficient if you did care. At that point, allignment issues also start cropping up performance wise.

tremon 6y ago

It depends on how you intend to use it. For example, in digital signal processing (audio), most processing is done using uint32 values. It would make no sense to receive the value as a float, only to convert it back to int before using it. Case in point: most software volume controls allow to specify the output volume (or rather, control the attenuation) using the full uint16 range. In this case, the entire volume range is expressed from 0x0000 to 0xFFFF. But in practice, this is just an amplification (multiplier) value between 0 and 1.