Huh, travis fails on 32 bits with strange error. No idea what could i broke (and no 32-bit machine to test) - Float64::MAX and Float64::MIN are used only in benchmark/ips.cr and changing MAX/MIN to the finite value is the only potentially breaking change.

Try to not change MIN and MAX.

Still broken on 32-bits. No ideas.

Well, working now. I'll try to revert MAX/MIN back to finite values.

Reverted, CI is green 😄

It would be great if you could specify the float constants as hexadecimal then use unsafe_as to convert them to floats. That way we know we're not loosing precision.

@RX14 in that case, should there also be some specs ensuring that 0x34000000_u32.unsafe_as(Float32) is actually small number?

@konovod yes.

done, but there is an error on 32-bits travis again. If it happens on other PRs too it's ok (well, not ok, but unrelated), but if only on this - perhaps there is some problem with it?

@konovod what is the status of this PR?

I don't see anything preventing it from merge. Travis 32-bit was failing with apparently irrelevant error, perhaps will be green if restarted. But i forgot how to restart CI - should I force push the same commit?

This might sounds like a dumb question but are these set at compile time or runtime? seem to me things like unsafe_as would be runtime. If this is the case should these be changes to compile time? Or does it even matter?

Even if unsafe_as isn't optimized away, consts initialization happens only at start of program, so performance doesn't matter. Anyway, I've changed it to the way @RX14 suggested, so unsafe_as is now only in specs.

Thanks @konovod !