From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,9a441a9594e85d08
X-Google-Attributes: gid103376,public
From: Mats Weber <Mats.Weber@elca-matrix.ch>
Subject: Re: Bignum modular types in Ada95
Date: 1998/01/29
Message-ID: <34D082F9.ABEC0D3B@elca-matrix.ch>#1/1
X-Deja-AN: 320261214
Content-Transfer-Encoding: 7bit
References: <34CE568C.55D7E23D@cl.cam.ac.uk> <34CF3E78.F816DB5@cl.cam.ac.uk>
 <EnIIvn.3zr@world.std.com>
Mime-Version: 1.0
Reply-To: Mats.Weber@elca-matrix.ch
Content-Type: text/plain; charset=us-ascii
Organization: ELCA Matrix SA
Newsgroups: comp.lang.ada
Date: 1998-01-29T00:00:00+00:00
List-Id: <comp.lang.ada>


> No.  Not really.  I guess there's one minor point: there's this thing
> called System.Max_Int, and it has to be some finite integer.  And some
> people write code that uses Max_Int to produce "the largest supported
> signed integer type", and, perhaps, expect that type to be reasonably
> efficient.  It's mainly that the Ada 9X project had no mandate to make
> any such wild-eyed changes.

And there is the fact that parameters of elementary types have to be passed by
copy, something you probably don't want for types with sizes around 1000 bits.

> Every Ada compiler includes a package for arbitrary-range integer
> arithmetic -- it's required, to do static expressions properly at
> compile time.  It's annoying (to me) that this implementation burden is
> required, but the user can't take advantage of it, portably, except in
> the case of static expressions.

I think it's reasonable the way it is (required in the compiler but not in the
runtime) because it's not needed for most applications, and the compiler can
have a quick and dirty, slow implementation that leaks memory without anyone caring.

The implementation, and even the spec of a bignum package is not that easy to
standardize, here are a few problems:

- Allow numbers of any size ? This requires tagged types and finalization,
which costs a lot in performance.

- Are the numbers _really_ big ? In this case, you will implement
multiplication and division using Fourier transforms, which is overkill for
medium size bignums.

- Only integers or reals as well ?

- ...