www.digitalmars.com         C & C++   DMDScript  

D - Large integers

reply "Matthew Wilson" <matthew stlsoft.org> writes:
Walter

How hard would it be to support larger than 64-bit integers? It'd be nice to
have arbitrarily large integers, though I expect there are various important
objections to this.

Matthew
Sep 04 2003
next sibling parent reply "DeadCow" <deadcow-remove-this free.fr> writes:
"Matthew Wilson" <matthew stlsoft.org> a écrit dans le message news:
bj7enj$e4m$1 digitaldaemon.com...

 Walter

 How hard would it be to support larger than 64-bit integers? It'd be nice




 have arbitrarily large integers, though I expect there are various




 objections to this.

 Matthew



You mean big interger primitive ? What about implementing it over object
like in java ?

-- Nicolas Repiquet
Sep 04 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 How hard would it be to support larger than 64-bit integers? It'd be







 to

 have arbitrarily large integers, though I expect there are various




 objections to this.

 Matthew



 You mean big interger primitive ? What about implementing it over object
 like in java ?



What about it? (Not sure what your comment means. ;/ )
Sep 04 2003
parent reply "DeadCow" <deadcow-remove-this free.fr> writes:
"Matthew Wilson" <matthew stlsoft.org> a écrit dans le message news:
bj89il$1llr$1 digitaldaemon.com...


 What about it? (Not sure what your comment means. ;/ )



Scuse my english =)

Doesn't something like this suit your needs ? :

class BigInteger {

    private byte[] data;

    BigInteger opadd( ...
    BigInteger opsub( ...

    ...

}


BigInteger a = BigInteger("123140090234823441284120");
BigInteger b = BigInteger("43421394023949342");
BigInteger c = a * b;

....

-- Nicolas Repiquet
Sep 04 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 What about it? (Not sure what your comment means. ;/ )



 Scuse my english =)



No need. Your English is infinitely better than my French. Je suis tres
desole


 Doesn't something like this suit your needs ? :

 class BigInteger {

     private byte[] data;

     BigInteger opadd( ...
     BigInteger opsub( ...

     ...

 }


 BigInteger a = BigInteger("123140090234823441284120");
 BigInteger b = BigInteger("43421394023949342");
 BigInteger c = a * b;



I guess it depends on what I mean by my needs. ;)

I'd like bigger integers to not be heap based, and to look and feel like the
currently supported fundamental integers. However, I recognise that there's
a practical limit to this, which may already have been reached with long.
Sep 04 2003
parent reply Mike Wynn <mike l8night.co.uk> writes:
Matthew Wilson wrote:

What about it? (Not sure what your comment means. ;/ )



Scuse my english =)



 
 No need. Your English is infinitely better than my French. Je suis tres
 desole
 
 

Doesn't something like this suit your needs ? :

class BigInteger {

    private byte[] data;

    BigInteger opadd( ...
    BigInteger opsub( ...

    ...

}


BigInteger a = BigInteger("123140090234823441284120");
BigInteger b = BigInteger("43421394023949342");
BigInteger c = a * b;



 
 I guess it depends on what I mean by my needs. ;)
 
 I'd like bigger integers to not be heap based, and to look and feel like the
 currently supported fundamental integers. However, I recognise that there's
 a practical limit to this, which may already have been reached with long.
 



are usually 512 to 2K bits (64 to 256 bytes) and on some systems (e.g. 
PalmOS) you do not have a large extendable stack space (Palm devices 
have 2K to about 16K [newer do have 32K+]) but may still want RSA/DH etc.
Sep 05 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
 Big Integers are usually heap based for exactly that reason, the sizes
 are usually 512 to 2K bits (64 to 256 bytes) and on some systems (e.g.
 PalmOS) you do not have a large extendable stack space (Palm devices
 have 2K to about 16K [newer do have 32K+]) but may still want RSA/DH etc.



Good point. I confess I've not been seeing past the end of my nose, which,
as it happens, is 256-bits.
Sep 05 2003
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
A lot of grief in the code generator <g>. I think this would be a proper
candidate for a UDT.

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bj7enj$e4m$1 digitaldaemon.com...

 Walter

 How hard would it be to support larger than 64-bit integers? It'd be nice




 have arbitrarily large integers, though I expect there are various




 objections to this.

 Matthew
Sep 04 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 A lot of grief in the code generator <g>. I think this would be a proper
 candidate for a UDT.



Does that apply to larger fixed size integers in addition to arbitrary large
integers? Just giving us 128-bits would be a killer?
Sep 04 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bj8ail$1n3d$1 digitaldaemon.com...

 A lot of grief in the code generator <g>. I think this would be a proper
 candidate for a UDT.



 Does that apply to larger fixed size integers in addition to arbitrary




 integers? Just giving us 128-bits would be a killer?



With 64 bit registers, it would be trivial. With register quads, though,
it's a significant problem.
Sep 04 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Most machines these days have 64-bit integer registers available with which
one could easily fake 128-bit math using tricks as old as computers.

I thought you were going to implement the cent data type at some point?  I
suppose it's not all that important... we can manage.  ;)

The big problem with doing emulated math on the user code side is handling
carry and overflow can only really be done from assembler.  Or do you think
D might provide some standard intrinsics for these operations that return a
pair of an int and a carry bit?

Sean

"Walter" <walter digitalmars.com> wrote in message
news:bj8cj8$1q3g$1 digitaldaemon.com...

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bj8ail$1n3d$1 digitaldaemon.com...

 A lot of grief in the code generator <g>. I think this would be a










