We have been knocking this about. Here are some thoughts. "But K&R C always defaulted to what was easier in hardware. C was just a high level assembler. Stuff was implementation dependent. Like signed or unsigned char. What was the default? That is one reason I do not believe C is a productivity language and one cannot make it such (e.g. UPC.) X10 is a new languages and mistakes from older languages should not be propagated. So let's propose the correct things. Codes have to be ported to X10. Users have to think about each line of code. Signed ints should do the correct things and Unsigned ints should also be consistent within there space. When mixing is done casting has to be explicit. Unsigned should not be sign extended because it does not have a sign. Maybe there should be a monad that "signs" an unsigned number either positive or negative and another that removes the signess from a signed int."
I think we should have an open dialog on this as it will have a long term effect on X10.We need to get it right. 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 ====================================================> ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ X10-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/x10-users
