Computing desk
< February 20	<< Jan \| February \| Mar >>	February 22 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

February 21[edit]

Physical media[edit]

Is it likely physical media (blu-ray, DVD etc) will be gone in future, replaced by downloads? Clover345 (talk) 01:43, 21 February 2013 (UTC)[reply]

Largely, yes. I do think there's a market for permanent data storage, though, for things like family picture albums. However, they'll have to come up with a more permanent media than DVD's, as they only last years or maybe decades, not centuries. StuRat (talk) 01:48, 21 February 2013 (UTC)[reply]

I think there will always be a personal, physical storage medium, unless you trust your personal data online. I use USB devices for backup instead of DVD's that I stopped using about 5 to 7 years ago. For data that I really cannot afford to lose, I back it up online as well (encrypted). As for non-personal data/media, it seems 'downloads' or 'data on demand' is the way to go. This is of course only in places where bandwidth and data throughput are high enough to support decent quality content. Sandman30s (talk) 12:54, 21 February 2013 (UTC)[reply]

I suppose one advantage of physical media for games/dvds is that you can sell it on or trade it in when you are finished with it. --_nonsense ferret 20:15, 21 February 2013 (UTC)[reply]

Internet-based storage has not been around long enough to decide the issue. Do we know that a given storage site will be around for the next 20 or 50 years? Will other family members be able to access my photos and recordings after I die? Will all of my collected recordings vanish if I miss a monthly payment to the storage service? I don't think physical media will ever be completely replaced. We still hang paper photos and paintings on our walls and read paper books. — Loadmaster (talk) 18:39, 22 February 2013 (UTC)[reply]

This premise is not well-formed. Internet-based data hosting still uses physical media to store data. That media may take the form of magnetic hard-disks, solid-state storage, or any other cost-effective and convenient medium. The fact that you have outsourced your data storage to a third-party does not mean that your data isn't stored on physical media - only that you have become agnostic to the methods they are using. A better way to formulate the original question: will consumers continue to purchase (certain types) of data on physical media - and the answer to that is, "for now, yes." For example, people still buy DVDs and CDs. Yet, markets are growing for digital distribution of video; much like online sales of music cut into the market-share of compact discs. We can count up all the dollars of content purchased according to various distribution methods, and "estimate" whether physical media are still the dominant data-distribution channel for a particular marketplace. But, it is not clear how to compare market-shares across different types of industries: for example, should Netflix be compared to a television conglomerate, or to a motion picture studio distribution network, or to a DVD manufacturer? Is Netflix predominantly a "cloud service provider" or a "hard-disk and data-center operator"? To answer that question, you'll probably have to pay big bucks for a technology industry business analyst to provide you very little useful information. Nimur (talk) 19:02, 22 February 2013 (UTC)[reply]

Where to start?[edit]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]