 candidate for a UDT.



 Does that apply to larger fixed size integers in addition to arbitrary




 integers? Just giving us 128-bits would be a killer?



 With 64 bit registers, it would be trivial. With register quads, though,
 it's a significant problem.
Sep 05 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bj9fac$bnt$1 digitaldaemon.com...

 Most machines these days have 64-bit integer registers available with




 one could easily fake 128-bit math using tricks as old as computers.



Not the x86.


 I thought you were going to implement the cent data type at some point?  I
 suppose it's not all that important... we can manage.  ;)



Yes, but at the moment it is just sort of reserving the keyword.


 The big problem with doing emulated math on the user code side is handling
 carry and overflow can only really be done from assembler.  Or do you




 D might provide some standard intrinsics for these operations that return




 pair of an int and a carry bit?



D does have a nice inline assembler <g>.
Sep 05 2003
next sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 Most machines these days have 64-bit integer registers available with




 one could easily fake 128-bit math using tricks as old as computers.



 Not the x86.



I think it might be easy to support a subset of operations for any large
integer of either defined size or automatically computed size. We might
have some restriction for some operations like we might require support
for division only by "small" integer (32 bits or less)


 I thought you were going to implement the cent data type at some point?







 suppose it's not all that important... we can manage.  ;)



 Yes, but at the moment it is just sort of reserving the keyword.


 The big problem with doing emulated math on the user code side is







 carry and overflow can only really be done from assembler.  Or do you




 D might provide some standard intrinsics for these operations that







 a

 pair of an int and a carry bit?



 D does have a nice inline assembler <g>.
Sep 05 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bj9ha6$eff$2 digitaldaemon.com...

 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bj9fac$bnt$1 digitaldaemon.com...

 Most machines these days have 64-bit integer registers available with




 one could easily fake 128-bit math using tricks as old as computers.



 Not the x86.



True enough.


 The big problem with doing emulated math on the user code side is







 carry and overflow can only really be done from assembler.  Or do you







 D might provide some standard intrinsics for these operations that







 pair of an int and a carry bit?



 D does have a nice inline assembler <g>.



That guarantees you won't be portable.

I'd rather have something that guarantees you will be.  I guess it's not a
big deal.

Sean
Sep 06 2003
parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bjcv3p$2chk$1 digitaldaemon.com...

 "Walter" <walter digitalmars.com> wrote in message

 D does have a nice inline assembler <g>.






You'll be portable among all the x86 platforms, which is far better than
using inline assembler with C++.


 I'd rather have something that guarantees you will be.  I guess it's not a
 big deal.



I don't think adding the primitives in the language will help much in
writing multiprecision arithmetic. To get decent results, inline asm will
still be needed.
Sep 15 2003
prev sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
whats udt ?

"Walter" <walter digitalmars.com> wrote in message
news:bj89ai$1l9g$1 digitaldaemon.com...

 A lot of grief in the code generator <g>. I think this would be a proper
 candidate for a UDT.

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bj7enj$e4m$1 digitaldaemon.com...

 Walter

 How hard would it be to support larger than 64-bit integers? It'd be







 to

 have arbitrarily large integers, though I expect there are various




 objections to this.

 Matthew
Sep 04 2003
next sibling parent "Walter" <walter digitalmars.com> writes:
User defined type. Such as std::complex in C++.

"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bj8d44$1qvo$1 digitaldaemon.com...

 whats udt ?

 "Walter" <walter digitalmars.com> wrote in message
 news:bj89ai$1l9g$1 digitaldaemon.com...

 A lot of grief in the code generator <g>. I think this would be a proper
 candidate for a UDT.

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bj7enj$e4m$1 digitaldaemon.com...

 Walter

 How hard would it be to support larger than 64-bit integers? It'd be







 to

 have arbitrarily large integers, though I expect there are various




 objections to this.

 Matthew
Sep 04 2003
prev sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
User defined type

"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bj8d44$1qvo$1 digitaldaemon.com...

 whats udt ?

 "Walter" <walter digitalmars.com> wrote in message
 news:bj89ai$1l9g$1 digitaldaemon.com...

 A lot of grief in the code generator <g>. I think this would be a proper
 candidate for a UDT.

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bj7enj$e4m$1 digitaldaemon.com...

 Walter

 How hard would it be to support larger than 64-bit integers? It'd be







 to

 have arbitrarily large integers, though I expect there are various




 objections to this.

 Matthew
Sep 04 2003
prev sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
I'm a big fan of gmp: http://www.swox.com/gmp/
It probably wouldn't be too hard to create a D wrapper for the library since
it is pure C code. Hmmm... I sense another D project coming on.

-Ben

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bj7enj$e4m$1 digitaldaemon.com...

 Walter

 How hard would it be to support larger than 64-bit integers? It'd be nice




 have arbitrarily large integers, though I expect there are various




 objections to this.

 Matthew
Sep 05 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
Ben

I think you should do as you suggest, ;). It would be great.

btw, do you know whether the performance of GMP is good?

Matthew

"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:bjbd5e$1e8$1 digitaldaemon.com...

 I'm a big fan of gmp: http://www.swox.com/gmp/
 It probably wouldn't be too hard to create a D wrapper for the library




 it is pure C code. Hmmm... I sense another D project coming on.

 -Ben

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bj7enj$e4m$1 digitaldaemon.com...

 Walter

 How hard would it be to support larger than 64-bit integers? It'd be







 to

 have arbitrarily large integers, though I expect there are various




 objections to this.

 Matthew
Sep 05 2003