• Matthew Wilson (5/5) Sep 04 2003 Walter
• DeadCow (7/12) Sep 04 2003 to
• Matthew Wilson (2/11) Sep 04 2003 What about it? (Not sure what your comment means. ;/ )
• DeadCow (15/16) Sep 04 2003 Scuse my english =)
• Matthew Wilson (6/18) Sep 04 2003 I guess it depends on what I mean by my needs. ;)
• Mike Wynn (5/39) Sep 05 2003 Big Integers are usually heap based for exactly that reason, the sizes
• Matthew Wilson (2/6) Sep 05 2003 Good point. I confess I've not been seeing past the end of my nose, whic...
• Walter (6/11) Sep 04 2003 A lot of grief in the code generator . I think this would be a proper
• Matthew Wilson (2/4) Sep 04 2003 Does that apply to larger fixed size integers in addition to arbitrary l...
• Walter (5/9) Sep 04 2003 large
• Sean L. Palmer (12/22) Sep 05 2003 Most machines these days have 64-bit integer registers available with wh...
• Walter (8/16) Sep 05 2003 which
• Philippe Mori (7/21) Sep 05 2003 I think it might be easy to support a subset of operations for any large
• Sean L. Palmer (10/21) Sep 06 2003 True enough.
• Walter (7/12) Sep 15 2003 You'll be portable among all the x86 platforms, which is far better than
• Charles Sanders (4/19) Sep 04 2003 whats udt ?
• Walter (3/25) Sep 04 2003 User defined type. Such as std::complex in C++.
• Matthew Wilson (3/25) Sep 04 2003 User defined type
• Ben Hinkle (8/13) Sep 05 2003 I'm a big fan of gmp: http://www.swox.com/gmp/
• Matthew Wilson (8/25) Sep 05 2003 Ben

"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

"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

to
 have arbitrarily large integers, though I expect there are various

important
 objections to this.

 Matthew

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

-- Nicolas Repiquet

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

 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

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

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

"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

"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.

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.
 

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.

"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.

"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

to
 have arbitrarily large integers, though I expect there are various

important
 objections to this.

 Matthew

"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?

"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

large
 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.

"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



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?

 With 64 bit registers, it would be trivial. With register quads, though,
 it's a significant problem.

"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

which
 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

think
 D might provide some standard intrinsics for these operations that return

a
 pair of an int and a carry bit?

D does have a nice inline assembler <g>.

"Philippe Mori" <philippe_mori hotmail.com> 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.

 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?


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

 think
 D might provide some standard intrinsics for these operations that


return
 a
 pair of an int and a carry bit?

 D does have a nice inline assembler <g>.

"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

 which
 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


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?

 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

"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>.

 That guarantees you won't be portable.

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.

"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


nice
 to
 have arbitrarily large integers, though I expect there are various

 important
 objections to this.

 Matthew

"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


 nice
 to
 have arbitrarily large integers, though I expect there are various

 important
 objections to this.

 Matthew

"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


 nice
 to
 have arbitrarily large integers, though I expect there are various

 important
 objections to this.

 Matthew

"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

to
 have arbitrarily large integers, though I expect there are various

important
 objections to this.

 Matthew

"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

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
 to
 have arbitrarily large integers, though I expect there are various

 important
 objections to this.

 Matthew