Agreed and a thoughtful path forward is a wise move. Another PL1 may not be of interest to all. ;-)
Steve... On Jul 3, 2008, at 7:07 AM, Igor Peshansky wrote: > I don't see why not. Implementing it efficiently, however, will > take some thought... > > Also, it might make the code more cluttered if all arrays have > to be parameterized by the index type. We'll need to either > consider default template arguments, or allow defining another > array type with 2 parameters. > Igor > > Stephen Poole <[EMAIL PROTECTED]> wrote on 07/03/2008 05:12:12 AM: > > > Would this apply to Nat64 (others as well) and Indexable[Point > [Nat64]]as > well ? > > > > Steve... > > > > On Jul 3, 2008, at 1:16 AM, Igor Peshansky wrote: > > > > We should probably make Indexable generic as well, so that > > Indexable[Int64] is something that's indexable by 64-bit values, > > and Indexable[Point[Int64]] is something indexable by points with > > 64-bit fields... > > Igor > > > > Jeff Kuehn wrote on 07/03/2008 01:05:03 AM: > > > > > If this means the ability to define regions with Int64 values > for the > > > bounds as well, it > > > would be a value-add. > > > > > > Regards, > > > --Jeff > > > > > > Nate Nystrom wrote: > > > > Hi Vivek, > > > > > > > > > > > > On 03 Jul 2008, at 00:38, 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. > > > > > > > > Agreed. Or, we could make Point generic; that is, support > > > > Point[Int32], Point[Int64], etc. > > > > > > > > Nate > > > > > > > > > > > > > > > > > > > >> > > > >> 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 > > > >> > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > --- > > > > 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 > > > > > > > > > > -- > > > Jeffery A. Kuehn > > > Senior HPC Evaluation Researcher > > > Scientific Computing Group, National Center for Computational > Sciences > > > Oak Ridge National Laboratory > > > One Bethel Valley Road MS6173 > > > Oak Ridge, TN 37831 > > > P:865.241.6134 F:865.241.2650 > > > > > > > > > ---------------------------------------------------------------------- > --- > > > 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 > > > > -- > > Igor Peshansky (note the spelling change!) > > IBM T.J. Watson Research Center > > XJ: No More Pain for XML's Gain (http://www.research.ibm.com/xj/) > > X10: Parallel Productivity and Performance (http://x10.sf.net/) > > > > > > > ---------------------------------------------------------------------- > --- > > 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 > > -- > Igor Peshansky (note the spelling change!) > IBM T.J. Watson Research Center > XJ: No More Pain for XML's Gain (http://www.research.ibm.com/xj/) > X10: Parallel Productivity and Performance (http://x10.sf.net/) > > ==================================================> 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
