On 15 Jul 2008, at 09:23, Jeff Kuehn wrote: > Would that syntax allow one to be able to say something like: > > int32 x; > ((x to uint32) to uint64)... > or > ((x to int64) to uint64)... > > to explicitly force or prevent sign extension? >
Yes, certainly. The question, I suppose, is whether transitive conversions like 'x to uint64' should be allowed. I believe C treats this as: '(x to int64) to uint64'. Does the convenience of a shorter conversion syntax outweigh the possible confusion about what the conversion does? Nate > Regards, > --Jeff > > > Nate Nystrom wrote: >> 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 >> > > -- > 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 > > ------------------------------------------------------------------------- > 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
