Arcane Jill wrote:

> I have placed source code for "etc.bigint", a module and package for manipulated
> unlimited precision integers, online at:
> 
> http://www.fast-forward.info/ramonsky/stuff/d/bigint.html
<snip>

1. "Construct an Int having the value value. This is a copy constructor. It copies by value, not by reference."

You seem to indicate that Int objects are immutable.  In that case, why bother with the copy constructor and dup method?

2. You have overloaded operators for combining with int and uint.  Why not long and ulong?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

In article <c9i0d5$12or$1@digitaldaemon.com>, Stewart Gordon says...

>1. "Construct an Int having the value value. This is a copy constructor. It copies by value, not by reference."
>
>You seem to indicate that Int objects are immutable.  In that case, why bother with the copy constructor and dup method?

Err... you've got me there. Historical reasons, I guess. I think some of the lib code may need to use that constructor internally, and there seemed little point in making it private. Maybe it would be ok to remove that at this stage, but I'd have to think hard before taking that step in case it broke anything.

But you're right. Public calls will almost certainly never need it.



>2. You have overloaded operators for combining with int and uint.  Why not long and ulong?

No reason. I just forgot. But it's never too late to add them.

Also missing are constructors from float, double and real, for much the same reason. They, too, can be added in the future. (Also, it will be dsourced in a couple of days, so it will be easier for other people to add anything I've missed out.)

Jill

>Will fix tonight.

Fixed and uploaded.

Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c99o8r$1p31$1@digitaldaemon.com...
> In article <c99nfj$1nrf$1@digitaldaemon.com>, J Anderson says...
>
> >Why was big int made a class? Why not a struct?
>
> 1. Ease of initialization. a = new Int(5); is better than Int a;
a.init(5);
>
> 2. Most importantly (to me). Only classes can have a destructor. In a
> version(Secure) build, the destructor wipes the memory which held the
Int's
> value. This is important in cryptography, since big integers may hold cryptographic keys, etc., and you don't want those values lying around in
memory
> indefinitely. (In a non version(Secure), there is no destructor, of
course).

Since the GC is allowed to move memory around (even though the current implementation does not) in order to do compaction, wiping memory on a delete is not reliable. I suggest it would be better to allocate the secure array using std.c.stdlib.malloc, and then when explicitly free'ing it with std.c.stdlib.free, do the wipe. That way you'll be in complete control of any copies.

There's still another problem, though. D's GC does not *guarantee* that destructors will get run for non-auto objects. Therefore, you might want to keep a list of all the secure arrays created that haven't been wiped yet, then on program close with a module destructor, go through the list and wipe any remaining ones.

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c9hatr$3pd$1@digitaldaemon.com...
> PS. TEMPORARY WORKAROUND - I suspect that if you build with version(DisableKaratsuba) the problem may go away. Disallowing the more
complex
> (but possibly faster) Karatsuba multiplication algorithm forces the lib to
use
> classical long-multiplication, which is much simpler, and unlikely to be
buggy.

This sounds like a job for DbC! I suggest adding an 'out' postcondition for the Karatsuba algorithm. In that postcondition, do the classical multiplication, then assert that the results match. For debug builds, this will be a great confidence builder in making sure the more complex code is right.

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c9bu8h$1oi8$1@digitaldaemon.com...
> In article <c9a37n$282p$1@digitaldaemon.com>, Ivan Senji says...
> >int main(char[][] args)
> >{
> >    Int n= new Int("123456");
> >    printf("n = %.*s",n.toString);
> >}
> >and it prints:
> >n = 23456
> You are correct. It's a bug. I just reproduced it. I will fix it and add
that
> one to the unit tests. Will let you know when it's done.

Can I suggest another use for DbC? In the toString() function, add an 'out' postcondition which converts back to an int. Assert that it matches the original int.

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c9cu9v$1pu$1@digitaldaemon.com...
> See - although I can /use/ makefiles, I always seem to get them wrong when
I try
> to hand craft them, no matter how many times I read through the man page.

Don't feel bad, NOBODY learns how to write makefiles by reading the man page. The usual way is to take an existing makefile and hack away at it to make it work for a new project. Incidentally, this is why makefiles tend to be unreadable horrors.

I suspect that make was never designed, it was hacked together in a weekend by some programmer who never thought much about it <g>.

In article <c9l5vg$2ljv$2@digitaldaemon.com>, Walter says...
>
>This sounds like a job for DbC! I suggest adding an 'out' postcondition for the Karatsuba algorithm. In that postcondition, do the classical multiplication, then assert that the results match. For debug builds, this will be a great confidence builder in making sure the more complex code is right.

I'm ahead of you there. My class has made that test all along. The reported bug (which I've actually fixed now) was detected by a DbC assert - though not that one, as one of the lower-level functions asserted in the middle of executing the Karatsuba algorithm. Thanks to you, my friend, it was possible to isolate this error and fix it very fast.

This class is well and truly DbC'ed. The out conditions really do test whether the answer is right wherever it can, for as many functions as possible.

For this reason, of course, the (theoreticaly faster) Karatsuba algorithm is actually much /slower/ in a debug build, because it calls the classical algorithm to check whether it got the answer right! Only in a release build could it actually be faster.

Jill

In article <c9l6gn$2mcm$1@digitaldaemon.com>, Walter says...


>Can I suggest another use for DbC? In the toString() function, add an 'out' postcondition which converts back to an int. Assert that it matches the original int.

Now that's one I missed! Well spotted. Ok - will add that one sometime soon.

Jill

On Sat, 29 May 2004 09:58:23 +0000 (UTC), Arcane Jill wrote:

> I have placed source code for "etc.bigint", a module and package for manipulated unlimited precision integers, online at:
> 
> http://www.fast-forward.info/ramonsky/stuff/d/bigint.html
> 
> (PS. I found it mildly inconvenient that I had to put supporting files in directory "etc/bigint_files/" instead of "etc/bigint/", because D wouldn't let me have a module and a directory with the same path).
> 
> There is no binary - it's "build-it-yourself". But there /is/ documentation.
> 
> Over the next few days I'll try to get this also copied onto dsource (maybe even with a binary this time, who knows?)
> 
> By the way - how does one persuade the dmd linker to produce a library? Probably a dumb question I know, but I always just linked everything against main to get an executable.
> 
> Arcane Jill

I am *so* impressed! This is an excellent piece of work. Well done indeed. I can't wait for the crypto stuff as this is also an area that I work in.

I'm also a bit slow ;-) Can you give me the "for Dummies" explanation of why a+=b is not allowed? In my humble brain

   a += b;

is syntax sugar for

   a = a + b;

so what am I missing here?

-- 
Derek
3/Jun/04 11:22:48 AM