OR as the other note mentioned, a nice "porting guide" for the unwashed masses.
Steve... On Jul 15, 2008, at 11:17 AM, Jeff Kuehn wrote: > I'd rather the shorter conversion be flagged as an error. Signed > and unsigned types are > sufficiently distinct that programmers should consider and express > how they want the > conversion to take place in each instance. > > Regards, > --Jeff > > > Nate Nystrom wrote: > > > > 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 > >> > > > > > > -- > 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 > ==================================================> 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
