3 ms·

I don't know anything about FLAC, but is the implicit modular arithmetic the expected behavior here? What if a product or a sum overflows?

• jstimpfle 10y ago
  My assumption would be that the assumption was that 64-bit arithmetic is somehow more time efficient and 32-bit is more memory efficient while still large enough to hold the results.
• nkurz 10y ago
  I think the shift at the end (>> qlp_shift) takes care of this. The multiplication and sum are done in 64-bit, and then the sum is presumably shifted enough so as to fit in 32-bits.
  • junke 10y ago
    Thanks. Isn't it possible to give a "coefficients" vector with large enough values so that computations with 64 bits would overflow too? I don't doubt the code works in practice, because the range of values are reasonable. However this is not explicit, just looking at the code. I'd prefer if the actual domains were being made obvious. Right now, 12, 32 and 64 feel like magic numbers in the code.
• Ruud-v-A 10y ago
  Good question! It turns out that 64 bit arithmetic does not overflow (I explain this in a comment in the source code [1]) up to the shift. The shift amount must then be large enough to fit the result in 32 (or actually, 24 or usually 16) bits. For a valid FLAC file this will be the case. For an invalid FLAC file it might truncate, but an invalid file cannot be decoded properly anyway. The shift amount is a 5 bit signed number [2], so it is never possible to shift by the integer width or more. [1]: https://github.com/ruuda/claxon/blob/91b6af9/src/subframe.rs#L476-L481 https://github.com/ruuda/claxon/blob/91b6af9/src/subframe.rs... [2]: https://github.com/ruuda/claxon/blob/91b6af9/src/subframe.rs#L576-L579 https://github.com/ruuda/claxon/blob/91b6af9/src/subframe.rs...
  • junke 10y ago
    Thanks for the detailed answer.