How can I represent the output of 250500*250500 in 32-bit word?

Question

We have 250500*250500 = 62,570,250,000. How can we represent this using low and high? I know that the biggest number that can be represented in 32 bits is 4,294,967,295 (2^32 - 1)

Answer 1

In binary, 250500*250500 = 62,570,250,000 looks like:
‭0011 1101 0010 1000 0100‬ * ‭0011 1101 0010 1000 0100‬ =
0110 1001 1100 0011 0100 1101 0100 0001 0000‬

Solid rules of math say that you can fit the results of an 18 bit number, times an 18 bit number, into 36 bits. Solid rules of math state that you cannot necessarily reduce bits from compression, so there are some limits you may have to deal with.

Still, there may be some options.

A computer could be used to keep track of meters... or kilometers.
If you kept track of the concept of 50 kilometers, that's effectively the same as keeping track of 50,000 meters.
Similarly, instead of keeping track of 250500*250500 = 62,570,250,000 (meaning, 250,500 single units x 250,500 single units), you could keep track of deca-units, e.g., 25050x25050 = 627,502,500 (250,500 decaunits x 250,500 deca-units = 627,502,500 square deca-units). The number 627,502,500 will fit within a 32-bit word.

A skilled computer programmer should consider what the computer's memory represents (e.g., if a piece of memory is storing information about units or deca-units), and consider making adjustments if there are benefits (such as working around limitations, or maybe just operating with faster speed).

Maybe instead of keeping track of deca-units (which are groups of 10 units), you may want to keep track of groups of units that are a different size, such as groups of 500 units. The concept is that if you know that your numbers will always be even, then you can divide numbers by two and potential with smaller units. (Although, you would need to divide by more than 2 to get under the specific maximum value of 4,294,967,295.) If you can keep track of hecto-units (100 units each), instead of 250,500*250,500 you would have 2,505*2,505=6,275,025 (12 bits times 12 bits, which could require 24 bits to store a result, but happens to only require 23 bits for this particular case). If you can keep track of quinquehecto units (500), you would have 501*501=251,001 (9 bits times 9 bits, stored in 18 bits).

Whether you can find a useful pattern is one aspect of useful programming that goes beyond just familiarity with a programming language. Pulling this off often depends on what real-world concept you are trying to keep track of, and the feasibility (and details of the implementation) can vary between different real-life scenarios.

Edit: Minor correction. Also expanded paragraph about 500 units to show actual numbers as a demonstration.

Answer 2

The question currently says: "We have 250500*250500 = 62,570,250,000."

Well, this is complete and utter nonsense.
250500*250500 = 62,570,250,000. (WRONG MATH specified in the question)
250500*250500 = 62,750,250,000. (RIGHT MATH, what the question probably meant to ask)

This was throwing off some of my calculations. If we assume a typo, and correct for it, then I can provide this answer for 62,750,250,000.

The simple, straightforward answer to the question is: storing a smaller number along with a power. That's the answer, condensed into a small number of words. That answer probably requires some explanation, which is why I provide the remainder of this text.

25,500 is 18 bits.
2 is one bit.
That requires 19 bits total. That is 32-bits. That works.

Actually, this way of thinking is quite similar to how an x86 CPU (80387 and newer) keeps track of floating point numbers, using some bits as a Significand.

The question did not specify that 62,570,250,000 needs to be stored as a direct number. The first thing that could be done is to try square-rooting it, and seeing if the result is an integer. The result is an integer, and so there is a perfectly valid solution available. This solution successfully permits storing some numbers as large as 549,755,748,352 (which is equal to 8,388,607 * 65,536, a.k.a. 8,388,607 * (two raised to the 16th power)). One of the numbers that this system can accurately represent is
62,750,250,500
even though this same system would not be able to store
62,750,250,499

That's okay, though, because the question didn't require storing all possible smaller numbers. The question simply wanted a way to represent the number 62,750,250,500. That is perfectly doable.

So, the bits you store are:
0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 1 0 1 0 0 0 0 1 0 0‬

Using a technique similar to the common IEEE floating point assembly, these bits could get interpreted as:

• a positive number (first bit)
• 25500 (bits 10 through 32)
• which gets multiplied by itself one time
  • Because... "1" is the value of bits 2 through 9.

Note that bits 2 through 8 and 10 through 14 are leading zeros. That's 7+5=12 bits that aren't being very effective in this case. If positive numbers are assumed, that's 13 bits that may be a bit ineffective/inefficient for this particular case, so there could be potential that these could be used differently. (Remember earlier I said we needed 19 out of the 32 bits. 13+19=32.)

The idea here is that there's no need to store "output" as a large number, when you know that this number can easily be represented as a power of two. The value of 62,750,250,000 is effectively being stored, and the way it is represented is by storing a smaller number along with a power. Essentially, we are storing data which, if combined with a known formula that we specified, allows us to store this particular number. (This formula reasonably might end up being useful for storing other numbers, in a situation where people are often dealing with squared numbers.)

Note: This system is somewhat similar, but is NOT the same, as IEEE's floating point system which I've seen discussed in a University Assembly class focused on x86 Assembly. Here is a hyperlink to an online converter for IEEE floating point which you could use for that system. In that system, the bits for the exponent specify what power of 2 is used to multiply the remaining bits. However, that doesn't fit this case, as 25,500 is not a power of two. Trying to use IEEE's floating point system, we could find that 62,750,250,000 divided by 16 is 3,921,890,625. So we could represent the number as 3,921,890,625 times (two raised to the fourth power). Still, we would need 36-bits, which is larger than the 32-bits asked about (and larger than the 24 bits that Intel's coprocessors use for storing the non-exponent version of the number).

I might have largely ignored the "using low and high" part of the question. I wasn't very clear on just what the question is asking. However, this system does use different bits for different purposes, and so that exponent section of the data could be considered "higher" bits than the other bits placed at a lower position. So, the question "How can we represent this" is directly answered by the bold sentence, and explained further with the rest of this answer.