zig guarantees ieee-754 floating point, so in theory it should be identical for every target
#Are constants computed with comptime_float guaranteed to be bit-identical for each compile target?
ripe girder
if you find a case where it's not, or especially where it's different if you cross-compile compared to compiling on the target, that would be a bug
it'll use hardware instructions, but it's not going to do "fast math" stuff that's nondeterministic
the results should be consistent and reproducible across machines
if you find a case that breaks, report it on the issue tracker
Zig is supposed to produce reproducible compilations, and if it doesn't that would be a bug
raven sun
Currently comptime float is jut st comptime f128, but that's an implementation detail.
I don't know of a target that does f128 in hardware, it probably exists though.
For targets that don't, f128 math is implemented on compiler_rt, you can take a look at it
For your example specifically seems like sqrt rounds to f64 first then does sqrt https://github.com/ziglang/zig/blob/6a65561e3e5f82f126ec4795e5cd9c07392b457b/lib/compiler_rt/sqrt.zig#L240
pow is implemented in std.math, and it currently only accepts f32 and f64
From what I know, compiler_rt goal is to have all operations avaliable on all platforms, but it prioritizes the native instruction when it's faster
pulsar depot
note that the C standard does not specify the accuracy of trigonometric/sqrt/pow functions. I assume that zig does the same thing as C in this case. afaik the x86 trigonometric instructions have the same (bad) accuracy to remain backwards compatible with previous generation cpus.
but you definietly can't expect deterministic results from different architectures and I wouldnt rely on corss-microarchitecture determinism either.
that is all about the functions though. regular operations such as simple arithmetic on floats is deterministic across all target architectures.