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
next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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
prev sibling 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