Hi, Nate, Here's a related thought. If you're adding Int8, Int16, Int32, Int64 as new value classes, it would be useful to extend them to points by adding Point8, Point16, Point32, and Point64 as well.
Best, Vivek On Jun 19, 2008, at 11:01 AM, Nate Nystrom wrote: > Hello, > > We're starting to look at adding support for unsigned integers to > X10. The proposal is to add the following value classes: > > Int8, Int16, Int32, Int64 - signed integers of the given widths > Nat8, Nat16, Nat32, Nat64 - unsigned integers of the given widths > > More familiar names (e.g., byte, ubyte, short, ushort) will be > supported via type aliases. > > Note that Nat16 is not the same as Char, although they may have the > same representation. In particular, toString() should differ, e.g., > "97" rather than "a". > > > So, some questions: > > 1. How should comparisons between signed and unsigned values work? > > Consider: > > u16 = Nat16.MAX; // 2^16-1 == 0xffff; > u32 = Nat32.MAX; // 2^32-1 == 0xffffffff; > i32 = -1; // -1 == 0xffffffff; > > What is i32 < u16? > > K&R C is "unsignedness preserving": > > i32 < u16 == (nat32) i32 < (nat32) u16 == 0xffffffff < 0xffffffff > == false > > ANSI C is "value preserving": > > i32 < u16 == (int32) -1 < (int32) 0xffff == -1 < 65536 == true > > Except if the operands have the same width: > > i32 < u32 == -1 < 2^32-1 == 0xffffffff < 0xffffffff == false > > I find both the K&R rule and the ANSI rule are non-intuitive in these > corner cases. I think the last test should return true, but it > doesn't because they have the same representation. > > So, here are some of our options: > > (a) Be unsignedness preserving in the broken K&R C way. > (b) Be value preserving in the broken ANSI C way. > (c) Be value preserving correctly (i.e., i32 < u32 == true). > (d) Disallow signed vs. unsigned comparisons, forcing the programmer > to explicitly convert. > (e) Introduce different signed and unsigned operators (probably a bad > idea) > > C#, BTW, does (c) for 32-bit values, but (d) for 64-bit values. > > Any opinions? > > > 2. What are the conversion semantics? > > Assuming 2's complement representation, we can just truncate or sign > extend to the right width and reinterpret the bits in the new type. > When converting from a signed number to a longer unsigned, do we sign > extend before widening or after? > > i16: int16 = -1; // 0xffff > (a) (i16 to nat32) == 0x0000ffff > (b) (i16 to nat32) == 0xffffffff > > ANSI C does (b) and I don't see a good reason to be different. > > > 3. Should we get rid of >>> as redundant, since >> on an unsigned int > would do the same thing? > > > Thanks, > Nate > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > X10-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/x10-users > ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ X10-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/x10-users
