Number of digits in N!

[Elijah Cardon]

But an isomorphism always exist. Or, atleast an isometry. y = ax + b and
even y = b are simple isomorphism in a group(and hence a ring and field)
that let you get all the other elements.

f(x) = ax + b;

hence f(x + y) = a*(x+y) + 2b = a*x + b + a*y + b = f(x) + f(y)

hence f(x) is a homeomorphism and its obvious thats its an isomorphism.

I don't think the topological content of the problem relevant and would
think that homeo- is properly homo- . That's a very faggy thing to say, so
I'll anounce that I'm shutting off my computer to go out and look for a girl
who looks like Dean Neuman's daughters. EC

 

[Willem]

Chris wrote:
) Willem wrote:
)> Logan wrote:
)> ) Any given integer can be represented in a finite number of bits. The
)> ) same is not true for any particular given logarithm. Some of them
)> ) (such as log2(256)) can be represented in a finite number of bits, but
)> ) some of them cannot.
)>
)> Well, you can't even represent 1/3 in a finite number of bits, then.
)
) Sure you can: with a `ratio` object with numerator 1 and denominator 3:

In that case you can also represent any given logarithm in a finite number
of bits. I didn't end my sentence above with 'then' for nothing you know.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[jmcgill]

Logan wrote:
) Any given integer can be represented in a finite number of bits. ....
Well, you can't even represent 1/3 in a finite number of bits, then.

1/3 is not an integer.

 

[Richard Heathfield]

jmcgill said:

1/3 is not an integer.

It's actually an int, with the value 0 - integer division, remember!

 

[Clark S. Cox III]

Logan wrote:
) Any given integer can be represented in a finite number of bits. The
) same is not true for any particular given logarithm. Some of them
) (such as log2(256)) can be represented in a finite number of bits, but
) some of them cannot.

Well, you can't even represent 1/3 in a finite number of bits, then.

Sure you can. For example, in ASCII, it's "1/3". That's 24 bits.

 

[Joe Wright]

Sure you can. For example, in ASCII, it's "1/3". That's 24 bits.

#include <stdio.h>
int main(void) {
char a[] = "1/3";
printf("%d\n", (int)sizeof a);
return 0;
}
...says 4 which is 32 bits, right?

 

[Arthur J. O'Dwyer]

Sure you can. For example, in ASCII, it's "1/3". That's 24 bits.

#include <stdio.h>
int main(void) {
char a[] = "1/3";
printf("%d\n", (int)sizeof a);
return 0;
}
..says 4 which is 32 bits, right?

(Oh boy, crossposts to c.l.c that assume CHAR_BIT==8!
I think your compiler needs some helpful hints. Try

#include <stdio.h>
int main(void) {
char a[3] = "1/3";
printf("%d\n", (int)sizeof a);
return 0;
}

/* ;-) */

-Arthur

 

[Ben Rudiak-Gould]

No, the straightforward algorithm involves only rational numbers (which
can be represented with a finite amount of information) and thus never
needs to suffer from rounding errors. The log-based one must suffer from
rounding errors since it involves irrational numbers (which require an
infinite amount of information to be represented directly).

Reading this subthread, I get the strong impression that many people have
never heard of the notion of computable reals. Search the web for "exact
real arithmetic" or "computable real arithmetic" and you'll find many
libraries that will let you compute (sum_{i=1}^{N} log i) without roundoff
just as easily as GMP lets you compute (prod_{i=1}^{N} i) without wraparound.

-- Ben

 

[Willem]

Ben wrote:
) Reading this subthread, I get the strong impression that many people have
) never heard of the notion of computable reals. Search the web for "exact
) real arithmetic" or "computable real arithmetic" and you'll find many
) libraries that will let you compute (sum_{i=1}^{N} log i) without roundoff
) just as easily as GMP lets you compute (prod_{i=1}^{N} i) without wraparound.

Well then, just for the sake of argument, and keeping the OP in mind:

How exactly would such a library compute log10(7)+log10(8) ?


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Jon.Slaughter]

Hello.

Is there a method for computing the number of digits, in a given numeric
base, of N factorial, without actually computing the factorial?

For example, 8! has 5 digits in base 10; 10! has 7 digits in base 10.
Is there a way to compute that information without actually evaluating
the factorial?

I just found a formula in a book that might produce a very good
algorithm:

log(n!) = sum([n/p^k]*log(p))

where the sum runs over all p^k <= n and [ ] is the floor function.
This does require you to know all primes up to n though but this could
be in a lookup table.

so log(6!) = log(2)*([6/2] + [6/2^2]) + log(3)*[6/3] + log(5)*[6/5]

Ofcourse this sum isn't much different than sum(log(k),k=2..6) = log(2)
+ log(3) + log(4) + log(5) + log(6) for small n but might be pretty
good for large n since these primes are not very dense in the integers.

Anyways, I thought I'd throw it out there as its quite an interesting
formula.

Jon