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?
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
