www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Cent/UCent as library types

reply "monarch_dodra" <monarchdodra gmail.com> writes:
I'm asking this as a end user:

It was my understanding that cent/ucent where more or less 
abandoned as native types. But would it be possible to have 
Cent/UCent as library types?

We have Complex, and Walter recently proposed the HalfFloat type.

Why not Cent and UCent?

Is it too complex for library code? I'd suspect you need to catch 
overflow flags for efficient carry over, but D has built-in asm, 
so that shouldn't be too complicated... Should it?

Or do we already have some sort of generic (statically sized) big 
inter, eg:
Big!128 or UBig!128? Or if not, would we want that?

Should I open an ER for either of the two ideas?
Dec 31 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, December 31, 2012 19:56:11 monarch_dodra wrote:

 I'm asking this as a end user:
 
 It was my understanding that cent/ucent where more or less
 abandoned as native types.


Abandonded? They were specifically reserved for being used for 128-bit signed 
and unsigned types at an indeterminate point in the future. Nothing was 
abandonded, but nothing has been needed either, so it hasn't been implemented.


 But would it be possible to have Cent/UCent as library types?
 
 We have Complex, and Walter recently proposed the HalfFloat type.
 
 Why not Cent and UCent?
 
 Is it too complex for library code? I'd suspect you need to catch
 overflow flags for efficient carry over, but D has built-in asm,
 so that shouldn't be too complicated... Should it?
 
 Or do we already have some sort of generic (statically sized) big
 inter, eg:
 Big!128 or UBig!128? Or if not, would we want that?
 
 Should I open an ER for either of the two ideas?


I'd argue for sticking to BigInt if you want big numbers rather than adding 
the complication of adding a Cent and UCent library type. To get them right, 
you need a fair bit of what BigInt has anyway. What gain is there in having 
Cent or UCent over just using BigInt? I could see benefit in 128 bit built-in 
types, but I don't see what the point is of library types for them, not when 
we already have BigInt.

- Jonathan M Davis
Dec 31 2012
next sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Monday, 31 December 2012 at 19:10:09 UTC, Jonathan M Davis 
wrote:

 but I don't see what the point is of library types for them, 
 not when we already have BigInt.


  Fixed sizes means no GC/allocation for passing the data around 
to functions; And optimized assembly code. Beyond that, it 
doesn't seem highly important. But if it's around as a viable 
option people will begin using it.

  You never know when/where you could need it.
Dec 31 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, December 31, 2012 20:24:42 Era Scarecrow wrote:

 On Monday, 31 December 2012 at 19:10:09 UTC, Jonathan M Davis
 
 wrote:

 but I don't see what the point is of library types for them,
 not when we already have BigInt.


 
   Fixed sizes means no GC/allocation for passing the data around
 to functions; And optimized assembly code. Beyond that, it
 doesn't seem highly important. But if it's around as a viable
 option people will begin using it.
 
   You never know when/where you could need it.


Given that we already have cent and ucent reserved specifically for 128-bit 
integral types, I think that Cent and UCent only make sense if we have an 
urgent use case that needs 128-bit integral types where BigInt won't work, and 
we need a big reason not to just implement cent and ucent. Otherwise, why not 
just implement cent and ucent? Long term, Cent and UCent just don't make 
sense.

If someone wants to implement them for themselves, fine. But since the plan is 
presumably to implement cent and ucent eventually, why put them in the 
standard library where they've effectively given themselves an expiration date? 
Especially when it's likely to be a rather niche need in the first place?

- Jonathan M Davis
Jan 01 2013
prev sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 31 December 2012 at 19:10:09 UTC, Jonathan M Davis 
wrote:

 On Monday, December 31, 2012 19:56:11 monarch_dodra wrote:

 I'm asking this as a end user:
 
 It was my understanding that cent/ucent where more or less
 abandoned as native types.


 Abandonded? They were specifically reserved for being used for 
 128-bit signed
 and unsigned types at an indeterminate point in the future. 
 Nothing was
 abandonded, but nothing has been needed either, so it hasn't 
 been implemented.

 [SNIP]

 - Jonathan M Davis


I remember reading somewhere that they would never be 
implemented, but that cent/ucent was still forbidden keyword, to 
avoid any confusion.

My bad then I guess.
Dec 31 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, December 31, 2012 21:11:13 monarch_dodra wrote:

 I remember reading somewhere that they would never be
 implemented, but that cent/ucent was still forbidden keyword, to
 avoid any confusion.
 
 My bad then I guess.


They won't ever be implemented for D1, since D1 will be unsupported following 
the next release, which may be where you heard that. For D2, it's a question 
of when Walter thinks that they're worth implementing, and AFAIK, there is no 
current plan as to when that would be (particularly since there are no 128-bit 
x86 systems on the horizon). It's definitely not the case though that it was 
decided that they would never be implemented for D2.

- Jonathan m Davis
Jan 01 2013