User:Kinkreet/Computing

Where to start?

Hi all,

I am looking to learn about computing, especially how computers turn the 0's and 1's into, say texts and images. So 00110100 equals 52, but what in the computer turns 00110100 into 52 and not for it to remain as a string of 0's and 1's? I read a little about the HEX editor, but can anyone tell me how it works? A Hex editor itself on the computer is still only 0's and 1's right? Many thanks, Kinkreet^{~♥moshi moshi♥~} 09:36, 21 February 2013 (UTC)

That 00110100 is a number; you can represent it as 52, as 42 in octal, as 2A in hex, as the ASCII character '*', as a colour, or a little snippet of sound, and so on. When you go to display it, or print it, or listen to it, then some circuitry, and/or some software, changes it from one representation to another. There's a lot of representations, and a lot of operations you can do on things stored in each. For a firm but practical grounding on this kind of thing I can heartily recommend the book The Elements of Computing Systems by Nisan and Schocken, which will have you start with just a 1 (not even a 0) and build on that, layer by layer, until you've constructed a working computer and the software that goes on it. -- Finlay McWalterჷTalk 13:09, 21 February 2013 (UTC)

00110100 in binary is actually 64 in octal.←86.186.142.172 (talk) 16:11, 25 February 2013 (UTC)

Right, if you want to understand the whole picture of how computers work, there are several layers of abstraction built up, and binary stings/ logic gates are quite near the bottom. I'll note that textual representation and encoding is not unique to computers, and has been around since ancient times. If the OP is interested in the general issue, s/he might enjoy flag semaphore, railway signals, semaphore line and text encoding. SemanticMantis (talk) 16:43, 21 February 2013 (UTC)

Incidentally 0011 0100 is hex 34 if it's shown in most-significant-bit-first, or hex 26 if it's lsb first; I don't see where you got 52. -- Finlay McWalterჷTalk 16:46, 21 February 2013 (UTC)

It's 32+16+4=52 if you treat it as an 8-bit binary number. Rojomoke (talk) 16:51, 21 February 2013 (UTC)

Which 0x34 ... it's time to up my meds, I think. -- Finlay McWalterჷTalk 16:56, 21 February 2013 (UTC)

Would it help if we provided a little code sample that converts binary numbers into decimal (not using any built-in functions, of course, as that would be "cheating") ? StuRat (talk) 17:00, 21 February 2013 (UTC)

With the certainty of sounding like a noob, I have no idea what 'code sample' even means...and certainly nothing about flag semaphore or anything like that! I have borrowed the book from the library and is actually munching through the first few pages as I am eating my pizza. Maybe I will return to the archive of this conversation to understand what all these phrases mean. Thank you all very much for helping me out, people usually say 'I appreciate it' and not mean it. Please know that I do! Thanks! Kinkreet^{~♥moshi moshi♥~} 17:27, 21 February 2013 (UTC)

OK, sounds like you have no computer programming experience. With that in mind, let me give a very basic "pseudocode" example of a computer program to convert an 8 digit binary number to a decimal number:

    DECIMAL = 0
    if (8th digit of binary number = 1) then DECIMAL = DECIMAL +   1
    if (7th digit of binary number = 1) then DECIMAL = DECIMAL +   2
    if (6th digit of binary number = 1) then DECIMAL = DECIMAL +   4
    if (5th digit of binary number = 1) then DECIMAL = DECIMAL +   8
    if (4th digit of binary number = 1) then DECIMAL = DECIMAL +  16
    if (3rd digit of binary number = 1) then DECIMAL = DECIMAL +  32
    if (2nd digit of binary number = 1) then DECIMAL = DECIMAL +  64
    if (1st digit of binary number = 1) then DECIMAL = DECIMAL + 128
    print DECIMAL

