Data manipulation
I was reading this post on the net about Data manipulation and it said “programs produce results by manipulating data(writing, changing and reading)” Could someone tell me what they mean by writing, reading and changing? Examples will help alot, Thanks. Also I’m starting out c++ so I wouldn’t understand some of the terms fully. Thanks
Don't over think this one. Its the most basic concept of what a computer program does. For example a program may read a text file off the disk, change a few words, and write it back to disk. But it may also all be in memory... for example the calculator program creates memory to hold its 'data' for a few moments, reads input from the user, computes a value, and writes that value to the screen.
They are trying to explain what a program is in simple terms for you. Most likely you know this intuitively from existing in a computerized society; this looks like stuff that was written way, way, way back when your average person may not have ever seen a computer at all upon entering college.
They are trying to explain what a program is in simple terms for you. Most likely you know this intuitively from existing in a computerized society; this looks like stuff that was written way, way, way back when your average person may not have ever seen a computer at all upon entering college.
With no context (like a link) your question is basically: "Some random human bashed this sequence of keys on a keyboard, possibly with his face. Please explicate." You are far better to read a book and ask questions about it then to ask about comments from random websites. More thought went into the book. It will save you a lot of time.
But let's look at this timeless quote anyway:
"Changing" is repetitive when "reading, writing" will do. Getting rid of some excess verbiage:
To expand a little, perhaps:
He's clearly emphasizing the "reading and writing of data" part (and didn't acutally mention the "programmed sequence" part). He doesn't say what exactly he means by "results", but to keep it simple we can say that the result is the value of some chunk of the data memory when the program stops (the actual "result" from our point of view would be the printing of the value, but that is extraneous detail here).
Well, clearly if the result-chunk of memory didn't originally contain the "result" (which is surely the usual case) then something will need to be "written" into it for the result to appear there. Is that news? Is it a deep insight to note that it may have read other data in order to calculate the new value to write into the result?
It's not really possible to know exactly what the writer meant.
Maybe he means that a calculation can be seen as a sequence of state changes, where the state is the value of all the data in the program. You can imagine the data memory "clicking" from one state to the next, where some quantum of "reading and writing" is done between the clicks. Click, click, from state to state, and when it stops, some chunk of the data memory will contain the answer. (Or maybe every 60th of a second a portion of the data memory could be written to the screen as an image.)
Pure functional programming is somewhat different. It doesn't "read and write data" per se. It sees a calculation as a nested pattern of function calls. In a purely functional program there are no "variables" at all, so in a sense you could say there's no data memory clicking from state to state. But actually the data memory is stored on the stack as the various return values. And of course the entire stack structure is clicking along from state to state. And when it stops, the last returned value is the result.
But let's look at this timeless quote anyway:
| programs produce results by manipulating data (writing, changing and reading) |
"Changing" is repetitive when "reading, writing" will do. Getting rid of some excess verbiage:
| “programs produce results by reading and writing data” |
To expand a little, perhaps:
| programs calculate their results through a programmed sequence of reading and writing data |
He's clearly emphasizing the "reading and writing of data" part (and didn't acutally mention the "programmed sequence" part). He doesn't say what exactly he means by "results", but to keep it simple we can say that the result is the value of some chunk of the data memory when the program stops (the actual "result" from our point of view would be the printing of the value, but that is extraneous detail here).
Well, clearly if the result-chunk of memory didn't originally contain the "result" (which is surely the usual case) then something will need to be "written" into it for the result to appear there. Is that news? Is it a deep insight to note that it may have read other data in order to calculate the new value to write into the result?
It's not really possible to know exactly what the writer meant.
Maybe he means that a calculation can be seen as a sequence of state changes, where the state is the value of all the data in the program. You can imagine the data memory "clicking" from one state to the next, where some quantum of "reading and writing" is done between the clicks. Click, click, from state to state, and when it stops, some chunk of the data memory will contain the answer. (Or maybe every 60th of a second a portion of the data memory could be written to the screen as an image.)
Pure functional programming is somewhat different. It doesn't "read and write data" per se. It sees a calculation as a nested pattern of function calls. In a purely functional program there are no "variables" at all, so in a sense you could say there's no data memory clicking from state to state. But actually the data memory is stored on the stack as the various return values. And of course the entire stack structure is clicking along from state to state. And when it stops, the last returned value is the result.
Last edited on
an example of what? A program? Hello world program... the data is built into th e program (this is not unusual) and then written to the screen. It reads it from memory (where it put it during initialization/load), if you want to get silly about it. Think of any simple real world program, like notepad. What does it do? Why does it exist?
The best way I can help you is to tell you to move on. You are wasting time on this concept, and after your first day of writing your actual beginners programs this idea will be clear. Again, it probably IS clear, deep inside you; these concepts were necessary when computers did not exist in the home commonly and are beyond redundant today.
The best way I can help you is to tell you to move on. You are wasting time on this concept, and after your first day of writing your actual beginners programs this idea will be clear. Again, it probably IS clear, deep inside you; these concepts were necessary when computers did not exist in the home commonly and are beyond redundant today.
Last edited on
| these concepts were necessary when computers did not exist in the home commonly and are beyond redundant today. |
This was my thought exactly.
..and it is a microscopic level, so generalized that it may well describe moving a 'word' of data into a register, another 'word' into a second register, calling the "mul" instruction, then moving the data back to memory point to the result. This is something that happens billions of times per second on modern hardware.
Expressing that instruction sequence as ax = b * c; is a little closer to this side of the 80's.
| You are wasting time on this concept |
I should've just said that.
However, since I'm already babbling, I think I totally misunderstood what the quote-writer meant by "change". Now I think he meant "operate on", or "transform". So he's saying computation is a matter of read, transform, write. Is it true?
Kind of. He seems to be talking about the distinction between RAM and the CPU registers. The CPU reads values into its registers from RAM, operates on them, and writes them back to RAM. It's really a technicality, though. If it was just as fast to operate directly on RAM then presumably that's how it would be. Then the quote devolves into the original quote without the read, change, write part, "programs produce results by manipulating data". Is that an interesting statement?
Last edited on
@dutch I think several of us are arriving at that same basic point - this is a reference to a very mechanical, microscopic view of the machine, one that sounds like it came out of the 50's or 60's.
Technically it rings true, and you've given how, I think I exampled it with a 'mul' instruction, and indeed, we're talking about basic Turing machine stuff.
It may not be all that interesting to most of us today, especially since we're all about writing code that is, to a great extent, far removed from these very basic mechanics (though they are still there under the hood).
Your point "If it was just as fast to operate directly on RAM then presumably that's how it would be" takes me back to the 70's on the 6502 (for those not familiar, that's an old 8 bit processor that didn't have any registers). For that old chip, every byte of RAM was, essentially, it's registers. You'd view it either A) it had no registers or B) all RAM were it's registers.
Even so, signals flowed from RAM into the CPU's circuits to perform the very primitive manipulations it could perform (the CPU did not have a multiply instruction, for example), and when the CPU had the result, it wrote that back to RAM as if that memory were the register.
So...technically it is operating as the OP's quote describes, but at the time it really made sense as a study they were doing good just to get a multiplication completed....we're now about moving cameras, calculating collisions, forces, reverb, color correction, refraction...just, not in the same universe as a perspective on what the machine does to accomplish these things.
Indeed, if you check what the CPU can do, it really doesn't do much anyway. It's all about the basic math operations, moving, comparing, jumping...all of which we hope to ignore from a language perspective.
Technically it rings true, and you've given how, I think I exampled it with a 'mul' instruction, and indeed, we're talking about basic Turing machine stuff.
It may not be all that interesting to most of us today, especially since we're all about writing code that is, to a great extent, far removed from these very basic mechanics (though they are still there under the hood).
Your point "If it was just as fast to operate directly on RAM then presumably that's how it would be" takes me back to the 70's on the 6502 (for those not familiar, that's an old 8 bit processor that didn't have any registers). For that old chip, every byte of RAM was, essentially, it's registers. You'd view it either A) it had no registers or B) all RAM were it's registers.
Even so, signals flowed from RAM into the CPU's circuits to perform the very primitive manipulations it could perform (the CPU did not have a multiply instruction, for example), and when the CPU had the result, it wrote that back to RAM as if that memory were the register.
So...technically it is operating as the OP's quote describes, but at the time it really made sense as a study they were doing good just to get a multiplication completed....we're now about moving cameras, calculating collisions, forces, reverb, color correction, refraction...just, not in the same universe as a perspective on what the machine does to accomplish these things.
Indeed, if you check what the CPU can do, it really doesn't do much anyway. It's all about the basic math operations, moving, comparing, jumping...all of which we hope to ignore from a language perspective.
Topic archived. No new replies allowed.