Greetings to everyone,

If we take a processor with 16bit precise ALU and try to compute a
factorial (n!) form 2^80, what happens with ALU then? To be more precise,
does ALU width (precision) limits it from computing numbers higher than it
can allocate and how (if?) does it impacts performance of integer
computing? In other words, how come it is possible to compute very large
number if ALU is not precise enough for them (or my calculator is being
dishonest).

I hope I made my point clearly enough. Thanks in advance.


--
Kupio sam pistolj od svercera na crno,
Na tebe cu rado da potrosim zrno...

Bitstring <Xns960DE2CE896C7bubbachipsetone@130.133.1.4>, from the
wonderful person Bubba <(E-Mail Removed)> said
>Greetings to everyone,
>
>If we take a processor with 16bit precise ALU and try to compute a
>factorial (n!) form 2^80, what happens with ALU then? To be more precise,
>does ALU width (precision) limits it from computing numbers higher than it
>can allocate and how (if?) does it impacts performance of integer
>computing? In other words, how come it is possible to compute very large
>number if ALU is not precise enough for them (or my calculator is being
>dishonest).

All sensible math packages (for big numbers) break the calculation up
into smaller sized (i.e. 16 bit, 32 bit, whatever) pieces. Some simple
ones designed for very long numbers actually work in binary coded
decimal, and do long multiplication the 'very hard' way.

BTW, even 16 bit ALUs generally have a 16bit*16bit multiply, which will
give a 32 bit answer (in two registers).

Google is your friend (and yep, this sounds suspiciously like a homework
assignment, so hints is all you get).

--
GSV Three Minds in a Can
SC recommends the use of Firefox; Get smart, or get assimilated.

Bubba wrote:
> Greetings to everyone,
>
> If we take a processor with 16bit precise ALU and try to compute a
> factorial (n!) form 2^80, what happens with ALU then? To be more precise,
> does ALU width (precision) limits it from computing numbers higher than it
> can allocate and how (if?) does it impacts performance of integer
> computing? In other words, how come it is possible to compute very large
> number if ALU is not precise enough for them (or my calculator is being
> dishonest).
>
> I hope I made my point clearly enough. Thanks in advance.

The really large numbers (or the really small ones too) are worked on
inside the FPU rather than the ALU. The floating point unit gives up
some level of precision for some flexibility in estimation.

Yousuf Khan

In article <Xns960DE2CE896C7bubbachipsetone@130.133.1.4>,
(E-Mail Removed) says...
> Greetings to everyone,
>
> If we take a processor with 16bit precise ALU and try to compute a
> factorial (n!) form 2^80, what happens with ALU then? To be more precise,
> does ALU width (precision) limits it from computing numbers higher than it
> can allocate and how (if?) does it impacts performance of integer
> computing? In other words, how come it is possible to compute very large
> number if ALU is not precise enough for them (or my calculator is being
> dishonest).

The same way you do arithmetic only knowing the 9x9 tables.

--
Keith

On Wed, 02 Mar 2005 22:46:18 -0500, Yousuf Khan <(E-Mail Removed)>
wrote:

>Bubba wrote:
>> Greetings to everyone,
>>
>> If we take a processor with 16bit precise ALU and try to compute a
>> factorial (n!) form 2^80, what happens with ALU then? To be more precise,
>> does ALU width (precision) limits it from computing numbers higher than it
>> can allocate and how (if?) does it impacts performance of integer
>> computing? In other words, how come it is possible to compute very large
>> number if ALU is not precise enough for them (or my calculator is being
>> dishonest).
>>
>> I hope I made my point clearly enough. Thanks in advance.
>
>The really large numbers (or the really small ones too) are worked on
>inside the FPU rather than the ALU. The floating point unit gives up
>some level of precision for some flexibility in estimation.
>

Stirling's approximation.

http://mathworld.wolfram.com/Stirlin...oximation.html

RM