factorial and exponent

[Thomas]

I want to calculate the value of 126 raise to the power 126 in turbo
C.
I've checked it with unsigned long int but it doesn't help.
So how could one calculate the value of such big numbers?
What's the technique?

 

[Army1987]

I want to calculate the value of 126 raise to the power 126 in turbo
C.
I've checked it with unsigned long int but it doesn't help.
So how could one calculate the value of such big numbers?
What's the technique?

1. Use another programming language, or
2. find a bignum library, or
3. don't compute it. Compute its base-10 log. The integer part will
be the exponent, and from the fractional part you can find out the
mantissa.

<ot> log10(126**126) = 126 * log10(126) </ot>
printf("%fe%d", pow(10, x - floor(x)), (int)floor(x));

where x is 126 * log10(126).

HTH.

 

[Richard Heathfield]

In this article, I use ^ to represent "to the power of", rather than as
XOR.

Thomas said:

I want to calculate the value of 126 raise to the power 126 in turbo
C.
44329076602207821491972574571700100562486647339617150064334557177890\
43517106373872170818953941792055669609014893218047089803712563472169\
06583373889953014265747680923405829337012685381706863104615274196776\
3913240019546541793769190722594113575550312228000452759781376

I've checked it with unsigned long int but it doesn't help.

Since the largest value you are likely to be able to store in an
unsigned long int in Turbo C is 4294967295, it's hardly surprising that
you can't represent 126^126 in that type.

So how could one calculate the value of such big numbers?
What's the technique?

How would you do it by hand?

To save you some work, you'd probably start off by observing that
126^126 =
(126^63)^2 =
((126^31)^2*126)^2 =
(((126^15)^2*126)^2*126)^2 =
((((126^7)^2*126)^2*126)^2*126)^2 =
(((((126^3)^2*126)^2*126)^2*126)^2*126)^2 =
((((((126^2)*126)^2*126)^2*126)^2*126)^2*126)^2

So if you can multiply a number by itself, and multiply a number by 126,
you can get your result quite quickly.

See Knuth's "The Art of Computer Programming", volume 2, for information
on how to multiply two arbitrarily large numbers.

Alternatively, learn how to use GNU's GMP package, or Miracl, both of
which have C bindings.

 

[CBFalconer]

I want to calculate the value of 126 raise to the power 126 in
turbo C. I've checked it with unsigned long int but it doesn't
help. So how could one calculate the value of such big numbers?
What's the technique?

First, decide what holds the answer. You will need in the order of
1000 bits. Probably at least two of them.

 

[BiGYaN]

I want to calculate the value of 126 raise to the power 126 in turbo
C.
I've checked it with unsigned long int but it doesn't help.
So how could one calculate the value of such big numbers?
What's the technique?

Use GMP library found in http://gmplib.org/
It will enable you to do "Arithmetic without Limitations" !!

 

[Richard Heathfield]

BiGYaN said:

Use GMP library found in http://gmplib.org/
It will enable you to do "Arithmetic without Limitations" !!

Nonsense.

Consider an integer greater than or equal to 2. Call it A. Consider
another integer greater than or equal to 2. Call it B.

Raise A to the power B, storing the result in A. Now raise B to the
power A, storing the result in B. If you repeat this often enough, you
*will* hit a limit, no matter what numerical library you use.

 

[Army1987]

BiGYaN said:


Nonsense.

Consider an integer greater than or equal to 2. Call it A. Consider
another integer greater than or equal to 2. Call it B.

Raise A to the power B, storing the result in A. Now raise B to the
power A, storing the result in B. If you repeat this often enough, you
*will* hit a limit, no matter what numerical library you use.

But it is a limit of your computer, not of the library itself.

 

[Flash Gordon]

Army1987 wrote, On 17/06/07 09:48:

But it is a limit of your computer, not of the library itself.

If it uses space allocated with malloc/realloc, then the library (rather
than the computer) has a limit because even with an infinite computer
size_t and pointers are of defined finite size, so you can only have a
block of known finite size and you can only chain a finite number of
such blocks together with pointers.

Of course, this applies to all libraries written in C.

It is also very important for people learning to be programmers (or who
already are programmers) to understand that in the real world resources
are always limited, so there is no such thing as "without limitations".

 

