Re: bigint/bugnum library
- Posted by jaygade Jul 13, 2013
- 1770 views
The way 4.1 is right now, I would agree. If we allow atoms to be smaller than integers, then I believe that this would become a bigger incompatibility - and having both would certainly make things no easier for anyone.
I don't think that would be as big of an issue, really. Atoms can still be larger than integers, it's just that they won't be as accurate for pure integer values.
Even double atoms can still be +/- 1e37. That's WAY bigger than most machine integers. And long doubles are +/-1e307 I think? That is HUGE.
If we say that Euphoria integers are AT LEAST 64 bits (a performance issue only on 32-bit machines) then we should be okay.
Hmm. I confess that I really like the idea of having 64bit sized integers and 80bit atoms on 32bit 4.1 Euphoria. (Though this combination is not possible on ARM without some software emulation, as you pointed out.)
80-bits is good, but we shouldn't rely on it. I'm actually suggesting that maybe on 32-bit Euphoria, integers should be up to 63-bits. We can rely on that for all 32-bit implementations, I believe, with a little extra code.
But if we say that integers are 32 or 53 bits on 32 bit machines, but 63 bits or 64 bits on a 64 bit machine, then we may have problems.
Future code can be ifdef'd to deal with this when necessary. I guess the big issue is porting existing code.
We shouldn't have to ifdef much, if anything, unless existing code relied on larger ranges. Most older code relies on smaller ranges so it shouldn't be an issue.
Aside from math libraries and low level code (e.g. the interface to C libraries), I was hoping that most code wouldn't care about the underlying size of an integer or an atom. But I can see this come back to bite us when we least expect it...
I agree 100%. The Euphoria user should not have to worry about differences in underlying sizes within reason, which 80+ -bit long doubles and 63-bit integers should provide. There should be one set of limits for integers regardless of the underlying architecture, and we should advise users that limits on atoms might apply if they have a certain class of processor.
Note: None of this means that we don't need an arbitrary-precision library, because that would be useful.
