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

[Arjen M. <arj...@wl...>]

Lars Hellstr=F6m wrote:
>=20

>=20
> But your point is probably that math::bignum simply does not use such a
> two's complement representation, and therefore exhibits a different
> native shift behaviour.
>=20

It does not. It actually implements them in a 2**N-ary representation.

> > So, my question is:
> >
> > Should we strive to make rshift produce the _same_ results as Tcl's >=
>
> > operator?
>=20
> Since the future for math::bignum is likely to be to provide an option
> for backwards compatibility for the Tcl 8.5 built-in bignums, I think
> they should, yes.
>=20

Well, that is clear then. I was hoping for the easy answer, I must=20
admit :)

> > If so, how should we do this?
>=20
> Am I right in suspecting that the difference is that
> math::bignum::rshift in principle divides by a power of two and rounds
> towards 0, whereas >> in principle divides by a power of two and rounds
> downwards? In that case a fix would be to subtract 1 from the current
> math::bignum::rshift result if not all the out-shifted bits are zeroes.
>=20

Now, that is an interesting thought ... I haven't fathomed the effect=20
of this padding yet, but if we can translate it to so simple an
algorithm,
I am all for it.

Regards,

Arjen