(I'd actually use more complex structures like loops to do this, and add support for negative numbers and variable length binary strings, but this is the simplest way.) Try running through this program yourself, and see if it doesn't work. StuRat (talk) 18:07, 21 February 2013 (UTC)

One thing to remember about computers is that they are very dumb machines. They do exactly what they are told to do, no more, no less; they just do it very fast. Astronaut (talk) 17:49, 21 February 2013 (UTC)

The important thing to keep in mind is that a number and its representation are two distinct things. This extends beyond the whole 56 decimal, 00110100 binary, 0x38 hexidecimal thing. It even extends to single digits. For example five is "5" in English/Western numerals, but "٥" in Eastern Arabic numerals, "५" in Devanagari numerals, "๕" in Thai numerals, "五" in Japanese numerals, and "ה" in Hebrew numerals. They're still all five, though. Same thing with the "zeros" and "ones" in a computer. In no place in the computer is there a long thin thing representing a "1", and a slightly flattened hollow round thing representing a "0". Instead, there are closed switches and open switches, capacitors storing charge or not storing charge, etc. (And depending on the context and chip, whether a closed switch represents a 1 or a 0 can change - it's completely subject to convention.) - So how does the computer know to put a picture on your screen that looks like a horizontal line over a vertical line over a half circle (i.e. a glyph that looks like "5")? Well, it takes the internal set of open/closed switches that have a binary encoded five on them, recognizes that that represents "five", and then looks at at table/performs a calculation which tells it that the character for "five" is ASCII character 0x35. It then stick the number fifty-three (which is what hexadecimal 0x35 is) into an output buffer (again, coded as binary in a set of switches/capacitors). Then the software that displays characters on the screen takes the value of fifty-three and looks up the fifty-third entry in an internal table it has. It then uses the entry in this table (put there by the font designer) to change the state of the output display such that in a small square on the screen there's a pattern of black and white pixels that looks exactly like what we think "five" should look like - no coincidence, because the font designer spent a bunch of time getting that internal table entry just right. And how does it know that fifty-two needs two glyphs, one "5" and one "2"? Well, it does the same thing you do when you convert numbers from binary & hexidecimal to decimal. It does a bunch of divisions by ten (not "10" - the number ten) and then makes sure the remainders are put together in the correct order. - Note that while the computer understands what five is, it doesn't really have a concept of "5", except perhaps as the fifty-third entry in some internal table. And the conversion to separate decimal digits typically happens late in the process. In StuRat's code above the variable DECIMAL doesn't actually contain a decimal number - it contains a value that is almost certainly represented internally by binary on/off states. The actual separating out into decimal digits is hidden internally in the "print DECIMAL" statement, probably deep in a system library. - Regarding a Hex editor, it's simply a program for directly modifying the bytes in memory or a file - it's a little disappointing, but that's all that computers do. They change the state of bits in one location (e.g. the memory or file being edited) based on the state of bits in another location (e.g. the bit coming from your keyboard presses and the bits in memory that are the hex editor program). There's nothing special about hexadecimal in this context, aside from the fact that it's convenient for representing eight-bit bytes.-- 205.175.124.30 (talk) 01:30, 22 February 2013 (UTC)

I'll try to explain layman's terms, though it'll still be technical. When you ask what in the computer turns 00110100₂ into 52₁₀, and not for it to remain as a sequence of 0s and 1s, the short answer is nothing. No matter what, the computer always sees 52₁₀ as 00110100₂. Also, I'm going to avoid calling sequences of 0s and 1s as strings, because then they're easily confused with text representations of the data. StuRat's example is how humans convert these values to decimal, so humans can comprehend things better. 205.175 basically explained how those 0s and 1s become the text you're reading.

So how does a computer know if 00110100₂ is 52₁₀, or the text character "4", a pixel color, a music "note", or any other data? Short answer is it doesn't. When you read a block of data off your hard drive, for example, all you will see are 0s and 1s, because that's all that's there. A hex editor reads these 0s and 1s, and shows it on the screen. It converts the 0s and 1s to hex, just because it's easier for humans to read (since 34₁₆ is easier to read than 00110100₂, and the two values are identical). The computer doesn't care what the hex value is.

When you open a file, the file extension tells the computer what to use to interpret these 0s and 1s. It also has to do with things like headers in files, but we'll ignore that for now. If the computer is told that the file is text, it will display the 00110100₂ sequence it finds as a "4" on the screen. If the computer is told that the file is an image, then it uses the sequence of 0s and 1s to create a color for a pixel, with the location relating to where in the file it's found. For example, the data for the second pixel follows the first, in the most basic use. If the computer is told that the file is a sound, it uses the sequence of 0s and 1s to create a frequency. If the computer treats it as a number, it goes through hardware designed to handle sequences of 0s and 1s, such as adders and multiplers. When it needs to determine which sequence is "larger" than the other, it goes through hardware comparators. Note that the computer at this point still doesn't actually know the sequence is a specific value. Just like it doesn't matter if you're multiplying 112 by 33, or 358 by 1283 -- you go through the same steps to multiply. The hardware is setup the same way. It takes inputs, run it through steps, and spits out an output. It doesn't need to know that 00110100₂ is 52₁₀ to do the math.

In all of the above examples, it's acting on the sequence of 0s and 1s, and it doesn't know that it's anything else. In fact, you can send a text file to an image program. It won't really do much, because the aforementioned header that the image program looks for in the file is absent, so it can't figure out what type of image it is, or how many 0s and 1s is used to determine what a pixel should be. You can also send a text file to your sound card with similar effects. Doing this type of thing is easier in Unix/Linux, but that's way outside the scope of this question, but you really can output a text file to your sound card, because the computer doesn't actually do anything other than interpret sequences of 0s and 1s. So if you tell the computer to interpret (what you know as) a text file as a sound file, it'll do it. Hope this helps a little. --Wirbelwind(ヴィルヴェルヴィント) 07:31, 22 February 2013 (UTC)