Richard Heathfield suggested bit-shifting, and for your problem this willwork just fine. However, it is [very!] suboptimal, even in the case youproposed.The key issue -- and it is the same situation for addition, subtraction, andmultiplication -- is that the processor inherently has integer addition,subtraction, multiplication and division instructions; but they handleoperands smaller than you are interested in.The key question is whether it is possible to use these "small" instructionsmultiple times to deal with larger operands.In the case of addition and subtraction, the answer is clearly YES. Even ifone is programming in ''C'' and doesn''t have direct access to the CARRY bit ofthe processor, if the result of an addition is smaller than either of theinput arguments (which must be unsigned), then a carry occurred. With alittle thought, one can code multi-precision integer addition that doesn''tperform badly (although it won''t be as efficient as assembly-language).For example:unsigned int input1[2]; /* LSI first for all of these */unsigned int input2[2];unsigned int output[3]; /* Result has one more int to hold carry out. */unsigned int carryout[1];output[0] = input1[0] + input2[0];if ((output[0] < input1[0]) || (output[0] < input2[0]))carryout[0] = 1;elsecarryout[0] = 0;output[1] = input1[1] + input2[1];if ((output[1] < input1[1]) || (output[1] < input2[1]))output[2] = 1;elseoutput[2] = 0;/* Now, process the carry out of the LSI */if (carryout[0]){output[1] ++;if (! output[1])output[2] ++;}I don''t claim that I didn''t make some kind of mistake in the above (I''mdoing this from scratch). The bottom line is that one can do addition andsubtraction of large integers in ''C'' fairly effectively.Note that the solution above uses the inherent ability of the processor toadd using native machine instructions.The solution suggested by Richard Heathfield is just as crude as doingaddition one bit at a time (compared to the technique above).I won''t get into multiplication ... but there is a way to do that using theprocessor''s multiplication ability, too. You''ll figure it out quickly ifyou think about it.And finally, division ... which is the toughest case.If you try to do the algebra and figure out if you can use "small" machinedivision instructions to accomplish a larger division, you''ll rapidly cometo the conculsion that you can''t. (Fortunately, Donald Knuth and his peersare just a bit more experienced than you or I. It ends up there is a way todo it.)The process is very similar to the way people do longhand division. Inlonghand division, people estimate one digit at a time, then multiply andsubtract, then go on to the next digit. Occasionally, one guesses wrong andhas to increase or decrease the quotient digit and re-do that digit.In the algorithm, a "digit" is 16-32 bits; and the result of estimation maybe off by as much as 2 counts in one direction only (there is a simple andcheap correction procedure).The classic algorithm assumes that the machine has a division instructionthat takes a dividend of bitsize 2w, divides it by a divisor of bitsize w,and produces a quotient of bitsize w and a remainder of bitsize w, with thepossibility of overflow (which is deliberately avoided by the algorithm).For a typical desktop processor, w is 32 bits, so that in one machineinstruction you can do a 64/32 division. However, typically compilers willonly allow you to do a 32/32 division, so you have to use w=16 and apply thestandard algorithm.The algorithm essentially will produce 16 bits of the result at a time(versus 1 bit at a time from the bit-shifting approach).If you have access to the assembly-language of the machine, normally you canget [at least] 32 bits at a time.The standard integer division algorithm is a bit awkward to code in ''C'', butwhen the data sizes are known in advance (as they are in your case), it getsless awkward.I won''t include the code here (too much thought would be required).Here are the resources you should look up.a)Knuth covers this in Volume 2 of his classic work: http://www.amazon.com/Art-Computer-P...e=UTF8&s=booksb)The GMP has some division code that is compiled in the eventassembly-language isn''t available for the specific processor. This will usethe "digit estimation" technique I described.c)Also, this URL should be helpful. It also cites Knuth. http://en.wikipedia.org/wiki/Arbitra...ion_arithmeticHeathfield''s suggestion will work just fine. However, in the general case,you don''t want to do that.Dave. 这篇关于分裂问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持! 上岸,阿里云!