Speaking of axing things from the spec before 1.0,
what will happen to the "cent" and "ucent" types ?

As in: they're not even in the DMD keyword list...
Sounds like good candidates for termination to me.


They don't seem to be just buggy and/or problematic
like "bit" and "real" are, but fully unimplemented ?

And one could just use etc.bigint* or even ulong[] instead ?
http://www.digitalmars.com/d/archives/digitalmars/D/8959.html


Or is it somehow remotely connected to "vector" types ?
(those are OTOH very useful already, and all 128 bits)

Adding SIMD support to D does sound like a lot more work
than a 128-bit integer type, even if a lot more useful...


Or is there any other possible reason for keeping the 2¢ ?
--anders


* http://svn.dsource.org/svn/projects/deimos/trunk/docs/bigint.html
  (Arcane Jill's code does come with one of the weirdest licenses,
   making it unsuitable for any library, but there are others too;
   such as "GNU MP Bignum": http://www.swox.com/gmp, written in C++)

"Anders F Björklund" <afb@algonet.se> wrote in message news:cu7v1j$2c11$1@digitaldaemon.com...
> Speaking of axing things from the spec before 1.0,
> what will happen to the "cent" and "ucent" types ?

If they're 128-bit integers, then I say: let's have 'em. Or at least lets leave them in the spec, so we can have 'em later.

JMO

Matthew wrote:

>>Speaking of axing things from the spec before 1.0,
>>what will happen to the "cent" and "ucent" types ?
> 
> If they're 128-bit integers, then I say: let's have 'em. Or at
> least lets leave them in the spec, so we can have 'em later.

But what good are they ? Isn't long "emulated" often enough ?
(the whole idea was to take pure fantasy stuff out of the spec)

--anders

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anders F Björklund schrieb am Tue, 08 Feb 2005 00:38:04 +0100:
> Matthew wrote:
>
>>>Speaking of axing things from the spec before 1.0,
>>>what will happen to the "cent" and "ucent" types ?
>> 
>> If they're 128-bit integers, then I say: let's have 'em. Or at least lets leave them in the spec, so we can have 'em later.
>
> But what good are they ? Isn't long "emulated" often enough ? (the whole idea was to take pure fantasy stuff out of the spec)

They should at least remain as "reserved" keywords. Otherwise any
 - still distand - improvements would be hampered by missing keywords.

Meanwhile the compiler should check that those keywords aren't used and don't later cause some of the "length" problems.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCCAO53w+/yD4P9tIRAim5AKCjuzbIWexWIklgEOBglPVY2mWuggCgrNvn
2pEK/KQ7kg5Bx1qdn0YlFjw=
=+E33
-----END PGP SIGNATURE-----

"Anders F Björklund" <afb@algonet.se> wrote in message news:cu8u4s$18m3$1@digitaldaemon.com...
> Matthew wrote:
>
>>>Speaking of axing things from the spec before 1.0,
>>>what will happen to the "cent" and "ucent" types ?
>>
>> If they're 128-bit integers, then I say: let's have 'em. Or at least lets leave them in the spec, so we can have 'em later.
>
> But what good are they ? Isn't long "emulated" often enough ? (the whole idea was to take pure fantasy stuff out of the spec)

Ok, you've persuaded me.

I'm the one who always insists on adding some unused fields in communications packet headers, "just in case".

:-)

Thomas Kuehne wrote:
> Anders F Björklund schrieb am Tue, 08 Feb 2005 00:38:04 +0100:
> 
>>>Matthew wrote:
>>>
>>>
>>>>>Speaking of axing things from the spec before 1.0,
>>>>>what will happen to the "cent" and "ucent" types ?
>>>>
>>>>If they're 128-bit integers, then I say: let's have 'em. Or at
>>>>least lets leave them in the spec, so we can have 'em later.
>>>
>>>But what good are they ? Isn't long "emulated" often enough ?
>>>(the whole idea was to take pure fantasy stuff out of the spec)
> 
> 
> They should at least remain as "reserved" keywords. Otherwise any
>  - still distand - improvements would be hampered by missing keywords.
> 
> Meanwhile the compiler should check that those keywords aren't used
> and don't later cause some of the "length" problems.
> 
> Thomas
> 
> 


