fixed size integer arithmetic
sa212+gmp at cyconix.com
Mon Sep 3 11:44:06 CEST 2007
I can't speak for the OP, but...
Richard B. Kreckel wrote:
> I suppose you guys are talking about modular arithmetic, right?
In principle, yes. In practice, though, a modular arithmetic library is
probably not the best way to go (in my case, anyway).
> Did you try CLN <http://www.ginac.de/CLN/>? CLN is not C, though. It is
> (I may mention that in CLN the modulus (called "invariant" above) is a
> dynamic attribute of the class, not determined at compile time. IOW:
> different moduli are not different C++ types and mismatches cause
> runtime errors.)
I didn't find CLN; thanks for the link. My own app is modelling
hardware, and the compiler constructs which let you do this. This is
required in hardware description languages, such as VHDL and Verilog. A
simple way to look at this is to think of an N-bit processor, with N-bit
registers and an N-bit ALU, where N is arbitrary and is not necessarily
a power of 2. You then need to handle all the low-level N-bit arithmetic
and logical/bitwise operations that you'd expect to find in a processor.
Or, alternatively, take the set of operators from a language such as C
and re-implement them for arbitrary N, rather than the standard set of
8, 16, 32, and 64.
CLN might have been a useful starting point, but it doesn't appear to
have the bitwise operators, apart from << and >>, and >> seems to have a
restriction on N. There's also the issue of operations on elements of
different modular rings. There's nothing wrong, in principle, in adding
a 9-bit integer to a 191-bit integer, to get a 191-bit result (or
vice-versa), but CLN won't let you do this. It could be handled at a
higher level, but you'd then need an op to resize integers, which I
can't find. This leads on to a can of worms involving truncations and
extensions, arithmetic conversions, and so on. The actual usage of these
low-level ops turns out to be just as difficult as the low-level
More information about the gmp-discuss