James Harris <james.h...@gmail.com
> Simple question: What are the differences between Ada's
> Universal_Integer and a typical bigint type?
> By bigint I mean a signed integer which expands and contracts to be as
> wide as needed.
> I read a comment that one cannot define an Ada object as being of type
> Universal_Integer but I wondered why not. Wouldn't it make sense to have
> Ada programs (or programs in another language, for that matter) treat
> integer constants and expressions as of type bigint?
For Ada there are problems, mostly due to original constraints on
design. For other languages there is no essential problems.
I program every day in Spad, where type 'Integer' is in fact
bigint type. There is also type 'SingleInteger' which represent
machine sized-integers (due to particulars of implementation
range of 'SingleInteger' is slightly smaller than pure machine
> One additional point: In an expression which combines a constant (or
> constant expression) with a declared object the value of the undeclared
> constant expression would be automatically converted. For example, in
> x + 4
> the undeclared bigint 4 would be automatically converted to the type of
> x as long as it was in range.
ATM Spad needs explicit convertion to smaller type.
> Would there be any practical problems with treating integer literals in
> that way?
In general when using integers of differing sizes there is correctness
versus efficiency tradeof. Large types means that there is little
(or no) possibility of overflow. However, when smaller types are
large enough they frequently are much more efficient. Consider
the following Spad function:
f() == max()$SingleInteger + 2
Currently Spad compiler generates code based on result type: if
return type of 'f' is declared as 'Integer' (that is bignum)
Spad compiler generates bignum addition. When return type is
declared as 'SingleInteger', then Spad compiler generates
addition in 'SingleInteger', which will overflow. For this
example Spad rules in fact work resonably well, but in general
it is tricky to decide which type to use (Spad tends to err
on side of correctness and use bignums). In Spad there is
possibilty to manualy choose types, that is you can write:
x +$SingleInteger qconvert(2)@SingleInteger
where '+$SingleInteger' means '+' for type 'SingleInteger' and
'qconvert(2)@SingleInteger' effectively changes type of constant.
Note that Spad in used mostly for mathematical computation
and there is tendecy for users to choose values close to
type limits. So, there is quite nontrivial risk that
addition or multiplication in fixed width type will overflow.