When something is assigned to a variable, such as an integer with 32 bits, does that mean the integer's binary form will always be of 32 digits? or does one number not correspond to one bit, and when we say we store data in "a box of x bits", the number used to represent that thing being stored is not the same number of digits as the number of bits?
Is it the case that for all things, such as all primitive and reference types in java, the number of bits into which something is stored corresponds to the number of digits used to represent this thing?
thanks
I have looked at examples of numbers to represent objects to see if they were the same length as the number of bits that fit into their memory box.
Related
I'm having difficulty storing and displaying numbers greater than 32767 in LC-3 since a register can only hold values from -32768 to 32767. My apology for not being able to come up with any idea for the algorithm. Please give me some suggestion. Thanks!
You'll need a representation to store the larger number in a pair or more of words.
There are several approaches to how big integers are stored: in a fixed number of words, and in a variable number of words or bytes. The critical part is being able to detect the presence and amount of overflow/carry on mathematical operations like *10.
For that reason, one simple approach is to use a variable number of words/bytes (for a single number), and store only one decimal digit in each of the words/bytes. That way multiplication by 10, means simply adding a digit on the end (which has the effect of moving each existing digit to the next higher power of ten position). Adding numbers of this form numbers is fairly easy as well, we need to line up the digits and then, we add them up and detect when the sum is >= 10, then there is a carry (of 1) to be added to the next higher order digit of the sum. (If adding two such (variable length) numbers is desired, I would store the decimal digits in reverse order, because then the low order numbers are already lined up for addition.) See also https://en.wikipedia.org/wiki/Binary-coded_decimal . (In some sense, this is like storing numbers in a form like string, but using binary values instead of ascii characters.)
To simplify this approach for your needs, you can fix the number of words to use, e.g. at 7, for 7 digits.
A variation on (unpacked) Binary-coded Decimal to pack them two decimal digits per byte. Its a bit more complicated but saves some storage.
Another approach is to store as many decimal digits as will fit full in a word, minus 1. Which is to say if we can store 65536 in 16-bits that's only 4 full decimal digits, which means putting 3 digits at a time into a word. You'd need 3 words for 9 digits. Multiplication by 10 means multiplying each word by 10 numerically, and then checking for larger than 999, and if larger, then carry the 1 to the next higher order word while also subtracting 10,000 from the overflowing word.
This approach will require actual multiplication and division by 10 on each of the individual words.
There are other approaches, such as using all 16-bits in a word as magnitude, but the difficulty there is determining the amount of overflow/carry on *10 operations. It is not a monumental task but will require work. See https://stackoverflow.com/a/1815371/471129, for example.
(If you also want to store negative numbers, that is also an issue for representation. We can either store the sign as separately known as sign-magnitude form (as in stored its own word/byte or packed into the highest byte) or store the number in a compliment form. The former is better for variable length implementations and the latter can be made to work for fixed length implementations.)
want to save the number x in more bits than the standard binary representation. The bitstring representation, which iam searching, must be unique for this number x that i can map x to this representation and back. Also on every bit position 1 and 0 must be allowed.
Exists such a bitstring representation of number x, or its not possible to create such representation?
For example the zeckendorf representation is unique but doesnt allow 2 consequtive 1. If iam cut out the 0 after one 1 the length of the resulting bistring is more or less equal to standard binary representation length, but not longer.
Add a single bit that is the parity of the original number: XOR all of the bits together. THe mapping is deterministic, unique, and trivially reversible.
In general, any error detection/correction addition will satisfy your posted requirements.
What's the most optimal (space efficient) way to represent integers of unbounded length?
(The numbers range from zero to positive-infinity)
Some sample number inputs can be found here (each number is shown on it's own line).
Is there a compression algorithm that is specialized in compressing numbers?
You've basically got two alternatives for variable-length integers:
Use 1 bit of every k as an end terminator. That's the way Google protobuf does it, for example (in their case, one bit from every byte, so there are 7 useful bits in every byte).
Output the bit-length first, and then the bits. That's how ASN.1 works, except for OIDs which are represented in form 1.
If the numbers can be really big, Option 2 is better, although it's more complicated and you have to apply it recursively, since you may have to output the length of the length, and then the length, and then the number. A common technique is to use a Option 1 (bit markers) for the length field.
For smallish numbers, option 1 is better. Consider the case where most numbers would fit in 64 bits. The overhead of storing them 7 bits per byte is 1/7; with eight bytes, you'd represent 56 bits. Using even the 7/8 representation for length would also represent 56 bits in eight bytes: one length byte and seven data bytes. Any number shorter than 48 bits would benefit from the self-terminating code.
"Truly random numbers" of unbounded length are, on average, infinitely long, so that's probably not what you've got. More likely, you have some idea of the probability distribution of number sizes, and could choose between the above options.
Note that none of these "compress" (except relative to the bloated ascii-decimal format). The asymptote of log n/n is 0, so as the numbers get bigger the size of the size of the numbers tends to occupy no (relative) space. But it still needs to be represented somehow, so the total representation will always be a bit bigger than log2 of the number.
You cannot compress per se, but you can encode, which may be what you're looking for. You have files with sequences of ASCII decimal digits separated by line feeds. You should simply Huffman encode the characters. You won't do much better than about 3.5 bits per character.
I have a list in which each item has 2 integer attributes, n and m. I would like to map these two integer attributes to a single new attribute so that when the list is sorted on the new attribute, it is sorted on n first and then ties are broken with m.
I came up with n - 1/m. So the two integers are mapped to a single real number. I think this works. Any better ideas?
That's clever, so I hate to break it to you, but it won't work. Try it (with a computer) using the n=1,000,000,000 and values of m between 999,999,990 and 1,000,000,010. You'll find that n-1/m is the same value for all of those cases.
It would work if floating point numbers had infinite precision, or even if they had twice as much precision as an int (although even there you might run into some issues), but they don't: a double precision floating point number has 53 bits of precision. An integer is (probably) 32 bits, so you'd need at least 64 bits to encode two of them. But then, you could just use a 64-bit (long long) integer, encoding the pair as n*2^32 + m.
Generally in programming, the floating point data types should not be compared for equality since the values stored are very often an approximation.
Can two non-integer Oracle NUMBER values be compared reliably for equality since they are stored differently (base-10)?
Yes, Oracle NUMBER types are precise. They're more like integers with a scale than float/double types. So a NUMBER(10,3) has 10 digits, 3 after the decimal point, which is really a 10 digit integer with a scale of 3. In fact, that's precise how Java BigDecimals work (being a BigInteger plus a scale internally).
Oracle NUMBER types are stored as sets of centesimal digits (that is base 100, not base 10), one digit per byte.
The first byte represents the exponent, other bytes represent mantissa.
That means that for extremely large numbers, even the integer numbers can be rounded:
SELECT 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 -
10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
FROM dual
---
0
Oracle guarantees 38 digits of precision in a NUMBER, although 40 can be represented. See Oracle Concepts for a reference.