[LAD] Is -ffast-math safe for audio?

[Tim]

On 11/23/2018 09:18 AM, Gordonjcp wrote:
> On Fri, Nov 23, 2018 at 02:09:02PM +0100, Robin Gareus wrote:
>> On 11/23/2018 01:00 PM, Will Godfrey wrote:
>> [...]
>>> Thanks for going into this in such detail Robin. I never realised fp stuff
>>> could be *quite* so, umm, approximate!
>>
>> Depending on context and the maths, the difference may not matter at
>> all, or may be off completely..
> 
> Surely the answer is just to use 16-bit ints for everything, then...?
> 

I've said before: Bankers forbid fp and use BCD math,
  otherwise pennies go missing which accumulate into dollars.

Unless Will's requirement is scientific or astronomical,
  yet still requires a fairly wide range, I suggest 128-bit int math.
It may not be useful with plugin or jack audio paths, which are
  always fp, but for other things like time it really helps.

Until several months ago MusE used fp to represent time, such as
  wall-clock time and jack time etc. It caused many timing problems.
So I ripped up all of that and used 128-bit int math instead.

You just have to carefully determine your required range and
  change the units that it represents. In MusE's case, the time
  value now represents 128-bit int nanoseconds instead of fp seconds.

128-bit math is not supported fully yet on all platforms
  especially 32-bit platforms. So I used a third-party library
  'libdivide' which handles the cross-platform stuff.
I made a convenient routine which does A * B / C in 128-bit math
  since that is by far the most common general usage in our app.

Tim.