[M3devel] what to do about file sizes being 32bits?

[hendrik at topoi.pooq.com]

On Sat, Jan 09, 2010 at 08:34:39PM -0600, Rodney M. Bates wrote:
> 
> 
> But the question that creates trouble is not how many bits to store 
> variables
> in, but how many bits to do arithmetic in.  This affects when/whether 
> overflows
> can occur.  I define an overflow as a case where the mathematically correct
> value is, for whatever reason, not what you get.  By "mathematically
> correct", I mean in the system of (unbounded) integers, not a modular 
> arithmetic.
> The usual reason you don't get the correct value is that it won't fit in the
> field you are doing arithmetic in.
> 
> In Modula-3 and with only INTEGER and its subranges, the arithmetic is 
> always
> done in the full range of INTEGER, even if the operands have subrange types.
...
...
> 
> But the size arithmetic is done in is the problem.  The only way to preserve
> the relative tidiness  of the system of subranges would be to have every
> subrange value's representation expanded to the largest size, then do
> the arithmetic in that size.  But this loses the efficiency of native
> arithmetic on _every_ operation, something we just can't afford.
> 
> So INTEGER has to have some special properties that arbitrary subranges
> do not, namely that it is a size arithmetic is done in, if neither operand
> has a larger range.  Having two distinct base types is a lot cleaner
> and less misleading than trying to pretend that INTEGER is just a particular
> case of a subrange.
> 
> This is messy.  But it's about the best we can do, given the difference
> between efficient hardware "integer" arithmetic and the integer arithmetic
> of mathematics.
> 
> Note that you can't fix this by trying to use the value range of where the
> final expression result is to be assigned/passed/whatever.  Then the rules
> just get a whole lot more complicated (for programmer and compiler alike),
> and the cases where overflow can occur get a lot harder to anticipate.  And 
> the
> likelihood they are what is wanted is not good either.  You might have a
> distant chance at this if an expression could have at most one operator,
> but multiple operators and intermediate results make it a tar pit.
> 
> 

GOt that.  INTEGER is not a subrange of LONGINT because its arithmetic 
is different.

And the reason INTEGER has all its restrictions is simply to be 
able to use efficient machine arithmetic, and to make it clear that 
efficient machine arithmetic will be used.  This is why we don't 
expand "every subrange value's representation ... to the largest size, 
then do the arithmetic in that size."

But it is quite possible to performs operation on LONGINT subranges to 
produce results that are as long as necessary to be mathematically 
exact, because the whole point of LONGINT is to use it for numbers that 
do not fit the word size for the most efficient machine arithmetic.  
We're want to use subranges of LONGINT that match the requirements of 
an application, whether those subranges fit the most desirable machine 
word size or not.

-- hendrik