[Richard Heathfield]

Army1987 said:

But it is a limit of your computer, not of the library itself.

Nevertheless, it is a limit, and therefore the library *cannot* 'enable
you to do "Arithmetic without Limitations"', and therefore BiGYaN's
statement is nonsense.

Incidentally, you've just emerged from a 30-day spell in my sin bin. I
hope I won't have to chuck you back in there.

 

[BiGYaN]

BiGYaN said:



Nonsense.

Consider an integer greater than or equal to 2. Call it A. Consider
another integer greater than or equal to 2. Call it B.

Raise A to the power B, storing the result in A. Now raise B to the
power A, storing the result in B. If you repeat this often enough, you
*will* hit a limit, no matter what numerical library you use.

"Arithmetic without Limitations" is sort of a slogan for GMP (http://
gmplib.org/). That's why I just put it in quotes.

The case that you are talking about does not show the limitation of
the numerical library. It's a limit of your computer. Besides, for all
*practical purposes* you won't hit this limit in a modern computer.
Like I'm quite sure that nobody will actually need all the digits of
126^126 for any *practical* job.

 

[Johan Bengtsson]

Army1987 said:

Nevertheless, it is a limit, and therefore the library *cannot* 'enable
you to do "Arithmetic without Limitations"', and therefore BiGYaN's
statement is nonsense.

Incidentally, you've just emerged from a 30-day spell in my sin bin. I
hope I won't have to chuck you back in there.

Of course there are limits, but I don't agree that they necessarily have
to be in the library. size_t is one limit, but if run on for example a
windows box it will not be *the* limit. A win32 application is not
allowed to allocate more than 2Gbytes of memory (and that's typically
half of what size_t allows for), unless you buy a more expensive version
of windows where that limit is raised to 3Gbytes.
It would also be possible for the mathematics library to internally use
something else than a standard C pointer and internally use paging
towards the system's hard disk or some internet based server or whatever
(magnetic tape?) allowing for a *much* higher limit. Oh well the limit
will still be there somewhere, but the calculation time will probably be
the limiting factor instead...

No, I don't seriously suggest using magnetic tape as a paging media...
but it would be possible!

 

[Johan Bengtsson]

Army1987 said:

Nevertheless, it is a limit, and therefore the library *cannot* 'enable
you to do "Arithmetic without Limitations"', and therefore BiGYaN's
statement is nonsense.

Of course there are limits, but I don't agree that they necessarily have
to be in the library. size_t is one limit, but if run on for example a
windows box it will not be *the* limit. A win32 application is not
allowed to allocate more than 2Gbytes of memory (and that's typically
half of what size_t allows for), unless you buy a more expensive version
of windows where that limit is raised to 3Gbytes.
It would also be possible for the mathematics library to internally use
something else than a standard C pointer and internally use paging
towards the system's hard disk or some internet based server or whatever
(magnetic tape?) allowing for a *much* higher limit. Oh well the limit
will still be there somewhere, but the calculation time will probably be
the limiting factor instead...

No, I don't seriously suggest using magnetic tape as a paging media...
but it would be possible!

 

[Richard Heathfield]

BiGYaN said:

"Arithmetic without Limitations" is sort of a slogan for GMP (http://
gmplib.org/). That's why I just put it in quotes.

It's still false, within quotes or without them.

The case that you are talking about does not show the limitation of
the numerical library. It's a limit of your computer.

It's still a limit.

Besides, for all
*practical purposes* you won't hit this limit in a modern computer.

It's still a limit.

Like I'm quite sure that nobody will actually need all the digits of
126^126 for any *practical* job.

Cryptography springs to mind as a practical application which requires
exactness to the very last digit for calculations involving numbers of
that size and indeed greater.

 

[Richard Heathfield]

Johan Bengtsson said:

Of course there are limits, but I don't agree that they necessarily
have to be in the library.

I'm not saying they are, but that's not the issue. The claim was that
the library allows you to do arithmetic without limitations, and all
I'm saying is that that claim is false.

 

[BiGYaN]

Cryptography springs to mind as a practical application which requires
exactness to the very last digit for calculations involving numbers of
that size and indeed greater.

Thanks for informing .... I really had no idea. I take back my comment.

 

