long long vs double?

[coolgod]

long long vs double?
i always they were the same when it came integer operations but when doing an usaco question http://hi.baidu.com/leokan/blog/item/727307463c56d40d6a63e562.html
today I realized they had some difference. I spend 3 hrs debugging my code only to find if i change one variable from long long to double it magically gets me the right answer.
The variable isn't being used to numbers as big as 2^63,
max is like 30 choose 16.
I implemented the smart way to do choosing doing and didn't even go up to that big number.
I tried long long, int64_t to declare my variable and still doesn't work.
In theory the data type is 64 bit, or approximately 2^63-1, it should hold my numbers well. I even tried unsigned long long and it doesn't work. How comes double works? I'm using codeblock with i think last 3 year's version of gcc.

[Tony]

well for one long long is an integer type, while double is a floating point type.

[DemonWasp]

Double will hold considerably larger numbers (with reduced precision) than an integer type. For example, you can't store numbers above 2^64 in a 64-bit integer, but a double (of the same size) can store well above 10 ^ 200 (though not terribly precisely).

If any intermediate number (such as computing n!) is above what integers can represent, you'll have an overflow problem at that point, which will be corrected by choosing double. For example, "30!" is well over 2 ^ 100, and therefore cannot be stored in a 64-bit integer. A more correct solution for problems such as (a choose b) is to cancel factors without computing, when possible: for example, 30 choose 16 does require you to compute 30 x 29 x ... x 17, but you don't have to continue all the way to one.

[coolgod]

i did choosing using this way "A more correct solution for problems such as (a choose b) is to cancel factors without computing, when possible: for example, 30 choose 16 does require you to compute 30 x 29 x ... x 17, but you don't have to continue all the way to one." the divided the other factors.
I understand how doubles are implemented underneath, because of fraction and exponents bits, and how precision works.
So you're suggesting i happened to get the answer correct because it's a number with a bunch of 2's in the factor, thus the lost precision from double implementation happened to round correctly in the end?
I think that's the correct answer cause 30x 29 .....x15 turns out to be a 3.04264807 * 10^21 which happens to be greater than (2^64)-1
I believe the more elegant solution used pascal's triangle to calculate it.

[DemonWasp]

Precision in doubles is...complicated. I haven't taken the course that covers that yet (University 3rd-year CS), so my understanding isn't particularly detailed or accurate yet.

It would certainly be possible to calculate using Pascal's triangle; the O(n * k) runtime is pretty excellent, and doesn't involve any unreasonably-large intermediates.

[coolgod]

I found these 2 articles to be particular good read.
http://acm.uva.es/p/float-in-competition.pdf
http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
I spent a full two frustrated day getting what info i could from it.