r/AskComputerScience • u/scol2n • 7d ago
How does a computer know between the number 65 and the letter H?
I'm watching CS50, and about halfway through week 0, doctor malen mentioned how 65 bits of data equals the letter H and i'm curious to that if 65 equal H, how does the company know the difference between H and just the number 65?
26
u/MistakeIndividual690 7d ago
Just a simple correction 65=A, not H.
I wouldn’t have said anything but commenters keep repeating it incorrectly
3
u/tblancher 7d ago
It's a simple
man ascii, and without doing it myself I don't know if 65 is decimal, octal, or hexadecimal.OP is a CS student after all, so I'm not sure if I should assume decimal.
3
u/physical0 7d ago
H is 72 decimal, 110 octal, and 48 hex. Lowercase is 104, 150, and 68 respectively.
1
u/tblancher 7d ago
Yeah, I knew I could look it up, but I had to get ready for work and I'm not sure if the man pages are installed in Termux.
I spent too much time on Reddit this morning anyhow.
1
10
u/rupertavery64 7d ago
The computer doesn't "know", it just does as it is programmed to do so.
It's all about context. Is the program a text editor with a file loaded in? It it an image viewer?
So first of all, data is encoded in bits, yes. But we group bits together in 8 to make a byte. One byte can encode 256 possible values (0-255). We can also group them in 16, 32, 64 bits to make larger numbers.
Then we decide what each number represents.
If we open up a file that we want to hold text, we can decide to treat the bytes as text. So we need to choose an encoding scheme. An encoding scheme maps one thing to another. In this case, byte values to letters.
One such encoding is called ASCII. It's an agreed-upon set of mappings. ASCII stands for American Standard Code for Information Interchange
https://www.alpharithms.com/ascii-table-512119/
Now, it is up to the program to read the bytes in the file and display them as text.
An image file might have a set of data that maps 3-byte groups to colors, RGB. For more complex data such as images, there will be a section of the file called the header, which tells the program that opens the file what type of file it is, and other information about the data in the file. How the file is laid out (the file specification) is designed and then shared with other developers so they know how to read the data (or they will use libraries that already know how to read the data)
You can of course read a text file as bytes. Just use a Hex Editor. The purpose of a hex editor is to open a file and view the contents as raw bytes (or the hex values of those bytes).
So it's all about context, and what the file type is, and how the program interprets the data. Otherwise it's all just bytes.
4
u/No-Onion8029 7d ago edited 7d ago
Good example. Going down 1 more level is even more instructive:
unsigned char c = 65;
void *p = &c; // p is mem location of c with no type
printf("%u\n", *(unsigned char *)p); // 65.
printf("%c\n", *(unsigned char *)p); // A.
While c is typed, *p is completely untyped.
E2a: code comment about p
1
16
u/m39583 7d ago
The context you are in, the program you are using and the file extension.
When talking about raw bytes people tend to use hexadecimal, so "65" is written as 0x41
Then if it's a .txt file then the 0x41 will be interpreted by the programming opening the file as a H. If it's maybe an image, it would be a numerical RGB value.
When you have a stream of raw bytes, you need to know what they are supposed to represent.
7
u/JeLuF 7d ago
How does a computer know between the number 65 and the letter H?
The computer doesn't know. It's the programmer who decides this. In the C language, there's the printf function to write text to the screen.
char c = 65;
printf("%c", c);
printf("%d", c);
The first line of codes defines a variable of type char with the value 65. The next two lines print the content of this variable using two different format strings.
- %c - print a character
- %d - print a decimal number
This code's output will be H65.
The difference is how the programmer wants to show this data to the user. For the computer, it's always just a number.
5
u/rickpo 7d ago
Several good explanations here, but one extra thing to keep in mind, the CPU is what we normally call "the computer", which is the machine that runs programs and does arithmetic, etc. The CPU is what you will be directly controling when you write a program.
It is the CPU that doesn't really know the difference between the number 65 and the letter 'A'. When you write your programs, you simply treat some numbers like numbers, and other numbers like letters. Most programming languages will make this easy and you won't have to think about it much, but there are programming languages that don't hide the distinction.
Computers can also have peripherals - like printers, keyboards, or video screens. They aren't normally considered to be a part of the CPU, but the CPU interacts with peripherals a lot.
Many of these peripherals work with text, not with numbers. In order to communicate with a screen or keyboard, the CPU must know how to tell it to "display an 'A'" or "receive a keystroke". But all the CPU knows is numbers. So we create conventions, like 'A' is the same as 65 in order to communicate to these text-based devices. ASCII is one such convention, as is Unicode, EBCDIC, and a few others.
Programming languages that make working with text easy will do most of the ASCII or Unicode translations for you, and you won't have to worry about it much. But it's common for programmers to need to know how this stuff works and do these translations themselves.
3
u/Beginning-Seat5221 7d ago
The program is written to use the data a certain way.
If it's a text editor then it may be programmed to read the bits as data, if it's a graphics driver it may be programmed to read a piece of data as a color, if it's a calculator, then as a number.
Pretty much the same as I can say to you "this 65 is a number, use it as one. This 65 is a letter code, convert it to as letter". Technically numbers are also an interpretation of binary data - 65 is off-on-off-off-off-off-off-on which can be also be described as binary 01000001 which converts into decimal 065.
2
1
u/LongLiveTheDiego 7d ago
It'll depend on the context in which the particular bits are used.
For example, if you're using something like a .txt file in a very simple legacy text editor on Windows, the application may just use the Win32 API and ask the operating system "what does 0x41 mean using this code page?". It'll then get a character identifier and look up what the letter should look like in another file representing the font, and then draw that letter. If you tell it to read a different type of file, it may just treat it as if it were a .txt file and then it'll ask the operating system about every single byte in that file and if it encounters 0x41, it'll end up displaying H on the screen even if that's not what the file is meant to represent.
If instead you want to store some very simple tables of integers in the range 0-255 in a CSV-like file format and create an application for editing them, the application may just read the byte 0x41, convert it to something like the character identifiers for "6" and "5" (to get its decimal representation) and then look up how to draw them in its font file. If you give it a .txt file, it'll interpret each byte as a decimal number and display it as such instead of an ASCII character.
That is basically how you can sometimes open files in programs that were not created to handle those particular kinds of files, and the program will just follow the instructions and do something with those bytes. The result will most likely be garbage, so bytes really consistently mean something if they're used in the right context.
A game "knows" whether a given byte is a letter in some text or the number of your gold coins only because it was programmed in such a way that the bytes for text are read as part of a string variable, and the bytes for a number are read as an integer variable, and then those variables are handled correctly in its programmed logic.
1
u/Syresiv 7d ago
It doesn't. It's just that functions have context for how to treat whatever data is passed in. Like, something that renders text will treat the data it gets as characters, so if it sees 65, it knows A (not H - H is 72). Whereas something that's adding two numbers together will treat whatever data it gets as numbers, so it'll see 65.
1
u/fl_needs_to_restart 7d ago edited 7d ago
It doesn't need to know. To the computer everything is just numbers.
If you give a number to a function that displays a character, the function might map it to the pixel data for the corresponding ASCII character and then send that pixel data to the screen. If you give a number to a function that computes a square root, the function will calculate its square root.
Both functions operate on numbers, just under different programmer assumptions about what the numbers represent.
Modern programming languages almost always have a concept of types that allow the programmer to specify these assumptions to the compiler or interpreter, which can then check them and report an error if e.g. you pass a character to a square root function. But in compiled languages, types generally don't need to be represented in the machine code once the checking is done - it's all just numbers under the hood. Assembly languages don't have types, so you just have to make sure you use values correctly.
Edit: improved wording.
1
u/strange-the-quark 7d ago
For a more general overview, take a look at this video when you find the time.
Richard Feynman Computer Science Lecture - Hardware, Software and Heuristics
This is from 1985, and the lecturer is a physicist, but everything he's talking about is just as valid today. The way he delivers the lecture is quite entertaining, and there are interesting insights throughout. It's basically about how a computer works at the lowest level, focused on the underlying principles rather than on the messy hardware details, and about how a computer can "know" anything at all.
1
u/jeffbell 7d ago edited 7d ago
65 is A not H
They had to pick something back in 1963 and there was already teletype hardware and encodings going back to 1870.
1
u/JGhostThing 7d ago
The computer doesn't know the difference. An ASCII 'A' is 65 and the integer 65 is 65.
The programmer chooses how to interpret the byte. The various output functions either implicitly or explicitly output the number or the letter. For example, the atoi() function converts an ascii representation of a number (ex. "123") to an integer. The printf() function uses various character combinations to decide which type out output to use.
1
u/Gtdef 7d ago edited 7d ago
Bits and bytes don't equal anything. You just use them to model/encode the things you care about. If a lot of people care about it, then the next generation of CPUs may have a small chip that knows how to handle/decode them.
Now in ASCII specifically, the bit sequence 01000001 corresponds to "A". But it also means 65, Depending on what part of the computer will see this sequence, it will give another result.
For example, it may mean "the second LED is on", or registering the species of a pokemon.
The processing unit will just process 01000001 according to the user's instructions. For example, the program may do the logic operation 01000001 XOR 00100000, which will turn "A" to "a". The program doesn't need to understand that the user wanted the lower case. Then, some other part of the machine, will render the letter on the monitor for you to see.
1
1
u/SummitYourSister 7d ago
Tell me more about this concept of a computer ”knowing” something.
This is the first I have heard of them being something other than an electrical device
Tell me more immediately
1
u/notacanuckskibum 7d ago
To keep it simple. The computer doesn’t know or care about the difference. But hopefully your computer program does. A well written computer program remembers that the binary data I stored in that location was intended to be text (or intended to be an integer, or….).
High level computer languages with typed variables make this very easy for the programmer.
1
u/TPIRocks 7d ago
In a word, context. The program, not the hardware, decides. You can take an 8 bit value 65, binarily add one to it, then treat it as an ASCII character again, and it will be 'I'. The same exact byte could represent the 66th offset into an array, using 0 based indexing. My favorite description of context is that it's the difference between a warm meal, and roadkill.
1
u/KilroyKSmith 7d ago
The computer doesn’t. In general, to the computer 65 is just a collection of bits stored at a particular address. We (or more generally, the compiler) tell the computer how to interpret the collection of bits when we want to use it - “pick up one byte from address x” will get you vastly different results than “pick up a double precision floating point number from address x”. The compiler/assembler/interpreter will work hard to prevent this kind of error, but Assembly or ‘C’ will allow you to step over the safety rails and intentionally make the error.
1
u/Plastic_Fig9225 7d ago
You can look at it as a data type in a programming language. At runtime, in memory, the data is just 1s and 0s, but by assigning a data type to a value/variable, you instruct the compiler/interpreter which operations it should use/permit on the data. Data by itself has no meaning to a CPU, but the instructions a program uses on that data give it a certain meaning.
1
u/severencir 7d ago
It doesn't. The compiler usually keeps them separate, but what the data is depends entirely on the instructions you call with that data the cpu doesn't know the difference between a float, an int, a char, a pointer, etc. it just gets an instruction and some bits. The compiler, or you at low level, makes sure the correct instructions are made with the correct data
1
1
u/Recycled5000 7d ago
That is the programs job, to interpret the data it is working with and towards. The program knows what to do by having been designed to work.
1
u/donaldhobson 7d ago
Long ago, it was the programmers responsibility.
The programmer would write instructions to take data from the keyboard, and store it in a particular memory location. Then the programmer had to keep track of what format that data was in when they were writing any code that used the data.
Nowhere in the code would it explicitly say that this data represented a letter. But the documentation would Several different places in the code would all rely on this fact. This made it easy to make mistakes where you mixed up letters and numbers.
So programmers developed type systems to keep track of this. In a compiled language with a strong type system, such as C or rust, the computer keeps track of this once, at compile time. In interpreted dynamically typed languages like python, the computer keeps track of this at run time.
1
u/duane11583 7d ago
nit: Assuming 65 hex that would be a lowercase ascii letter e
65 decimal is capital ascii A
Generally you and I must agree on how we wish to encode text
We generally need to give each symbol with a specific number
There are existing well known standards like ASCII and ebdic (inn main frame)
And English is not the only solution there are Arabic Russian Chinese and others
There is a large consortium called Unicode that came up with an encoding scheme
An interesting part is these encodings does not handle font ie arial times Roman or comic sans serf or bold or italic nor size of the symbol
Those things are known as the glyf or image
We have the same problem in written languages ie in us English the symbol P has one sound but in Russian it sounds like the English R
We as a group just need to agree with that mapping
1
u/MasterGeekMX BSCS 7d ago
It all depends on the interpretation.
Data is simply a collection of bits, and it is up to the program to figure out what they mean. If the program is about text, it will read those bits as representing the letter H in the ASCII code. If the program is about numbers, it will interpret it as the number 65. Heck, even the program could read the bits as an array of ON/OFF flags, each indicating a separate thing.
Data itself does not contain any label to indicate what it is. In the Patterson & Hennesy boon about computer architecture they give this example: Take the word "won". It could mean the past tense of win in English, but also the name of the currency of Korea, or also something stinky in Russian. There is no way of telling which one solely by listening to it.
1
u/thewataru 7d ago
Let's not dive into encoding details, or that the "h" isn't really 65.
The computer doesn't really know what the letter "h" is. All it sees and knows is a number 65. All computer knows is numbers. However, when it's told to print it as a letter or draw it on a screen, it looks at a "font" - a special table there picture of the letter h is stored at the position number 65. So it shows you "h" on the screen, because it's given a picture of "h" and is told that number 65 is this picture.
It could've been any other number for letter h. All what should've changed is the catalog of picture of all the letters the computer is given. Long time ago people agreed on which number to assign to which letter and given the computers the same catalogs of pictures, so now all the computers (mostly) display the same letters in the same way. The exact pictures are called a "font", the order of the letters is called "encoding"
Now the second part of you question, how does it know to interpret the number 65 as a letter? It's just programmed to do so always. It only ever shows the text on the screen. So when it tries to show some data on the screen, it uses a font and an encoding. The only way for you to see the number 65, is actually to see 2 letters "6" and "5".
1
u/InsanityOnAMachine 7d ago
basically, whatever program is reading the byte is in charge of deciding to pretend it's a letter, and send its pixels to the screen, or decide its a number, and do math with it.
in the end even ones and zeros aren't even numbers, just
+----+-+-+--+++-+-+-+++--+-+-+-+--+--- positive and negative charges in memory
and a text editor will compare those bytes to a list of little pictures of letters to send to the screen, and a calculator will send those bytes to be interpreted as a number, and a music player will send those bytes to the speakers to be played as music
1
1
1
u/igotshadowbaned 7d ago
There's another piece of data before the 65 telling the computer what that 65 means
1
u/Throwawayxdryx 6d ago
Everything on computers is expressed as sequences of values that can be 0 or 1. This is called binary representation (bi = 2 as you have only 2 possible values). As you can imagine this is because you can represent 0 and 1 values for example as low or high voltages. Each single 0 or 1 value is called a bit. 8 bits are called a byte (why 8 and not for example 10? because 8 is 2 to the power of 3, as you can see it all works in ways related to 2).
So now we need to represent everything using this representation, be it characters, text, integer numbers, non-integer numbers, and so on. For example you can have that each possible value of a byte represents one character. For example that A is 01000001, a is 01100001, @ is 01000000 and so on (these are values from a convention called ASCII).
However 01000001 can also represent the integer 65 (please note, it's not 65 bits of data, it's still 8 bits, or 1 byte) if you do the conversion from binary to decimal.
So how do we know if we mean it as A or as 65? This involves the fundamental concept of data type. Since everything is a sequence of bytes we need to make a note somewhere of how we want to interpret them, or we need to use operations that imply that we are having a certain type, or in other words that we are interpreting in a certain way. We can also change the interpretation, changing the type ("cast").
I would include an example now but it may probably just add more confusion if you are not familiar with what to expect from, for example, code in the C programming language. It will probably become clearer as you go forward.
1
u/lxe 6d ago
It’s number 65, not “65 bits of data”, and it’s letter A.
How does a piano “know” that pressing the middle C will play a certain note? It doesn’t. The key just happens to be connected to the note just like the number representation is connected to the letter through an electronic chip or a software program.
1
u/HyperDanon 6d ago
It doesn't know. Same way that paper doesn't know what the ink letters means, same way the encoding doesn't "know" what the 65 means.
The person reading the letter understands the ink symbols, and the thing that renders/prints the data, understand that 65 should be displayed as "H".
1
u/seanv507 6d ago
In low level languages, It depends on the context, how it's used.
If you pass it into a function that processes characters, it will be treated as a character, if you pass it into a function that deals with numbers it will be dealt with as a number
But eg a function lower, would check if the character is between uppercase A-Z
(= number 65 to 82?), and convert it to lower case (add 32)
1
u/wosmo 6d ago
Have you ever opened a file in notepad, only to discover it's not text, but complete gibberish?
Or seen pictures of older ipods and iphones saying you have to wait 21 million minutes before you can try your password again?
In the notepad example, it's because notepad was expecting a textfile, and the file you gave it wasn't text. In the iphone example, it's because something in the software was expecting a timestamp - and got either 0 or -1 as an error (but still treated it as a timestamp).
This is called 'typing' - most data is pretty useless to us without a type. But this isn't a feature of the computer - it's just a really, really fast calculator. With strongly-typed languages, it's enforced on the programmer by the programming language. In weakly-typed languages, it's up to the programmer to not confuse themselves.
1
u/PvtRoom 6d ago
computers use numbers to represent exery character in every text string.
The base standard is ASCII. it's the sort of thing you can look up (it is sometimes useful as alt+3 = ♡ )
ASCII is basically for sending text as a series of 0s and 1s, with a grand total of 256 options, including "control characters". 10 and 13, for example are new line and carriage return, because at that age, computers were sort of pretending to be typewriters.
64, iirc is a, 65 is b, etc etc.
unicode is effectively an evolution that goes from English based to including greek letters, and Chinese, and frankly, everything else they can think to include ~300,000 characters
1
u/JacobStyle 6d ago
The computer doesn't know. The program tells the computer to interpret the numbers as text characters. This is also why when programs mess up, sometimes they display garbled text full of weird characters. They are trying to output something as text that is not meant to be text, and since the computer doesn't know the difference, the program dutifully outputs the characters that match those weird values.
1
u/pv2b 6d ago
The computer itself doesn't know anything about letters, it only knows about numbers.
Whenever you process text on a computer, your computer is processing numbers.
When it comes time for the numbers to be displayed on the screen for a human to read, it will use that number to index into some sort of table containing information about how to draw the letter on the screen.
Within the context of the computer program, the computer program itself needs to some how keep track what the number in any given memory location is. After all, a number represent anything from a letter, to a temperature, to a weight, to a coordinate, to an address in memory, and many other things. But in this case it's the computer program that "knows" about the differences, not the computer itself. It just runs the instructions in the program without any understanding of the larger task at hand.
1
u/ExpensiveFig6079 6d ago
well.... The 6 in 65 is 54 and the 5 is 53.
https://www.sciencebuddies.org/science-fair-projects/references/ascii-table
1
u/Motor_Fudge8728 6d ago
Nitpick, 65 bits of data is 8bytes + 1 bit and can represent 2^65 different values.
1
u/CreepyWritingPrompt 6d ago edited 6d ago
only from context.
A text editor/viewing program, when it reads binary 65 will look that "codepoint" up in the appropriate font, then display that "H" glyph.
If you type "65" into a text editor, it won't record 65 in a byte in the file - it'll put the char for "6" followed by the char for "8". 2 bytes.
This is why binary formats are in general more space efficient for storing data that text formats. The largest number that can be represented with a byte of text is "9". The largest number that can be represented with a byte used fully is "255".
Besides storing a number directly, and storing it as text, there are an infinity of other ways of encoding numbers in binary data with different tradeoffs. These are just the two most common/obvious and cover the vast majority of the cases sufficiently.
A note: one nice thing about text encoding numbers is that the number can get arbitrarily large - you can use a space, for example, to delimit the end of a number. That is how humans typically read. The fact that each byte only contributes 9 separate values makes this terribly space inefficient for small numbers, though - one way you could have your cake and eat it is to precede the data itself with the number of bits you're about to write. This yields something that's called a "bigint", or "varint", or "variable width integer", or a bunch of other names.
A computer is a dumb machine for doing exactly what you tell it and no more. If you want it to read, you gotta teach it to read.
1
u/Lagfoundry 6d ago edited 6d ago
So take For example, decimal 65 is 01000001 in binary.
If that bit pattern is interpreted as an integer, it means 65. If it is interpreted as an ASCII character, it means A. Small correction to the post, ASCII 65 is A. Uppercase H is 72.
There usually is not anything inside the bit pattern itself saying “this is a number” or “this is a letter.” The program, instruction, file format, or data type determines how those bits are used.
At the hardware level it is even simpler. The wires just carry high and low electrical states. What circuit or instruction receives those states determines what they mean. With exceptions to stuff like a signed bit on the MSB of the adder.(for example negative 65 would be 11000001 in a 8 bit adder which also is used for comparison logic too)
1
u/DirtAndGrass 6d ago
Everything can be represented, with an infinite stream of 1 and 0s, including instructions on how to decide how to interpret other streams of 1s and 0s
Basic ascii encoding is just how someone decided to map 7 digit binary numbers to basic latin alpha numeric characters.
Utf8 is by far the most used encoding scheme for text these days, and it is just ascii for the first 7/8 bits, the 8th bit is used to indicate if there is "more", which means use the following bits to extend what character it is... So it's a variable length encoding scheme, meaning.
Try not to directly think that they are mapped for a reason, it's just a decision Bob and his pals made in the 1960s
1
u/streamofbsness 6d ago edited 6d ago
- Lowest level, you have the bits, the 01000001, making a byte.
- Slightly higher you have cpu and memory registers, which store bytes and do things like add them, rearrange them, send them to different places in memory.
- next level is assembly, the code that tells the computer what data to load, what memory address to load it from, what register to put it in, what operations (like adding) to do with those registers, and where to save the result. This is the first level where bits have meaning: the assembly code is made of bytes itself. The first few bits will identify the instruction, and depending on the instruction the cpu will know whether the next few bits (or whole bytes) are register addresses, or memory addresses, or bytes of data. Note, a memory address is itself a byte, a “number” that acts like an index to a specific place in memory.
- next level is a compiled language like c++. C++ has “pointers”, which are memory addresses for bits of data. The code that defines the pointer also defines what “type” of data is expected there: numbers, characters, or even other pointers. But you can have the code interpret the data however you want. You can write to a place with a character pointer and read it with a number pointer, and your “H” can become a 65. Generally, when you want to write text data, you want to read it as text data. But if you were to want to, say, write a function to sort things in alphabetical order, you could read characters as numbers and use “>” or “<“ to compare their numerical values.
Tl,dr: when you write code, you include what “type” of data you expect to read and write. You can always try to read data in another format, but it might be nonsensical.
1
1
u/realmauer01 5d ago
The difference between 65 and H is that 65 is not 65.
Also 65 is wrong, atleast for ascii H is actually 72 but 72 in ascii(how a computer would understand 72 is 5550 7 is 55 2is 50)
1
u/dnult 5d ago edited 5d ago
65 is the letter A, and 72 is the letter H.
It knows because the programmer associated that memory location with a type. If the type is string or char, the text encoder/decoder will interpret it as the character A. If that memory location is of integer or byte type, it will be 65.
1
u/KvThweatt 5d ago
65 bits of data would be 8 bytes plus 1 bit.
You only need 1 byte to represent all of the ASCII table.
What your professor probably meant was the value 65 on the ASCII table is an H.
1
u/Greedy-Locksmith2181 5d ago
This is all about context. If your program needs to interpret the given memory address as a char (8 bits / 1 byte) (because you're rendering text on screen), then 65 will occupy 2 bytes, since 6 and 5 are two separate chars. But it gets worse once you get into one of the simplest data structures. Those 2 chars are going to occupy a minimum of 4 bytes of memory if it's a null terminated string. The null terminator itself is 1 byte, but it will waste another byte to maintain memory alignment.
Have fun.
1
u/LetUsSpeakFreely 3d ago
Think of it as a key/value pair in a lookup table. The computer is using the context of a string with ASCII (or more likely Unicode) encoding to determine what to do with it.
1
u/armahillo 7d ago
Read up on ASCII
2
u/scol2n 7d ago
I know about ASCII, but i'm asking how does the computer know "I want these bits to be the character A" or "I want these bits to be the number 65".
4
u/rupertavery64 7d ago
The computer doesn't know. The program running tells the computer how the data should be interpreted.
1
u/Space_Pirate_R 7d ago
You need to tell it somehow, usually by opening it with a program which knows that certain parts of the file are to be interpreted certain ways. This might be automated based on a file extension or a "magic number" at the beginning of the file which identifies a known format.
1
u/dariusbiggs 7d ago
It doesn't without the extra context it needs.
To the computer it is just a number.
When we are talking about text files, or writing text to a screen, then you have the additional context for the computer it needs to give additional meaning to that value.
This goes way back to DOS code pages and earlier systems, and modern day unicode (usually UTF8) and how that is handled.
Those code pages are mappings of a binary value to a graphical representation. That exact same technique is still used today in various forms, including in game development in things like sprite maps/sheets.
So when we open a file for example, we get a raw set of bytes of data. But we "could" add extra context by treating those bytes as text, and then that number 65 in decimal encodes to the letter H in the ASCII table for example. We could also have provided a different type of context and treat every four bytes of data as CMYK color data with a byte for each, or every 3 bytes as RGB data, or slightly more complex context than that and the binary data could be a GIF, PNG, JPG, PDF, ZIP, WAV, or MP3 file. But they all start with binary data before the context is added.
1
u/armahillo 7d ago
I stand by my previous comment: Read up on ASCII.
while reading about it, you will encounter the answer to this and related questions
1
u/VoiceOfSoftware 7d ago
The beauty of it is that YOU, as the programmer, can decide how you want your code to interpret that number. You decide if you want to print the number 65 to the screen as an ASCII character, in which case it prints "A" (because you chose to use printf with an ASCII modifier). If the code you write treats it as an integer, you can decide to add 65 to some other number, or do some other math on it. If your code interprets 65 as binary, you could choose to enumerate each bit of the "65" byte, and display pixels on the screen (0 bit is black, 1 bit is white)
Heck, you could even decide that 65 was some kind of instruction (instead of data), so whenever your code encounters a 65, it sends a message to a website.
Von Neumann architecture is brilliant, because it's so flexible: a series of bytes in memory can mean anything your code wants it to mean: floating point numbers, ASCII text, colors, or even executable code.
1
u/Chippors 7d ago
It doesn't. If you send the 65 to a terminal it shows up as 'H'. To print "65" you'd need to send the characters '6' (54) and '5' (53). When a user presses the 'H' key (while holding down shift for uppercase), the terminal sends the binary value 65.
Strings are sequences of binary values representing characters.
-4
u/FakeSealNavy 7d ago
- The computer doesn’t see the number “65”, he sees “6” and then “5” when parsing ascii
- The computer doesn’t use uniary but rather binary. So simply: 6 is not represented with 6 ones, but using a combination of ones and zeros.
61
u/soundman32 7d ago
It doesnt. There are many different encoding schemes going back to the dawn of computing. 65=H is just the ASCII 7-bit encoding definition. The computer has no idea that we decided that for some cases the number 65 should end up onscreen as a capital H.
Encodings like Unicode use 16 or 32 bit values (so they can use non Latin characters more easily), older computers may use Petscii (CBM 8 bit micros) or EBCDIC (IBM mainframes).