Differences in results when using the same function in CTFE and Runtime

[Quirin Schroll]

On Saturday, 10 August 2024 at 11:15:19 UTC, IchorDev wrote:
> On Friday, 9 August 2024 at 00:46:12 UTC, Nicholas Wilson wrote:
>> On Thursday, 8 August 2024 at 10:31:32 UTC, Carsten Schlote 
>> wrote:
>>> Hi
>>> - Can CTFE be used under all circumstances when float numbers 
>>> of any precision are involved?
>>> - Or is this some kind of expected behaviour whenever floats 
>>> are involved?
>>> - Is the D CTFE documentation completely covering such 
>>> possible issues?
>>>
>>> I can imagine that bugs causes by such subtil differences 
>>> might be very difficult to fix.
>>>
>>>
>>> Any experiences or thought on this?
>>>
>>
>> there are `toPrec`[1] intrinsics to solve exactly this issue 
>> of lack of truncation of precision.
>>
>>
>> [1]: 
>> https://github.com/dlang/dmd/blob/958ba9cbe3583830efe39505238939daa0dbd64c/druntime/src/core/math.d#L198-L214
>>
>>> Greetz
>>> Carsten
>
> Can anyone remind me whether there’s a way to force 
> calculations to be performed with a certain degree of precision 
> (e.g. single or double) instead of rounding down from the 
> largest floats available? Would be really useful for 
> cross-platform consistency. :’|

D specifies that floating point calculations may be performed 
with higher precision than the type suggests:

> Execution of floating-point expressions may yield a result of 
> greater precision than dictated by the source.

— [*Floating-Point Intermediate 
Values*](https://dlang.org/spec/float.html#fp_intermediate_values), D Language Specification

On almost all non-embedded CPUs, doing non-vector calculations in 
`float` is more costly than doing them in `double` or `real` 
because for single-arguments, the floats are converted to 
`double` or `real`. I consider `float` to be a type used for 
storing values in arrays that don’t need the precision and save 
me half the RAM.