Differences in results when using the same function in CTFE and Runtime
Timon Gehr
timon.gehr at gmx.ch
Wed Aug 14 02:35:08 UTC 2024
On 8/14/24 00:35, claptrap wrote:
> On Tuesday, 13 August 2024 at 21:03:00 UTC, Timon Gehr wrote:
>> On 8/13/24 13:09, Abdulhaq wrote:
>>
>> At the same time, "better accuracy" is part of the reason why CTFE
>> uses higher floating-point precision, but higher precision does not
>> mean the result will be more accurate. Unless arbitrary precision is
>> used, which is even slower, it leads to double-rounding issues which
>> can cause the result to be less accurate.
>
> If you have a pristine 24 bit audio sample, maybe 120db SnR due to DAC
> limitations. Processing it in 16 bit will automatically loose you 4 bits
> of accuracy, it'll drop the SnR to 96dbs. If you process it at 32 bits
> you still have 120db SnR, greater precision but same accuracy as the
> source.
>
> The point is the statement "higher precision does not mean the result
> will be more accurate." is only half true.
> ...
It is fully true. "A means B" holds when in any situation where A holds,
B also holds. "A does not mean B" holds when there is a situation where
A is true but B is false.
Clearly I am not saying that higher accuracy implies lower precision,
just that there are cases where lower precision gives you higher accuracy.
> If the precision you are doing the calculations at is already higher
> than the accuracy of your data, more precision wont get you much of
> anything.
> ...
It may even break some algorithms, especially when it is inconsistently
and implicitly applied, which is the case in D.
> but if the converse is true, if you are processing the data at lower
> precision than the accuracy of your source data, then increasing
> precision will absolutely increase accuracy.
>
Usually true, but I still want to decide on my own which computation
will be rounded to what precision. Even an accidentally avoided accuracy
issue resulting from not guaranteed implicit higher precision is a
ticking time bomb and very annoying to debug when it goes off.
More information about the Digitalmars-d
mailing list