We don't want to have to use "long long" for cent once it's implemented.

Thomas Kuehne wrote:

> They should at least remain as "reserved" keywords. Otherwise any
> - - still distand - improvements would be hampered by missing keywords.

You mean they should be added as keywords ? (for the first time)
(along with TOKint128, TOKuns128 and some kind of format char...)
	
> Meanwhile the compiler should check that those keywords aren't used
> and don't later cause the some of the "length" problems.

But length was not a keyword, but a dirty hack that affected Kris...
"bool" on the other hand, could be made into a proper D keyword ?


But I guess if we can support "real" with two doubles for
platforms that don't have any built-in 80-bit FPU registers*
(such as PPC and Sparc), then we can support "cent" by using
two long longs on platforms with 64-bit support (or 4 longs ?)

Just thought it was easier to have that in a library instead...
(and if needed, could be adding back in as 2.0 feature along
with the array operations and array/function literals and so)
Or do you think we'll have 128 bit CPUs, by the time D is out ?

--anders

* this is done by the C compiler, just as it is for long longs

John Demme wrote:

>>>> But what good are they ? Isn't long "emulated" often enough ?
>>>> (the whole idea was to take pure fantasy stuff out of the spec)
>>
>> They should at least remain as "reserved" keywords. Otherwise any
>>  - still distand - improvements would be hampered by missing keywords.
>>
> We don't want to have to use "long long" for cent once it's implemented.

You could use of course also use four "long" integers, instead :-)
(which is what the computer will end up with on 32-bit CPUs anyway)

--anders

Anders F Björklund wrote:
> John Demme wrote:
> 
>>>>> But what good are they ? Isn't long "emulated" often enough ?
>>>>> (the whole idea was to take pure fantasy stuff out of the spec)
>>>
>>>
>>> They should at least remain as "reserved" keywords. Otherwise any
>>>  - still distand - improvements would be hampered by missing keywords.
>>>
>> We don't want to have to use "long long" for cent once it's implemented.
> 
> 
> You could use of course also use four "long" integers, instead :-)
> (which is what the computer will end up with on 32-bit CPUs anyway)
> 
> --anders

I think we've got something here...

int int int int myBigInt = ...;// Some huge number

The four int specifiers tell the compiler to create a 128-bit variable using four 32-bit ints, whereas

long long myBigInt = ...;//Some huge number
Tells it to use two 64-bit integers.

This way, the former would only use half of each register on 64-bit chips.


Heh... Too bad I can't think of a single good reason for anyone to use such a frivilous feature.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anders F Björklund schrieb am Tue, 08 Feb 2005 01:30:45 +0100:
> Thomas Kuehne wrote:
>
>> They should at least remain as "reserved" keywords. Otherwise any
>> - - still distand - improvements would be hampered by missing keywords.
>
> You mean they should be added as keywords ? (for the first time)
> (along with TOKint128, TOKuns128 and some kind of format char...)

They are "Basic Data Types" but no kewords right now ...

?format char?

>> Meanwhile the compiler should check that those keywords aren't used and don't later cause some of the "length" problems.
>
> But length was not a keyword, but a dirty hack that affected Kris... "bool" on the other hand, could be made into a proper D keyword ?

<snip>

> Just thought it was easier to have that in a library instead... (and if needed, could be adding back in as 2.0 feature along with the array operations and array/function literals and so)

If defined in object.d, then the library hack should do it right now.

> Or do you think we'll have 128 bit CPUs, by the time D is out ?

mmmhhhhhh.....

Thomas

-----BEGIN PGP SIGNATURE-----

iD8DBQFCCChz3w+/yD4P9tIRArywAKCnCChU7dE74KfCc8VOLXuc4cI31ACffaSL
pedf1N3iobN68A3bAMGkIt4=
=C6mW
-----END PGP SIGNATURE-----