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

[Jay K]

I believe the right statement is:
  "fixed precision addition is not closed over addition/subtraction/multiplication"

"closed" meaning the output set is not a subset of the output set.

Let's just say our integers are 8 bits.
The input range is -128..127.
The output range however for addition is -256..254.
The output range for subtraction is -255..255.
(and if I'm slightly off, that's not the point)
The output range for mulplication is..well
nevermind, I know some of the rules:

  Adding two unsigned integers of n bits yields, worst case, n + 1 bits.
  Multiplying two unsigned integers of n bits yields, worst case, 2n bits.

gotta run..
 - Jay

> Date: Thu, 7 Jan 2010 22:53:44 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what to do about file sizes being 32bits?
> 
> On Fri, Jan 08, 2010 at 01:45:03AM +0000, Jay K wrote:
> > 
> > I understand "full range" is a problem, because, something like,
> > the set of operations isn't closed.
> 
> What does this mean?  What exactly do you mean by "full range"?  And 
> what do you mean by "closed"?
> 
> > 
> > I believe you need to define multiple types and/or
> > multiple operations.
> > 
> > You need an ability to trap/fail on overflow.
> > 
> > You need an ability for silent wraparound on overflow.
> > You need perhaps a way to add precision as needed. Slow.
> > You need perhaps a way to specify arbitrarily high precision,
> >   and then, again, either trap/fail or silent wraparound.
> > 
> > Basically, in my opinion, having just "INTEGER" and just "+"
> > isn't nearly sufficient.
> > 
> > Not having operator overloading makes pretty much any solution painful to use.
> 
> + is defined on integers and reals.  If that's not an overload, why not 
> have + defined on longint as well?
> 
> > We and C both have a compromise that covers most cases and
> > when people really need higher fixed or arbitrary precision, they
> > either give up the convenient "operator" syntax or use C++.
> >  
> > 
> > As I understand, in C, unsigned integers are defined to "silently wraparound"
> 
> The wraparound unsigned integers are extremely useful.  The most common 
> operations, +, *, and - have a clean, well-defined semantics as 
> arithmetic modulo 2^n.  It satisfies a lot of well-known algebraic 
> identifies.
> 
> Suppose you have an expression involving +, -, * and integers in 
> 0..2^n - 1 and its correct result is in this 0..2^n - 1 range as well.
> If you evaluate it with nonwraparound arithmetic, you may get overflow.
> Nonetheless, using wraparound arithmetic under these conditions will 
> still give the right answer.
> 
> This makes wraparound integers useful for indexing strange arrays with, 
> say, multiple subscripts in the rante 1000000000..1000000003.  
> Intermediate results partway through subscript evaluations can overflow 
> to their hearts' content, and you still get the right element in the 
> end.
> 
> > 
> > and signed integers are implementation defined, could "trap" but in reality
> > all implementations "silently wraparound".
> > It is a point of unsafety though, beyond the more well known
> > buffer overflows, leaks, etc.
> > 
> >  - Jay
> > 
> >  
> > > Date: Thu, 7 Jan 2010 19:22:00 -0600
> > > From: rodney_bates at lcwb.coop
> > > To: m3devel at elegosoft.com
> > > Subject: Re: [M3devel] what to do about file sizes being 32bits?
> > > 
> > > Full-range unsigned integers are a language designer's headache, because
> > > there are conflicts no matter what you do. The Modula-3 approach is to
> > > use the operations in interface Word.i3 (and now Long.i3) on type
> > > INTEGER (not CARDINAL, which has only half the range). These apply
> > > unsigned interpretation to values of type INTEGER.
> 
> The problem with Word.i3 is that expressions involving these integers 
> are so unreadable as to be seriously susceptible to error.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/0397073c/attachment-0002.html>