It's kind of embarrassing not to support random number generation, but not having float types?
Solidity, kill yourself.

Floating types for financial stuff look like a big no-no anyway. People would invariably fuck that up by using decimal fractions and having the associated rounding errors propagate.

@Fast-Nop First, we have "endless" precision float libraries, we use them for geometry processing.
Second, I just want to compute a simple fraction, to know what percentage each user contributed to a sum 😭

@NickyBones Float is never precise with decimal fractions, and increasing the precision will only make the propagated bugs appear later, which makes them harder to fix.

For a percentage, why not just doing (100 * usersum) / totalsum? Or with rounding, (50 + 100 * usersum) / totalsum.

@Fast-Nop If you use arbitrary precision arithmetic libraries, you'll be fine. I never bothered to ask how they do it, but it works. In geometry, you can get instability in algorithms very easily if your computations are not precise (infinitesimal shift can turn a convex polygon to non convex).
Your suggestion will still give me round numbers though...which means things will not add up to 100%

@NickyBones That's right, but ordinary float support would not add up to 100 either.

And arbitrary precision support would run into a display problem if you wanted to display stuff with so many digits that it would add up - not least because the amount of required digits may be infinite, like in 1.0/3.0.

@Fast-Nop no need to display :)
Floats won't give me a 100%, but it would be pretty close. With integers I could easy get to a point where I'm missing a few percents...

You'll find lots of techniques from the 90's to work around your problem :)

Floats are not a good fit for financial stuff but yeah, it sucks that even fixed point isn't implemented yet.

“Fuck” was the only word I just understood

@NickyBones use promiles instead of percents and you have more precision.