I’ve got some quite trivial code in C that I’m trying to wrestle into re-implementation in TADS3. It uses unit32 values. That means there are values that won’t fit into TAD3’s intrinsic Integer type, and there’s no uint32-equivalent intrinsic type. So as far as I know, BigNumber is the only option.
But a trivial declaration like v = new BigNumber(2654435761); throws a warning:
sample.t(32): warning: constant value exceeds integer range; promoted to BigNumber
What’s the proper ritual for declaring this sort of thing so as to not throw a bunch of warnings? Alternately, is there some other way of working with unsigned 32 or 64 bit integers in TADS3?
It’s a bit frustrating how much basic nuts and bolts programming IF authoring systems seem to want to prohibit.
Oooof. It looks like the question might be moot, at least as far as what I was trying to do. Because you can’t do bitwise operations on a BigNumber. So it looks like there’s literally no way to accomplish what I want to do in TADS3.
You can initialize BigNumber with a string. This works: v = new BigNumber('2654435761').
But, yeah, I don’t see how you can easily perform bitwise operations on them, especially since BigNumber internally stores the value with decimal encoding.
Can you do the operations on that number as a signed int32? That would be -1640531535 or 0x9E3779B1. Bitwise operations and addition/subtraction will work, but you’d just have to be careful with multiplication or comparisons.
Unfortunately not. One of the specific bits of code I wanted to implement is fast hash (specifically a slight modification of xxHash) to be used as a multiply-seeded PRNG.
What I’ll probably do is just kludge together something equivalent, possibly by precomputing a bunch of values and using them in-game as a lookup table (general programming sense of lookup table, not the TADS3 LookupTable), or maybe just doing a roll-your-own algorithm and not worrying about the quality of the randomness.
Yeah some LFSR-ish thing or a Pearson hash are what I just kudged together since posting the question, but I haven’t looked at the quality of the numbers they’re producing or the performance of TADS running them.
I’m kinda leaning toward precompute and lookup as an approach, since I don’t think any bitwise arithmetic is that performant in TADS, and I kinda want to be able to make lots of calls at runtime.
having worked 8 and 16 bit assembler, the obvious answer should be using two 32-bit integer as ersatz 64 bit integer, but tads format don’t have an underlying assembler language as zcode and glulx.
basically, one needs checking the owerflow of the lower 32-bit integer and increase accordingly the upper 32-bit integer.