Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!samsung!crackers!m2c!risky.ecs.umass.edu!dime!chelm.cs.umass.edu!yodaiken
From: yodaiken@chelm.cs.umass.edu (victor yodaiken)
Newsgroups: comp.lang.misc
Subject: Re: The Halting Problem is _not_ solvable on real com
Message-ID: <30739@dime.cs.umass.edu>
Date: 19 May 91 12:07:49 GMT
References: <30505@dime.cs.umass.edu> <30581@dime.cs.umass.edu> <472@smds.UUCP>
Sender: news@dime.cs.umass.edu
Organization: University of Massachusetts, Amherst
Lines: 35

In article <472@smds.UUCP> sw@smds.UUCP (Stephen E. Witham) writes:
>In article <30581@dime.cs.umass.edu>, yodaiken@chelm.cs.umass.edu (victor yodaiken) writes:
>> [some reasonable stuff...]
>> 
>> n = m*m
>>          does the multiplication on a TM, may compute  m*m MOD k
>>          on a FSM
>
>If so, it's because of the compiler, not the machine itself.
>You can compile a program for a regular computer so that the program 
>either computes to whatever precision is needed, or quits.

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.


[Fixed size representations are not necessarily the only reps]
>computers!  They are just a convenience, too.  Thinking that integer 
>variables behave like integers only leads to errors IF you're using a 
>compiler (or a method of programming) that doesn't treat them that way.
>

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.
And, it is also true that compilers can generate "ints" that will cause
the program to quit (or take an execption) if forced beyond machine
representation bounds. But, integers != machine representation of integers.

>Snap out of it, guy!  Was it a momentary lapse, or are the limits of your 
>thinking really so tied to convention?
>

Probably.