The C structure that represents a bigint is:
struct bigint {
void *num_buffer;
UV length;
IV exponent;
UV flags;
}
[snip]
The Cnum_buffer pointer points to the buffer holding the actual
number, Clength is the length of the buffer, Cexponent is the base
10
At 03:00 PM 3/8/2001 +, David Mitchell wrote:
The C structure that represents a bigint is:
struct bigint {
void *num_buffer;
UV length;
IV exponent;
UV flags;
}
[snip]
The Cnum_buffer pointer points to the buffer holding the actual
number,
Looks like they do operations with 16-bit integers. I'd as soon go with
32-bit ones--wastes a little space, but should be faster. (Except where we
should shift to 64-bit words)
Using 32/31-bit requires general support of 64-bit arithmetics, for shift
and multiply. Without it, we have to use
On Thu, Mar 08, 2001 at 11:43:31AM -0500, Dan Sugalski wrote:
I was thinking maybe (length/4)*31-bit 2s complement to make portable
overflow detection easier, but that would be only if there wasn't a good C
library for this available to snag.
The only portable integer overflow in ANSI C is
I was thinking maybe (length/4)*31-bit 2s complement to make portable
overflow detection easier, but that would be only if there wasn't a good C
library for this available to snag.
I believe Python uses (length/2)*15-bit 2's complement representation.
Because bigint and bitnum are
At 06:49 PM 3/8/2001 +, Nicholas Clark wrote:
On Thu, Mar 08, 2001 at 11:43:31AM -0500, Dan Sugalski wrote:
I was thinking maybe (length/4)*31-bit 2s complement to make portable
overflow detection easier, but that would be only if there wasn't a good C
library for this available to
At 10:49 AM 3/8/2001 -0800, Hong Zhang wrote:
I was thinking maybe (length/4)*31-bit 2s complement to make portable
overflow detection easier, but that would be only if there wasn't a good C
library for this available to snag.
I believe Python uses (length/2)*15-bit 2's complement
At 03:35 PM 3/8/2001 -0500, Bryan C. Warnock wrote:
On Thursday 08 March 2001 11:43, Dan Sugalski wrote:
It probably ought to be left undefined, in case we switch implementations
later.
Er, except, aren't you (we) supposed to be defining the implementation?
I thought the hand-waving period
On Thursday 08 March 2001 11:43, Dan Sugalski wrote:
It probably ought to be left undefined, in case we switch implementations
later.
Er, except, aren't you (we) supposed to be defining the implementation?
I thought the hand-waving period was over, and we're doing specifications.
If
On Thu, Mar 08, 2001 at 11:31:06AM -0800, Hong Zhang wrote:
Looks like they do operations with 16-bit integers. I'd as soon go with
32-bit ones--wastes a little space, but should be faster. (Except where we
should shift to 64-bit words)
Using 32/31-bit requires general support of 64-bit
At 08:34 PM 3/8/2001 +, Nicholas Clark wrote:
On Thu, Mar 08, 2001 at 01:55:57PM -0500, Dan Sugalski wrote:
At 06:49 PM 3/8/2001 +, Nicholas Clark wrote:
On Thu, Mar 08, 2001 at 11:43:31AM -0500, Dan Sugalski wrote:
I was thinking maybe (length/4)*31-bit 2s complement to make
On Thu, Mar 08, 2001 at 04:28:48PM -0500, Dan Sugalski wrote:
At 08:43 PM 3/8/2001 +, Nicholas Clark wrote:
I think most processors that do 32x32 multiply provide a way to get the
64-bit result. Whether *we* can is another matter, of course, but if
platform folks want to drop to
At 10:28 PM 3/8/2001 +, Nicholas Clark wrote:
On Thu, Mar 08, 2001 at 04:28:48PM -0500, Dan Sugalski wrote:
At 08:43 PM 3/8/2001 +, Nicholas Clark wrote:
I think most processors that do 32x32 multiply provide a way to get the
64-bit result. Whether *we* can is another matter, of
For bigint, we definite need a highly portable implementation.
People can do platform specific optimization on their own later.
We should settle the generic implementation first, with proper
encapsulation.
Hong
Do we need to settle on anything - can it vary by platform so that 64 bit
14 matches
Mail list logo
