"Why is it necessary to classify data according to its type in computer programming?"
in [General Programming]
|
Prev: "Why is it necessary to classify data according to its type incomputer programming?"
Next: "Why is it necessary to classify data according to its type in computer programming?"
From: Pascal J. Bourguignon on 5 Jul 2010 10:53 "Daniel T." <daniel_t(a)earthlink.net> writes: > pjb(a)informatimago.com (Pascal J. Bourguignon) wrote: >> Fred Nurk <albert.xtheunknown0(a)gmail.com> writes: >> >> > My answer to the subject of this thread is: >> > It is necessary to classify data into different types because a computer >> > must use a system of codes to classify the data processed. >> > >> > The assumption, of course, is that I'm doing basic reading comprehension >> > from a textbook. >> > >> > My answer is very much derived from this paragraph of my textbook: >> > A data type refers to how the computer classifies data. We can all see at >> > a glance whether data is numerical or expressed as a percentage or >> > currency but a computer must use a system of codes to classify the >> > different types of data that are processed. The different data types in >> > computer programming include integers, characters, Boolean, floating >> > point numbers, real numbers, dates, pointers, records, algebraic data >> > types, abstract data types, reference types, classes and function types. >> > >> > Does my answer make a lot of sense? >> >> >> (123 >> 1.23 >> "123" >> ABC >> #S(point :x 12 :y 34) >> #(1 2 3 4 5)) >> >> >> You can see that we have here a list containing an integer, a floating >> point, a string, a symbol, a structure of type POINT with two slots x >> and y bound to integers, and a vector of integers. >> >> You, as a human, can see it, and the computer, as a lisp implementation, >> can parse it too. Therefore you're both at the same level: >> >> there is no need to classify data according to its type >> >> because there are clues that will tell what kind of data we have and >> both a human or an computer program can take these clues to interpret >> the data as being of one type or another. > > That's a funny answer... There is no need to classify data according to > its type because we (and the computer) can classify data according to > its type. :-) Yes, it's funny because both the OP and I are struggling at explitely state things. (And indeed more philosophy is needed.) The quoted text book itself is funny. Computers don't do anything (but execute programs). Programs may or may not classify data. What programs is this text book talking about? My guess is and was that it was refering to "statically typed compilers and interpreters". My answer tried to show that if you extend the scope to "dynamically typed compilers and interpreters", then since these programs know for each data object what type it is, your own programs (that are executed by these "dynamically typed compilers and interpreters" programs) don't need to discriminate or classify by type the data objects any more than you do, given also that they read the same textual representation as you do. What's more, the type classification depends only on the job at hand, and is not an essential characteristic of the given data object. For example, in Common Lisp, depending on the implementation (type-of 42) may return anything from (INTEGER 42 42) to T including FIXNUM, (INTEGER 0 281474976710655), INTEGER, RATIONAL, REAL, etc. (type-of "abc") may return ("abc" could be classified as): STRING, (STRING 3), (BASE-STRING 3), (SIMPLE-BASE-STRING 3), (SIMPLE-ARRAY BASE-CHAR (3)), etc. Theorically, any user defined type that is a union of STRING would also be a valid classification of "abc", and for example: (deftype string-designator () `(or string character symbol)) (deftype pathname-designator () `(or pathname string)) (deftype username () `string) depending on the context, you may rather want to classify "abc" as a STRING-DESIGNATOR, or as a PATHNAME-DESIGNATOR, or even as USERNAME. The type classification forced by "statically typed programming language" implementations is artificial and misleading. It should not be necessary to classify data following this low level and arbitrary classification. On the other hand, if your application has a function that requires a pathname-designator, or a username argument, then you may want to classify your data with this classification. (defun open-database (db) (etypecase db (pathname-designator (open-database-file db)) (database (reopen-database db)) (integer (open-database-file (aref *database-table* db))))) (defun login (user) (etypecase user (username (login (find-user-uid user))) (integer (setf (user-is-logged-in (aref *user-table* user)))))) But again, you may just call functions that don't care what type your db or user are, so that you just DO NOT need to classify them. (defun collect-user (user) (push user *list-of-objects*)) -- __Pascal Bourguignon__ http://www.informatimago.com/
From: Paul N on 7 Jul 2010 17:15 On 5 July, 09:24, Fred Nurk <albert.xtheunkno...(a)gmail.com> wrote: > It is necessary to classify data into different types because a computer > must use a system of codes to classify the data processed. > > That's my answer (which I've tried to take from my textbook) to this > thread's subject. > > My textbook has this paragraph: > A data type refers to how the computer classifies data. We can all see at > a glance whether data is numerical or expressed as a percentage or > currency but a computer must use a system of codes to classify the > different types of data that are processed. The different data types in > computer programming include integers, characters, Boolean, floating > point numbers, real numbers, dates, pointers, records, algebraic data > types, abstract data types, reference types, classes and function types. Data in the real world has many types - for instance, a temperature, a distance, a name, an address. Obviously, what you can do with any piece of data depends on its type. In order to process data on a computer, it needs to be represented in some way. Normally, a computer language will provide a certain number of types - integers, floating point numbers, strings etc - and the programmer will use these in a suitable way to store the data he needs to deal with. A few languages only have one type (BCPL, for example, and possibly FORTH as well) and so the programmer needs to do more work. And many languages provide some way to produce new types, for instance classes in C++. So, for instance, a programmer may store distances and temperatures as floating-point numbers, and names as a string. Incidentally, I would be a bit surprised if a language actually provided a type for real numbers. > Does my answer make sense? Could I do a better job of showing my > understanding of the importance of data types using the textbook > paragraph? I think the question is a bit vague - for instance, a program to calculate all the prime numbers up to a given limit does not need to classify data at all. I think your answer might be more accurate if you say "a computer must use a system of codes to store the data to be processed" and then go on to explain how the type of the data will affect the coding. Hope this helps... Paul.
From: Joshua Maurice on 7 Jul 2010 18:37 On Jul 5, 1:24 am, Fred Nurk <albert.xtheunkno...(a)gmail.com> wrote: > It is necessary to classify data into different types because a computer > must use a system of codes to classify the data processed. > > That's my answer (which I've tried to take from my textbook) to this > thread's subject. > > My textbook has this paragraph: > A data type refers to how the computer classifies data. We can all see at > a glance whether data is numerical or expressed as a percentage or > currency but a computer must use a system of codes to classify the > different types of data that are processed. The different data types in > computer programming include integers, characters, Boolean, floating > point numbers, real numbers, dates, pointers, records, algebraic data > types, abstract data types, reference types, classes and function types. > > Does my answer make sense? Could I do a better job of showing my > understanding of the importance of data types using the textbook > paragraph? For the OP, here are my random thoughts. A char, and int, and a string are all just pieces of memory (perhaps more than one piece of memory). In the end, the hardware doesn't treat it different than other other kind of data, and as all modern computers are Von Neumann architectures, the hardware doesn't even distinguish between data and executable. It's all stored in the same way to the hardware, just a series of bits. Assembly lacks type information. Assembly is just a way of writing executables without using a hex editor (or manually twiddling bits with a physical device). Different opcodes perform different operations. An opcode that makes sense for an int can be called on a contiguous piece of memory which was previously treated as a string. The hardware does not care, and assembly let's you do whatever the hardware can do. The C programming language is a small, portable abstraction over many different kinds of hardware and assembly (ignoring the optimizer, dynamic linking, the loader, and all other complex and mostly irrelevant issues). There is a relatively straightforward one to one transformation of each "line" C code to a particular assembly. C introduced types as a way to get portability across different assembly languages. The C programming language identified common sets of operations across different assembly and hardware, and associated with each a name. This name is called "a type". For example, nearly all assembly languages had a group of opcodes which could be called "int add, subtract, multiply, divide". This notion of type allowed a portable method of specifying programs. Types in low level languages are an abstraction to provide portability. No longer do you need to know which opcode, but instead you just need to conform to pre- existing classes of operations which are associated with predefined "types". Once you do that, you can program portably to any hardware which can support the type abstractions which your program uses. That is the meaning of types at a most pragmatic level, a means of portability across assembly or virtual machine (ex: Java).
From: osmium on 7 Jul 2010 22:06 Fred Nurk wrote: <Presumed question contained in the subject line. Questioner has a very busy life.> A computer has no notion of context or meaning. A human seeing an integer, a number containing a decimal point, and a number given in scientific notation immediately and automatically classifies them and would add them in a way appropriate to the form used for the number. If conversion from one type to another is needed, the human can even see the need and make the necessary conversion. A computer must be *explicitly* told the form.
From: Matt on 8 Jul 2010 02:50
On Wed, 7 Jul 2010 21:06:02 -0500, osmium wrote: >Fred Nurk wrote: > ><Presumed question contained in the subject line. Questioner has a very >busy life.> > >A computer has no notion of context or meaning. A human seeing an integer, >a number containing a decimal point, and a number given in scientific >notation immediately and automatically classifies them and would add them in >a way appropriate to the form used for the number. If conversion from one >type to another is needed, the human can even see the need and make the >necessary conversion. A computer must be *explicitly* told the form. The type is implicit in the operator or function used. When else does it matter what type it is? I see no need (apart from ease of memory management for the compiler, which shuld be transparent to, not a constraint on, the user) to care what type of variable the characters "1.23" are assigned to. I may want to use that string as a number or as text in the same program. Why do I need to be burdened with type conversion as a separate step in my program? |