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

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.

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

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

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.

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

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

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

"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

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