Hi Steve,
On 15 Jul 2008, at 08:55, Stephen Poole wrote: > 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. I agree with all of this. > 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'm not sure exactly what you mean by this. Can you elaborate? My intent is to support explicit conversions, so: x to int32 -- converts x to a signed 32-bit integer x to uint32 -- converts x to an unsigned 32-bit integer There will be no implicit coercions between signed and unsigned integers. > > > 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... Nate > > > 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 > ------------------------------------------------------------------------- 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
