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/)
-------------------------------------------------------------------------
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