[Army1987]

Army1987 said:

Nevertheless, it is a limit, and therefore the library *cannot* 'enable
you to do "Arithmetic without Limitations"', and therefore BiGYaN's
statement is nonsense.

If you cannot compute a number n with a computer, you can always
(at least in principle) use a computer with a larger size_t and
compute it.
Your statement is much like "You cannot use the long division
algorithm indefinitely because sooner or later you'll run out of
paper", or "There is a N such as you cannot draw a regular
(2^N * 3 * 5 * 17 * 257 * 65537)-gon with straightedge and compass,
because even if the polygon were as large as the universe, each
side would need to be shorter than a Planck length".
The library does enable Arithmetic without Limitations. It is the
implementation (and the universe) which put the limits.

 

[JT]

If you cannot compute a number n with a computer, you can always
(at least in principle) use a computer with a larger size_t and
compute it.
Your statement is much like "You cannot use the long division
algorithm indefinitely because sooner or later you'll run out of
paper", or "There is a N such as you cannot draw a regular
(2^N * 3 * 5 * 17 * 257 * 65537)-gon with straightedge and compass,
because even if the polygon were as large as the universe, each
side would need to be shorter than a Planck length".

The library does enable Arithmetic without Limitations. It is the
implementation (and the universe) which put the limits.

No. By your same argument, I can say this method
below "enables arithmetic without limitations":

int add(int a, int b) { return a+b; }
int sub(int a, int b) { return a-b; }

Because you can always build a C compiler that
provides a larger "int" size.

(For example, 32-bit C compilers use multiple
operations to simulate 64-bit integer operations.
The C compiler can double that up to simulate
128-bit, 256-bit, or in did even a much larger
bitwidth)

My two objections:

(1) That library does not "enable" unlimited arithmetic.
The library itself does not "impose" additional limit.

(2) People are confused between infinite,
and finite bounded. People should read more math books.

- JT

 

[JT]

(2) People are confused between infinite,
and finite bounded.

Sorry, of course, I meant "finite unbounded".

- JT

 

[Army1987]

If you cannot compute a number n with a computer, you can always
(at least in principle) use a computer with a larger size_t and
compute it.
Your statement is much like "You cannot use the long division
algorithm indefinitely because sooner or later you'll run out of
paper", or "There is a N such as you cannot draw a regular
(2^N * 3 * 5 * 17 * 257 * 65537)-gon with straightedge and compass,
because even if the polygon were as large as the universe, each
side would need to be shorter than a Planck length".

The library does enable Arithmetic without Limitations. It is the
implementation (and the universe) which put the limits.

[snip]
My two objections:

(1) That library does not "enable" unlimited arithmetic.
The library itself does not "impose" additional limit.

(2) People are confused between infinite,
and finite unbounded. People should read more math books.

[correction incorporated above]

Indeed, I'm not saying that "Arithmetic without Limitations" means
that the library allows arithmetic with transfinite cardinals, only
that it allows arithmetic with arbitrarily large natural (finite)
numbers.
If there are indeed limits, they are due to the implementation.
Wait for a computer with more memory, and you'll be able to compute
larger numbers.

By your argument, the long division algorithm does not "enable" you
to divide arbitrarily large numbers, it just doesn't "impose"
additional limit (to that dictated by the size of the paper sheet
you work on).

 

[Richard Heathfield]

Army1987 said:

"Richard Heathfield" ha scritto...

If you cannot compute a number n with a computer, you can always
(at least in principle) use a computer with a larger size_t and
compute it.

No, in principle you'll run out of resources at some point.

Your statement is much like "You cannot use the long division
algorithm indefinitely because sooner or later you'll run out of
paper",
Correct.

or "There is a N such as you cannot draw a regular
(2^N * 3 * 5 * 17 * 257 * 65537)-gon with straightedge and compass,
because even if the polygon were as large as the universe, each
side would need to be shorter than a Planck length".
Correct.

The library does enable Arithmetic without Limitations.

No, it doesn't. To do so, it would have to remove all limitations on
arithmetic, and it simply can't.

It is the
implementation (and the universe) which put the limits.

And therefore the limits are there. If the library does not remove them,
it does not enable arithmetic without limits.