Dalek Prime wrote:I understand you. But null/nil is a constant, not a variable, just to mention. Note I'm speaking from a Lisp perspective.
Yes, this is used to end a data string with characters though, not regular numbers. When a string is accessed, it looks up the address where the string of data is located. Because character ASCII symbol assigns NUL to '0' in binary, any non-zero numbers listed refer to a character. The NUL at the end tells a program when to quit.
Pseudo-code Example:
Definition and data:
String -> "Colors" = (72, 105, 0)
Instruction code:
1) Let x = 0
2) If "color"[x] = 0 (or NUL) go to step 6
3) Print x
4) x = x + 1
5) Go to step (2)
6) End program.
Yes, though encoding nil/null as binary 0 is arbitrary (though perfectly reasonable). It could be any number. Anyways, I'm just saying that it's an advance.
Just to mention, nil performs multiple duties in common lisp. Falsehood, empty list, end of list, etc. Scheme, for some stupid reason, does not equate the empty list with nil, and uses #f for falsehood. Go figure.
Hobbes' Choice wrote:
I did not mention "all these operations". You use of English is limited I know.
Nevertheless. I'll let that go.
Maybe you were not listening in history?
Maybe you never heard of an ABACUS? A good operator of an abacus can do all those operations faster than a pocket calculator.
They were invented in Mesopotamia in the third millennium BC (or maybe even earlier) and initially employed the sexagesimal system. There never was a need for a zero as that was implied by an empty row of beads.
The builders square is one good contender for the greatest advance in Maths, the Abacus is another great contender, as it enabled calculations at great speed without a zero for thousands of years.
Once you know how to use one, you can then do without one and employ imagination with a "MENTAL ABACUS"
It's only our familiarity with decimal columns using a null position that makes us think that zero is so important. People have got along with other methods for thousands of years before with no problems.
A computer can do these operations faster than an abacus operator (using a 0 btw). Can an abacus operator keep up against a computer, with or without a zero?
PhilX
The abacus is a computer. Are you offering the electronic computer as the greatest advance in maths, or what?
Dalek Prime wrote:
Instruction code:
1) Let x = 0
2) If "color"[x] = 0 (or NUL) go to step 6
3) Print x
4) x = x + 1
5) Go to step (2)
6) End program.:
This program does not work BTW.
But I'll pretend it does.
Now rather than have start start with 0, have it start with 1. and make the conditional statement in 2 read "If colour(x) = 1 then goto 6.
You will have exactly the same algorithm, with no use of the character 0.
Hobbes' Choice wrote:
I did not mention "all these operations". You use of English is limited I know.
Nevertheless. I'll let that go.
Maybe you were not listening in history?
Maybe you never heard of an ABACUS? A good operator of an abacus can do all those operations faster than a pocket calculator.
They were invented in Mesopotamia in the third millennium BC (or maybe even earlier) and initially employed the sexagesimal system. There never was a need for a zero as that was implied by an empty row of beads.
The builders square is one good contender for the greatest advance in Maths, the Abacus is another great contender, as it enabled calculations at great speed without a zero for thousands of years.
Once you know how to use one, you can then do without one and employ imagination with a "MENTAL ABACUS"
It's only our familiarity with decimal columns using a null position that makes us think that zero is so important. People have got along with other methods for thousands of years before with no problems.
A computer can do these operations faster than an abacus operator (using a 0 btw). Can an abacus operator keep up against a computer, with or without a zero?
PhilX
The abacus is a computer. Are you offering the electronic computer as the greatest advance in maths, or what?
I really don't count the abacus as a computer because it's not an electronic device.
Philosophy Explorer wrote:
A computer can do these operations faster than an abacus operator (using a 0 btw). Can an abacus operator keep up against a computer, with or without a zero?
PhilX
The abacus is a computer. Are you offering the electronic computer as the greatest advance in maths, or what?
I really don't count the abacus as a computer because it's not an electronic device.
Dalek Prime wrote:
Instruction code:
1) Let x = 0
2) If "color"[x] = 0 (or NUL) go to step 6
3) Print x
4) x = x + 1
5) Go to step (2)
6) End program.:
This program does not work BTW.
But I'll pretend it does.
Now rather than have start start with 0, have it start with 1. and make the conditional statement in 2 read "If colour(x) = 1 then goto 6.
You will have exactly the same algorithm, with no use of the character 0.
Hence zero is not relevant here.
I agree and why I was responding. I should have used this but was being fair to how most computer programmers usually begin with the x = 0. For a computer, the hardware doesn't have to assign zero to a memory space already assumed empty and so it saves a command to load a charge (a '1') there. But it is the second use of '0' in (2) that Dalek was referring to not the value of x from the first that we are discussing only.
P.S. Why did you presume the program not to work BTW? beginning with x=1 depends on the particular programming language. Maybe you're only used to programming where the first of an array is defaulted to '1' rather than '0'?
NOTDalek Prime wrote:
Instruction code:
1) Let x = 0
2) If "color"[x] = 0 (or NUL) go to step 6
3) Print x
4) x = x + 1
5) Go to step (2)
6) End program.:
This program does not work BTW.
But I'll pretend it does.
Now rather than have start start with 0, have it start with 1. and make the conditional statement in 2 read "If colour(x) = 1 then goto 6.
You will have exactly the same algorithm, with no use of the character 0.
Hence zero is not relevant here.
I agree and why I was responding. I should have used this but was being fair to how most computer programmers usually begin with the x = 0. For a computer, the hardware doesn't have to assign zero to a memory space already assumed empty and so it saves a command to load a charge (a '1') there. But it is the second use of '0' in (2) that Dalek was referring to not the value of x from the first that we are discussing only.
P.S. Why did you presume the program not to work BTW? beginning with x=1 depends on the particular programming language. Maybe you're only used to programming where the first of an array is defaulted to '1' rather than '0'?
Actually Harddrives that comprise the vast majority of computer memory storage require no charge to store data, else they would need continual power, which they do not. 1 and zeros are nominal only and are represented by different steady states, set or not set - this makes the difference between 1 and zero as completely arbitrary.
I'd tell you why the program does not work if you tell me in English what you want it to do, and in what language it is written. Obviously it looks like BASIC but line 2 does not make sense. If you take it that x=0 the program would always end immediately it was run: x being one would return a nul to the "colour(x)" condition and THEN line 6. The rest of the program is redundant.
It's been a whilst since I programmed, but I think I'm right.
Last edited by Hobbes' Choice on Wed Jul 29, 2015 4:46 pm, edited 1 time in total.
Scott Mayers wrote:
Instruction code:
1) Let x = 0
2) If "color"[x] = 0 (or NUL) go to step 6
3) Print x
4) x = x + 1
5) Go to step (2)
6) End program.:
...
P.S. Why did you presume the program not to work BTW? beginning with x=1 depends on the particular programming language. Maybe you're only used to programming where the first of an array is defaulted to '1' rather than '0'?
Actually Harddrives that comprise the vast majority of computer memory storage require no charge to store data, else they would need continual power, which they do not. 1 and zeros are nominal only and are represented by different steady states, set or not set - this makes the difference between 1 and zero as completely arbitrary.
I'd tell you why the program does not work if you tell me in English what you want it to do, and in what language it is written. Obviously it looks like BASIC but line 2 does not make sense. If you take it that x=0 the program would always end immediately it was run: x being one would return a nul to the "colour(x)" condition and THEN line 6. The rest of the program is redundant.
It's been a whilst since I programmed, but I think I'm right.
I was using pseudocode which just means a rough layout in English to plan a program regardless of any particular language. You're confusing the value of 'x' with the value of color[x]. "color[x]" means the value of the data at the position of 'x' in the order the data is listed. Computers just assign the first value of a list as zero usually, especially in assembly language. In the example above, the first color[0] = 72, not '0'. And the next value of x becomes '1', which is color[1] = 105, and then color[2] = 0 which then tells you to go to step 6 to get out of the loop. So it does work.
EDIT: Line (3), however, should be corrected to Print color[x], not x. So you're still correct that my program code would have been in error without fixing that when transferring it into actual code.
