Added Float32 and Float64 consts

[konovod]

Fixes #4785
Adds EPSILON, DIGITS, RADIX, MANT_DIG, MIN_EXP, MAX_EXP, MIN_10_EXP, MAX_10_EXP and MIN_POSITIVE consts to Float32 and Float64.
I've renamed DIG -> DIGITS as it imho looks clearer this way. For a ROUNDS - I don't know how to get its value and is it really needed, so skipped it.
If the constants are different for some platforms, they of course should be moved to platform-specific files, but i think they are currently same for all supported platforms.

[konovod]

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.

[ysbaddaden]

Try to not change MIN and MAX.

[konovod]

Still broken on 32-bits. No ideas.

[konovod]

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

[konovod]

Reverted, CI is green 😄

[RX14]

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.

[konovod]

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

[RX14]

@konovod yes.

[konovod]

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?

[jkthorne]

@konovod what is the status of this PR?

[konovod]

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?

[RX14]

Perhaps the specs should be the other way around: specify the real numbers as constants then check them against the hex values in the specs.

[RX14]

This should be 6.

[konovod]

nice catch, my bad!

[jkthorne]

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?

[konovod]

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.

[Sija]

Still 6 :)

[konovod]

huh

[luislavena]

Probably leftover from a change?

[bcardiff]

Thanks @konovod !