Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!samsung!transfer!lectroid!jjmhome!smds!sw
From: sw@smds.UUCP (Stephen E. Witham)
Newsgroups: comp.lang.misc
Subject: Re: The Halting Problem is _not_ solvable on real com
Summary: Why fixed wordlength clouds the issue
Message-ID: <477@smds.UUCP>
Date: 21 May 91 14:01:07 GMT
References: <30505@dime.cs.umass.edu> <30581@dime.cs.umass.edu> <472@smds.UUCP> <30739@dime.cs.umass.edu>
Organization: SMDS Inc., Concord, MA
Lines: 39

In article <30739@dime.cs.umass.edu>, yodaiken@chelm.cs.umass.edu (victor yodaiken) writes:
> 
> Of course, you are correct, but  the point stands. If we have 
> TM machine representable integers, m*n means something different than
> m*n does on an actual computer.
> [...]
> Still, even variable sized representations of integers are not integers.
> I think that you are pointing out that the identification of "int" with
> "representable in one machine word" is often error causing. If so I agree.

Using either of the methods you and I mentioned,
you can write a program, or compile it, so that your "ints" always
act exactly like integers, but sometimes the program can't
go on.  Then the ONLY difference between m*n on two machines 
is that on some (imaginary, infinite) machines, you don't have to say "if 
possible."  

Knowing that a program will either do exactly the right thing, 
or quit, is a useful kind of property for a program to have when you want 
to prove things about it.  In fact, you should insist on it.  If you're 
trying to prove things about programs, then you're really starting off on 
the wrong foot if you let your compiler decide the meaning of your 
programs for you.  You should decide what you want a program to do, THEN
figure out how to write it for the machine(s) and compiler(s) you've got.
Only then can you compare the behavior of (nearly) equivalent programs on
different machines.  A program that has ints falling off the ends of their
ranges at machine-dependent places is probably just WRONG, and not worth
proving much else about. 

The reason for the length of this post is that I'm trying to argue against
a vague target: the attitude that computers doing almost but not quite what 
they are supposed to do is a fact of life that we should all accept and 
learn to live with.  Don't think that way!  Don't take compromise and 
approximation for granted!  The way you spoke of "inherent limitations" 
of computers was getting close to cybercrud: pulling things over on people 
(or yourself) using conventional notions of computers.  

--Steve Witham, sw@smds.UUCP
Not-the-fault-of: SMDS, Inc., Concord, MA