[M3devel] what to do about file sizes being 32bits?
Jay K
jay.krell at cornell.edu
Fri Jan 8 07:41:09 CET 2010
[truncated again, I have a knack for
aiming near 80 columns and therefore getting
the period right where the mail software truncates..]
From: jay.krell at cornell.edu
To: hendrik at topoi.pooq.com; m3devel at elegosoft.com
Subject: RE: [M3devel] what to do about file sizes being 32bits?
Date: Fri, 8 Jan 2010 06:07:08 +0000
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/ae9ef910/attachment-0002.html>
More information about the M3devel
mailing list