This is something we have been wrestling with for some time. It is great to see this has perked to the list. Excellent and we will try to make some collective suggestions from a variety of Nat codes we have been working on.
Steve/Jeff Kuehn et.al. On Jul 3, 2008, at 12:38 AM, Vivek Sarkar wrote: > 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://sourceforgenet/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 > ==================================================> Steve Poole Computer Science and Mathematics Division Chief Scientist / Director of Special Programs Computational Sciences and Engineering Division National Center for Computational Sciences Division Oak Ridge National Laboratory 865.574.9008 (0ffice) 865.574.6076 (Fax) "Wisdom is not a product of schooling, but of the lifelong attempt to acquire it" Albert Einstein ====================================================> ------------------------------------------------------------------------- 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
