Wiki Home

Representation Of Values


Namespace: WIN_COM_API
Values and the symbols used to represent them.

There are two components to the thing we call a number: the value it represents and the notation used to communicate that value to the reader. People get hung up on the idea that computers deal with hex or binary. Computers deal with values. (Maybe they get hung up on values, too. Computers deal in electrical (or other) impulses.) It is we humans who use hex, binary, and other notations to display the values.

Let's examine the number of days in a week. You should now have a number in your head. Cavemen might have made the same number of scratches on the wall: "IIIIIII" (like a tally). The Romans represented it as "VII". A child may hold up a bunch of fingers: "* y" (meant to look like five fingers and two fingers). Americans use the symbol "7". Europeans use the same thing with a "-" through it. The same value can also be represented in hex as "0x07" or binary "0111".

Note that there are many ways of representing the number of days in a week. Point is, it doesn't matter how you display it, it is the same value, and it is just a way that we humans use to communicate that value. A leading zero in C means octal, so there can be more to the interpretation, too.

Binary and hex get used in computers alot because it makes things easy: values are stored in memory and disk by setting or clearing bits. The 0000 0111 representation is similar to the top five bits clear and the rest set. The leading zeroes are unneeded place holders just like the leading zeroes on some paychecks does not change the value of the check: $0010 is the same as $10. (But remember that that needn't be so, as in C. - What? Please explain - seams relevant.) The explanation: In C, a leading zero in a numeric constant (and if it isn't followed by "x" as in "0x" for hex) means that the constant is octal not decimal. foo = 010; assigns to foo a value of 10 octal (a.k.a. 8 decimal).

I think we should talk about floating point and scientific notation, but I am tired of writing this now. If someone else wants to take over, that would be grand. I may pick it up some day.
A cash register eg:
barcode
(7 byte)
plu
(17 byte)
department
(1 byte)
price
(5 byte)
1234567890128GUM1250000

equivalent:

01 23 45 67 89 01 28 47 55 4D 20 20 20 20 20 20 20 20 20 20 20 20 20 20 01 20 20 09 C4 20

This string is like a dbf record - it has fields that are different data types. for each datatype, you need to decode it differently to get the right value.

7 bytes: 01 23 45 67 89 01 28
17 bytes: 47 55 4D 20 20 20 20 20 20 20 20 20 20 20 20 20 20
1 bytes: 01
5 bytes: 20 20 09 C4 20

"01 23 45 67 89 01 28" is "01234567890128" - when the 7 bytes are shown in hex it is easy to see why. But if you look at those same 7 values in decimal it gets confusing (so don't look...) ? 0x01, 0x24, 0x45, 0x67, 0x89, 0x01, 0x28 shows "1 36 69 103 137 1 40" which are the values we humans are used to seeing, but in this case seeing them this way is pretty useless.

"47 55 4D 20 20..." = "GUM space space...."
47 in hex is the same as G in Ascii
47 in hex is the same as 71 in decimal
47 in hex is the same as 0100 0111 in binary
? Chr(0x47) + Chr(0x55) + Chr(0x4d)
GUM

01 is 1. This is an easy one. (heh, and a free pun to boot)

Somehow "20 20 09 C4 20" = 250000... still trying to figure this one out. I'll let it sit for now.


See also: Base X
Contributors: Carl Karsten
Category Data
( Topic last updated: 2003.09.30 05:41:33 PM )