Peter Marreck (Mar 12 2025 at 16:30): Peter Marreck (Mar 12 2025 at 16:30):Noticed in the FAQ that heap-allocated bignums are not available. I think this does make sense from a design perspective at this stage of the language's development. But the FAQ further states that (paraphrased) you really need a good use-case for them due to all the tradeoffs. Well, here's one:
I work (mostly) in finance, and I was recently looking at the low-level languages space to do some calcs quickly, while also preserving accuracy by eliminating rounding across many many math operations dealing with currency, and it turns out that the best way to completely eliminate rounding errors is to use a Rational with a bignum-integer numerator and a bignum-integer denominator (using GCD algorithm to reduce every so often) and only do all your computations across Rationals, and while this MAY, IN MOST CASES result in numbers that fit within a 128-bit integer, it's not guaranteed anymore. And you wouldn't be working with a functional language if you didn't like nice guarantees, right? :)
Anyway, that's a pretty good use-case IMHO. Because the workaround would be to possibly force the fraction to reduce just enough to fit within 128 bits (halving both numerator and denominator via a bit-shift, probably) and then somehow track the accumulated error in a Rational data structure with metadata (perhaps tracking the number of forced shifts/discarded bits)... And note that since the result of a calculation would be the overflow, you'd have to implement this hack in all ops done to Rationals, catch the overflow error, and retry with forced reductions until the calculation goes through...
Sounds like a library someone could write... Hmmm. ;) I wish I wasn't at a loss for time, but maybe this will manage to nerd-snipe one of you... because I'm feeling the pull...
Brendan Hansknecht (Mar 12 2025 at 17:57):I agree with the use case being reasonable. Sounds like something that would hopefully be doable with reasonable results solely in user space and not requiring any changes to the standard library or custom zig builtins.
Kevin Gillette (Mar 27 2025 at 05:35):Zig has arbitrary sized integers (e.g. u7). Would there be room for Roc allowing Dec types to similarly have user-defined precision, e.g. 256-bit, in exchange for fewer assurances of optimal performance?
Richard Feldman (Mar 27 2025 at 13:09):I don't think so, no
Richard Feldman (Mar 27 2025 at 13:11):the OP use case sounds like a great example of a userspace numeric type :big_smile:
Richard Feldman (Mar 27 2025 at 13:12):to me, it definitely seems like this thread reinforces the conclusion that the current design is making the right tradeoffs already!
Last updated: Jun 16 2026 at 16:19 UTC