cent/ucent

[Jonathan M Davis]

bearophile wrote:

> This is one of the last dmd changes:
> http://www.dsource.org/projects/dmd/changeset/557
> 
> cent/ucent are probably easy to implement, their implementation can
> require little code on 64 bit systems, and operations done among them are
> probably fast on 64 bit systems.
> 
> 128 bit unsigned numbers can represent:
> 340_282_366_920_938_463_463_374_607_431_768_211_455
> Many normal programs don't overflow such numbers. A cent number can also
> be used to store safely the result of many operations done on 64 bit
> values. And generally I like the idea of having them...
> 
> But while I know of few scientific computations situations where quadruple
> precision floating point numbers can be useful, in practice I don't know
> of situations where cent/ucent can be useful.
> 
> One possible situation where ucent can be useful is to perform bitwise
> operations on 128-bits-wide SSE registers. But a good D compiler can use
> exactly the same CPU instructions when those operators are used among
> uint[4] fixed-sized arrays.
> 
> So unless some significant application can be found, I suggest to not add
> cent/ucent. All features in the language need a purpose, adding useless
> things is bad. They can be kept among reserved keywords (as 'macro') for
> possible 128-bit CPUs.
> 
> On the other hand instead of cent/ucent I have several situations (not
> related with cryptography) where I'd like in D a built-in "bint" or
> "bigint", that is the multi-precision integers (currently in a std.bigint
> module... well, the module was present in 2.046, I can't see it in Phobos
> of 2.047, I don't know why). Having it built-in allows for better
> multi-precision literals.
> 
> (There are other number types that probably are more useful than
> cent/ucent, like a decimal floating point (IEEE standard 854-1987), useful
> for concurrency.)
> 
> Bye,
> bearophile

cent and ucent are not currently implemented and have no need to be 
implemented at this point. They are reserved for when they will be deemed 
useful enough to implement (perhaps when we actually have 128-bit machines). 
In the meantime, I see no need to worry about it. They'll get implemented 
when it's appropriate. For now, we can just leave them as reserved and not 
worry about them. The fact that they exist makes it possible to implement 
them later without breaking backwards compatibility.

- Jonathan M Davis