Re: [Tcllib-devel] Question about rshift for math::bignum

[<Lar...@re...>]

torsdagen den 9 februari 2006 kl 09.15 skrev Arjen Markus:

> Now, this is fine with a fixed and finite number of bits that =
represent
> the integer,
> but the idea of bignum is that you have an arbitrary range for the
> integers. And there
> is no two's complement implementation of the sign.

It should perhaps be remarked here that there does exist a perfectly=20
valid two's complement implementation for arbitrary integers. Just as=20
one conceptually pads a non-negative number with an infinite sequence=20
of 0's on the left, one can view a negative number (in two's complement=20=

representation) as having an infinite sequence of 1's on the left.

But your point is probably that math::bignum simply does not use such a=20=

two's complement representation, and therefore exhibits a different=20
native shift behaviour.

> So, my question is:
>
> Should we strive to make rshift produce the _same_ results as Tcl's >>
> operator?

Since the future for math::bignum is likely to be to provide an option=20=

for backwards compatibility for the Tcl 8.5 built-in bignums, I think=20
they should, yes.

> If so, how should we do this?

Am I right in suspecting that the difference is that=20
math::bignum::rshift in principle divides by a power of two and rounds=20=

towards 0, whereas >> in principle divides by a power of two and rounds=20=

downwards? In that case a fix would be to subtract 1 from the current=20
math::bignum::rshift result if not all the out-shifted bits are zeroes.

Lars Hellstr=F6m=