<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
I believe the right statement is:<br> "fixed precision addition is not closed over addition/subtraction/multiplication"<br><br>"closed" meaning the output set is not a subset of the output set.<br><br>Let's just say our integers are 8 bits.<br>The input range is -128..127.<br>The output range however for addition is -256..254.<br>The output range for subtraction is -255..255.<br>(and if I'm slightly off, that's not the point)<br>The output range for mulplication is..well<br>nevermind, I know some of the rules:<br><br> Adding two unsigned integers of n bits yields, worst case, n + 1 bits.<br> Multiplying two unsigned integers of n bits yields, worst case, 2n bits.<br><br>gotta run..<br> - Jay<br><br>> Date: Thu, 7 Jan 2010 22:53:44 -0500<br>> From: hendrik@topoi.pooq.com<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] what to do about file sizes being 32bits?<br>> <br>> On Fri, Jan 08, 2010 at 01:45:03AM +0000, Jay K wrote:<br>> > <br>> > I understand "full range" is a problem, because, something like,<br>> > the set of operations isn't closed.<br>> <br>> What does this mean? What exactly do you mean by "full range"? And <br>> what do you mean by "closed"?<br>> <br>> > <br>> > I believe you need to define multiple types and/or<br>> > multiple operations.<br>> > <br>> > You need an ability to trap/fail on overflow.<br>> > <br>> > You need an ability for silent wraparound on overflow.<br>> > You need perhaps a way to add precision as needed. Slow.<br>> > You need perhaps a way to specify arbitrarily high precision,<br>> > and then, again, either trap/fail or silent wraparound.<br>> > <br>> > Basically, in my opinion, having just "INTEGER" and just "+"<br>> > isn't nearly sufficient.<br>> > <br>> > Not having operator overloading makes pretty much any solution painful to use.<br>> <br>> + is defined on integers and reals. If that's not an overload, why not <br>> have + defined on longint as well?<br>> <br>> > We and C both have a compromise that covers most cases and<br>> > when people really need higher fixed or arbitrary precision, they<br>> > either give up the convenient "operator" syntax or use C++.<br>> > <br>> > <br>> > As I understand, in C, unsigned integers are defined to "silently wraparound"<br>> <br>> The wraparound unsigned integers are extremely useful. The most common <br>> operations, +, *, and - have a clean, well-defined semantics as <br>> arithmetic modulo 2^n. It satisfies a lot of well-known algebraic <br>> identifies.<br>> <br>> Suppose you have an expression involving +, -, * and integers in <br>> 0..2^n - 1 and its correct result is in this 0..2^n - 1 range as well.<br>> If you evaluate it with nonwraparound arithmetic, you may get overflow.<br>> Nonetheless, using wraparound arithmetic under these conditions will <br>> still give the right answer.<br>> <br>> This makes wraparound integers useful for indexing strange arrays with, <br>> say, multiple subscripts in the rante 1000000000..1000000003. <br>> Intermediate results partway through subscript evaluations can overflow <br>> to their hearts' content, and you still get the right element in the <br>> end.<br>> <br>> > <br>> > and signed integers are implementation defined, could "trap" but in reality<br>> > all implementations "silently wraparound".<br>> > It is a point of unsafety though, beyond the more well known<br>> > buffer overflows, leaks, etc.<br>> > <br>> > - Jay<br>> > <br>> > <br>> > > Date: Thu, 7 Jan 2010 19:22:00 -0600<br>> > > From: rodney_bates@lcwb.coop<br>> > > To: m3devel@elegosoft.com<br>> > > Subject: Re: [M3devel] what to do about file sizes being 32bits?<br>> > > <br>> > > Full-range unsigned integers are a language designer's headache, because<br>> > > there are conflicts no matter what you do. The Modula-3 approach is to<br>> > > use the operations in interface Word.i3 (and now Long.i3) on type<br>> > > INTEGER (not CARDINAL, which has only half the range). These apply<br>> > > unsigned interpretation to values of type INTEGER.<br>> <br>> The problem with Word.i3 is that expressions involving these integers <br>> are so unreadable as to be seriously susceptible to error.<br>> <br>> -- hendrik<br> </body>
</html>