All numbers are imagined.
But it is still not a property of the number.But as I've pointed out elsewhere, C isn't Turing completeYou can determine halting of all those C programs with another program of sufficient power, since each C program is effectively a very very large state machine.
Plenty of languages are Turing complete though, and any of those works for your argument.
Sure it is; no you can't; no it isn't. I took precautions on that point: "If sequence N is a legal C program that contains a command to read any input other than a file the program wrote itself, bit N is 0." A C program in a typical implementation can't address more than 267 bits in memory, and any implementation will be limited to some number of bits, but there's no reason this restriction has to also apply to files. If a C program needs more data than that, it will have to save some of it to a file and subsequently read the file back in until it gets to the data it needs to recover; but there's nothing in the C language to bar it from doing so. Of course a typical C run-time system doesn't support files that large, but that's not part of the language either. You could perfectly well build a C run-time system that supports arbitrarily large files. Whenever such a run-time system runs out of disk space obeying a file write instruction, it interrupts the program, copies to mag tape the part of the file it already wrote to disk, frees the disk space, instructs the operator to remove the mag tape and replace it with a blank tape, and resumes execution of the program. As far as the program itself can tell, nothing out of the ordinary just happened. (It will of course be the operator's thankless task to keep track of which order all the mag tapes filling all the warehouses on all the planets in his intergalactic empire go in.But as I've pointed out elsewhere, C isn't Turing complete
)
Yes we are.
We are discussing an infinite series that can abstractly be thought of as existing within a set.
The infinite series is still there.
The elements without end are still there.
And to translate the set to something real would require every element of the infinite series being expressed.
That this is news to you just proves what a waste of my time you are.
we've been there before...
You had all the time to explain yourself and you haven't. Countless people have died trying to get you to articulate something cogent. You're parroting yourself ad libitum. Nauseating. You never produce anything like an argument, a piece of knowledge, or even a piece of your own expertise. You're just parroting yourself without a fail. You have one absurd belief that infinity doesn't exist in the physical word and you have no proof whatsoever. You're only argument is to claim that the word "infinite" means without end, which is no even true, and if it was, it would still be an idiotic argument. It's a bit short to argue that infinity doesn't exist. You're attention span also is very short. No way anyone can have a rational debate with you. It always ends up in the same litany of your deadbeat mantra that an infinite past is impossible because "it would never complete".
EB
What are you talking about? I didn't apply the distributive principle in that step. That step merely replaces a subexpression of the equation with an equal expression. I took out "9/10 + 9/100 + 9/1000 + ..." and put "x" in its place, which is a legitimate operation because those expressions are equal to each other according to an earlier step in the proof. Structurally speaking, Line 1 says "A = B", and Line 3 says "C = D + B", and Line 4 says "Therefore, C = D + A", and you're calling foul. What gives?
What are the file semantics? Are you sure that file-descriptor isn't for a network port? Send over n 1s and a 0, and the oracle on the other side just tells you whether the nth element of a predefined enumeration of lambda terms has a normal form.Sure it is; no you can't; no it isn't. I took precautions on that point: "If sequence N is a legal C program that contains a command to read any input other than a file the program wrote itself, bit N is 0." A C program in a typical implementation can't address more than 267 bits in memory, and any implementation will be limited to some number of bits, but there's no reason this restriction has to also apply to files. If a C program needs more data than that, it will have to save some of it to a file and subsequently read the file back in until it gets to the data it needs to recover; but there's nothing in the C language to bar it from doing so. Of course a typical C run-time system doesn't support files that large, but that's not part of the language either. You could perfectly well build a C run-time system that supports arbitrarily large files. Whenever such a run-time system runs out of disk space obeying a file write instruction, it interrupts the program, copies to mag tape the part of the file it already wrote to disk, frees the disk space, instructs the operator to remove the mag tape and replace it with a blank tape, and resumes execution of the program. As far as the program itself can tell, nothing out of the ordinary just happened. (It will of course be the operator's thankless task to keep track of which order all the mag tapes filling all the warehouses on all the planets in his intergalactic empire go in.But as I've pointed out elsewhere, C isn't Turing complete
Why do you think "has a binary expansion that can't be computed by any computation process because any such process would imply a contradiction" doesn't qualify as a mathematical property of L? There's more to mathematics than differential equations. Reductio ad absurdum proofs have been part of math a lot longer than real numbers.
Heh.What are the file semantics? Are you sure that file-descriptor isn't for a network port? Send over n 1s and a 0, and the oracle on the other side just tells you whether the nth element of a predefined enumeration of lambda terms has a normal form.
To make this rigorous we'd have to define restrictive file semantics simple enough to verify compliance syntactically. What I had in mind was getc, putc, fclose, and fopen on a fixed set of literal file names which all have to be fopened for write (not append!) before they can be fopened for read. That should be enough to emulate a Turing machine tape but not enough to talk to an oracle. For reasonable efficiency we could add fseek, with a prohibition against seeking beyond end-of-file.Its s computational property. Not a number property.
Can you clarify? I can't tell which of my statements you intend that to contradict.
I wasn't trying to get a change in magnitude; I was trying to establish what the magnitude already was. If you're arguing that my proof is wrong because my steps can't change the magnitude from .999... to 1, then you're making a circular argument -- you're assuming your conclusion that they're different as a premise.
Never; but what has that to do with our discussion? I'm doing algebra, not computer programming. In my proof x isn't the name of a register that starts at .9 and then gets overwritten with progressively larger numbers; x is one fixed number that never changes, "0.999...", and I'm trying to find out what number that is, just as if I started a proof with "y = 2 + 3".
What is your criterion for classifying a property as a "number property" or a "computational property"?
No, that's not what it says. It doesn't say a word about infinite results. When a real number is "computable", that means there exists a finite algorithm that takes in a finite positive integer N as input, runs in a finite time, outputs the Nth digit of the number's expansion in some number base, and stops. No infinity involved. (Which number base it is doesn't matter. If there's an algorithm for base 2 digits then there's also an algorithm for base 97 digits, and vice versa.)
convergent series. Finally, it's all just another form of Zeno's paradox: if you sequentially cross 90% of the remaining interval, you ultimately cover the entire interval just as you do if you sequentially cover half the remaining interval.
