you pointed out very correctly @jolisper. I just tried the code on two different interpreters (DrScheme and MIT-GNU Scheme). At least on these two, the behavior is the similar to what you pointed out. I think it doesn't depend on the interpreter. It most probably has to do with floating point arithmetic. In a machine, floating point numbers are stored in a different format. There is an IEEE standard notation.
So, I think, and I may be wrong:
When you give a natural number x as an argument to sqrt-iter, it will try to computer a y such that y^2 = x (with some error tolerance)...
Mathematically, we know that:
if y^2 = x and x is a natural number -> y will be less than x
so, in whatever format our machine (the hardware) stores the number x, if it can store x, it can also store y (because y < x). our machine will not run out of space. but floating numbers is a different story. there is this fractional part and exponent story (should refer to any article on floating point arithmetic). if i try to manually visualize the computations which might take place for a floating point number...then for any computation that wont stop...the machine is more likely to run out of space. The idea is still vague. Because then rises another question.
when we try to evaluate (sqrt-iter 1 2), after the first iteration the variable guess (inside the definition of sqrt-iter) will not be a natural number any more. Because we will improve our guess by averaging by 2
but then, i must point out that neither it is a floating point number - it is FRACTION and not a floating point number.
i mean, there is a difference between (/ 1 2) and (/ 1 2.) in scheme. the latter gives the answer .5 unlike 1/2 for the first expression.
So, if you change the definition for the average procedure to
(define (average x y)
(/ (+ x y) 2.))
it will behave similarly for natural numbers and floating numbers. (because after the first iteration our guess will be a floating point number always irrespective of what we had before).
Hope that answer some part of the question.