At 03:03 PM 3/8/2001 -0800, Hong Zhang wrote:
>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.
Care to start one? I'm about to start th
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
> >plat
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
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 ass
At 08:43 PM 3/8/2001 +, Nicholas Clark wrote:
>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-
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 p
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
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
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 there
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 portable
> > > overflow detection easier, but that w
> 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
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 r
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 t
> 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 complica
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 i
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 C pointer points to the buffer holding the actual
> >
> The C structure that represents a bigint is:
>
>struct bigint {
> void *num_buffer;
> UV length;
> IV exponent;
> UV flags;
>}
>
[snip]
> The C pointer points to the buffer holding the actual
> number, C is the length of the buffer, C is the base
> 10 exponent for
17 matches
Mail list logo
