From: Juergen Strobel <strobel@...>
Date: 2006-07-02T03:15:13+09:00
Subject: Re: [QUIZ] C-Style Ints (#85)

--9amGYk9869ThD9tj
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 01, 2006 at 09:57:18AM +0900, Daniel Martin wrote:
> I have some questions about some more edge cases.
>=20
> Ruby Quiz <james@grayproductions.net> writes:
>=20
> > 	irb(main):001:0> n =3D UnsignedFixedWidthInt.new(0xFF, 8)
> > 	=3D> 255
> > 	irb(main):002:0> n +=3D 2
> > 	=3D> 1
> > 	irb(main):003:0> n =3D n << 1
> > 	=3D> 2
> > 	irb(main):004:0> n =3D n >> 1
> > 	=3D> 1
> > 	irb(main):005:0> ~n
> > 	=3D> 254
> > 	irb(main):006:0> n +=3D 12
> > 	=3D> 13
> > 	irb(main):007:0> n =3D n & 0x0E
> > 	=3D> 12
> > 	irb(main):008:0>
>=20
> It would seem from the above that whenever there's arithmetic with a
> FWI as one operand and an Integer as the other, the result should be a
> FWI and we should do simple twos-complement arithmetic in that width.
>=20
> Now, should we also try to ensure that (2 + n) has the same result as
> (n + 2) ?
>=20
> What happens when we operate on two FWIs at once?  I would propose
> that the answer should be that the result is a FWI with as many bits
> as the larger of the two operands, but I'm stuck as to what to do when
> you add a SignedFixedWidthInt to an UnsignedFixedWidthInt.  What is
> the result?
>=20
> I'd like to propose these rules of arithmetic:
>=20
> Any operation between a FWI and a Float, Rational, or Complex has the
> same result as though the FWI were replaced by an Integer of equal
> value.

I agree. And that's a good hint for implementation :P

> For operations +, -, ^, &&, *, /, %, and ||, an Integer with a FWI (in
> either order) produces the same type of FWI as the FWI argument.  For
> those same operations, two FWIs produce an FWI with as many bits as
> the longer of the two and unsigned if either operand is unsigned.
> (rationale: like C)
>=20
> An alternative set of rules (I'm asking for a ruling here) sets the
> result of * and / to the same type as the first argument, and % to the
> same type as the second argument.  (Rationale: a * 2 is (a + a),
> whether a is a Fixnum, Float, Array, or String.  This seems like a
> property we might want to preserve when a is a FWI, even if "2" is
> only a FWI with the value of "2")

I like this second set of rules much better, or something even
simpler: The result has to be of the same class as the first
argument. If I am going to use a width-restricted integer class at
all, I expect the width to stay the same for things like

fwi +=3D other

and not be coerced to the larger width of both or some other class.
If other would be an (infinite size) ruby int, we don't coerce to that
either, don't we?

I also think we can safely ignore subtle points about C floats,
rationals etc, since we don't need to reimplement all of C's numeric
types here and sane interaction with other ruby numerics is hard
enough.

-J=FCrgen

>=20
> For ** (exponentiation), I'm not sure.  My instinct is to say that
> it's an error to raise a FWI to a negative power, and that FWI **
> FWI should produce the same type as the first argument.  (Rationale:
> it's like repeated multiplication)
>=20
> As for just taking the last n bits when passed an initial argument
> that's too wide - that's exactly what you want to do.  That lets us
> emulate the C cast-to-smaller-type:
>=20
>   short int g =3D (short int) some_big_variable;
>=20
> with FWI.new().  C is always taking only the least significant
> portion, so if we want to look like C...
>=20
>=20

--=20
 The box said it requires Windows 95 or better so I installed Linux

--9amGYk9869ThD9tj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iQEVAwUBRKa7qvy64gyiEfXtAQKs1Af/dUSX2mTHJnyfWnCg9he5qtU+huw/OwlC
mqmOrvwk2pDUmvG2C4+CIqfiR9ZuWCA23AjaWJiE1tfPn3r33ZGnaJJyAY3QwLW1
qN82zKo6U/mtmtcxw77NQkwpevN7ZH2LV/6SqPBaiyiGIf1DMn2AxmTjUt9nRmb1
EddXbbd+UsIQumRAcThr3/IauLHE4FzJE1pTp2j3aAxhzQ58l8U/jXfjof02HDxw
46vmvkG3SxtCgjIjie/UyrZHsxJYNzMNsj1yX0dxMjJW5U5f3IU6YvakVk+PEvTx
3UAZt89PrcZbN6Ieu2ptf/IzZkprlYHeDFt7B8zdmkijhe01KNdzKw==
=eiCx
-----END PGP SIGNATURE-----

--9amGYk9869ThD9tj--