Maybe someone should take the time to explain to Adak what the "loss of precision with floating point numbers" means, because none of the numbers in the screenshot are the same. Do you know what "not the same" means? Hint: Not "Correct!"
Quzah.
Maybe someone should take the time to explain to Adak what the "loss of precision with floating point numbers" means, because none of the numbers in the screenshot are the same. Do you know what "not the same" means? Hint: Not "Correct!"
Quzah.
Hope is the first step on the road to disappointment.
I thought you were arguing for more zero's in the mantissa of the number, of course, Claudiu.
PhD's program produces the correct amount of zero's, you will note.
I agree with what you say, but I don't know if this algorithm can be extended to arbitrary precision, or not.
My wristwatch and clocks, are not able to give PERFECT time, either, but the approximation, is quite sufficient. I don't know what the limits are to the accuracy of this algorithm.
So I'm making no judgments about that.
Last edited by Adak; 04-21-2010 at 12:39 AM.
He posted a list of numbers, not scientific notation, that are wrong. It doesn't matter how far you drag out the notation if all you're doing is approximating things. Approximating is guessing. If we wanted a guess, we wouldn't have been up in arms when he started calling us all stupid for saying that anything beyond 12 or 13 wouldn't fit in a long any more.Originally Posted by Adak
Quzah.
Hope is the first step on the road to disappointment.
@Adak
Well, despite the fact that I haven't seen any code yet and the only credible source of information for me right now is the fact that I am confident that lying about the results is not something I would suspect you of, I will give out a bravo to PhD for his estimation. However, this does not prove his contradiction of my point that the value of the result cannot be stored in an integer type variable, nor does it prove how my statement that started this heated debate : "factorial(14) is larger than MAX_LONG on 32 bit systems" is wrong, NOR DOES IT EXCUSE HIS TROLLING!
As of now I will not give him any credit for this as I suspect that:
a) his work is not his own (but rather his coworkers)
b) his work is not entirely correct (although a good attempt)
Last edited by claudiu; 04-21-2010 at 12:43 AM.
Thanks, Claudiu. Those ARE the numbers, straight from the program. I just added some logic to line up the results so they could easily be checked against some numbers from Wiki.
Too bad you're both still wrong or lying. His numbers from page 1 weren't listed as an "approximation". This isn't approximating:If it is, he's not claiming it's approximation, and since nothing prior to that says it's approximation, you're both still just trying to talk yourselves out of a corner. Assuming there really are actually two of you.The factorial of i 35 is: 10333147966386144222209170348167175077888
Edit: And even if he is approximating, he's still not stepping up and doing it in "10 lines of C", and he's still not doing it in an int. He started spouting off about how claudiu had no idea what he was talking about for saying that the factorial of 14 didn't fit in a long int.
Fact remains he's a lying, trolling, tool who at the bare minimum owes claudiu an apology. If he wanted to pop up and say "I can approximate it using floats." then he should have been straightforward in saying that. Not just vomit a bunch of numbers and call everyone stupid and then try to weasel his way out of it, and get someone else to fight his fights for him.
You're either one in the same, or you're both liars and back-peddling idiots.
Quzah.
Last edited by quzah; 04-21-2010 at 01:17 AM.
Hope is the first step on the road to disappointment.
Well, I'm pretty sure Adak != Overworked_PhD if that's what you are implying.
However, I completely agree with your other statements. This is just a sloppy approximation of something that is a discrete clear value (although very large and probably difficult to compute).
I did provide a solution for calculating factorials for much higher numbers with 100% accuracy by representing each value as an array of digits. The multiplication process would be very tedious indeed but it would be possible, and you would end up with a precise result, even if it would be 200,300 and even more digits long.
It *IS* an approximation (at this time, with this program). Here's some more output from PhD's program:Well, I'm pretty sure Adak != Overworked_PhD if that's what you are implying
However, I completely agree with your other statements. This is just a sloppy approximation of something that is a discrete clear value (although very large and probably difficult to compute).
I did provide a solution for calculating factorials for much higher numbers with 100% accuracy by representing each value as an array of digits. The multiplication process would be very tedious indeed but it would be possible, and you would end up with a precise result, even if it would be 200,300 and even more digits long.
As is, it is accurate at lower values, but only an approximation at higher values.Code:factorial of i 10 is: 3628800 Correct 10! is: 3628800 factorial of i 15 is: 1307674368000 Correct 15! is: 1307674368000 factorial of i 20 is: 2432902008176640000 Correct 20! is: 2432902008176640000 factorial of i 25 is: 1.551121e+25 Correct 25! is: 1.5511210043e10^25 factorial of i 35 is: 1.033315e+40 Correct 35! is: 1.0333148e10^40 factorial of i 50 is: 3.041409e+64 Correct 50! is: 3.0414093202e10^64 factorial of i 70 is: 1.197857e+100 Correct 70! is: 1.1978571670e10^100 factorial of i 100 is: 9.332622e+157 Correct 100! is: 9.3326215444e10^157
Quzah, you should know very well that I would not bait or troll.
Well, not much, anyway!
I modified the program and then checked the output against the factorial table found in the CRC Math handbook. As far as I can tell, I got it correct.
And on a funny side note, my co-worker was able to get correct results up to 1000! on a his 32 by machine by just modifying two lines of my corrected C code.[cd@localhost oakland]$ ./task2
0! = 1
1! = 1
2! = 2
3! = 6
4! = 24
5! = 120
6! = 720
7! = 5040
8! = 40320
9! = 3.6288e+05
10! = 3.6288e+06
11! = 3.9917e+07
12! = 4.7900e+08
13! = 6.2270e+09
14! = 8.7178e+10
15! = 1.3077e+12
16! = 2.0923e+13
17! = 3.5569e+14
18! = 6.4024e+15
19! = 1.2165e+17
20! = 2.4329e+18
21! = 5.1091e+19
22! = 1.1240e+21
23! = 2.5852e+22
24! = 6.2045e+23
25! = 1.5511e+25
26! = 4.0329e+26
27! = 1.0889e+28
28! = 3.0489e+29
29! = 8.8418e+30
30! = 2.6525e+32
31! = 8.2228e+33
32! = 2.6313e+35
33! = 8.6833e+36
34! = 2.9523e+38
35! = 1.0333e+40
36! = 3.7199e+41
37! = 1.3764e+43
38! = 5.2302e+44
39! = 2.0398e+46
40! = 8.1592e+47
41! = 3.3453e+49
42! = 1.4050e+51
43! = 6.0415e+52
44! = 2.6583e+54
45! = 1.1962e+56
46! = 5.5026e+57
47! = 2.5862e+59
48! = 1.2414e+61
49! = 6.0828e+62
50! = 3.0414e+64
51! = 1.5511e+66
52! = 8.0658e+67
53! = 4.2749e+69
54! = 2.3084e+71
55! = 1.2696e+73
56! = 7.1100e+74
57! = 4.0527e+76
58! = 2.3506e+78
59! = 1.3868e+80
60! = 8.3210e+81
61! = 5.0758e+83
62! = 3.1470e+85
63! = 1.9826e+87
64! = 1.2689e+89
65! = 8.2477e+90
66! = 5.4434e+92
67! = 3.6471e+94
68! = 2.4800e+96
69! = 1.7112e+98
70! = 1.1979e+100
71! = 8.5048e+101
72! = 6.1234e+103
73! = 4.4701e+105
74! = 3.3079e+107
75! = 2.4809e+109
76! = 1.8855e+111
77! = 1.4518e+113
78! = 1.1324e+115
79! = 8.9462e+116
80! = 7.1569e+118
81! = 5.7971e+120
82! = 4.7536e+122
83! = 3.9455e+124
84! = 3.3142e+126
85! = 2.8171e+128
86! = 2.4227e+130
87! = 2.1078e+132
88! = 1.8548e+134
89! = 1.6508e+136
90! = 1.4857e+138
91! = 1.3520e+140
92! = 1.2438e+142
93! = 1.1568e+144
94! = 1.0874e+146
95! = 1.0330e+148
96! = 9.9168e+149
97! = 9.6193e+151
98! = 9.4269e+153
99! = 9.3326e+155
100! = 9.3326e+157
[cd@localhost oakland]$
> because, his program has produced correct factorials for 30!, 50!, 70! and 100!
Bull........!
Correct to a handful of decimal digits - what a laugh.
The red is where they match - the rest is random noise.
Which is coincidentally the number of decimal digits in a double.
There is no magic here, just sloppy coding and checking.
Printing out 300 digits of a double does NOT make it accurate to 300 digits.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Mijo, I see no double here.Code:unsigned long i; for (i = 1; i <= n; i++) acc *= i; return acc;
rofl!
Go on - post your code!
What's your PhD in - stalling for time?
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Computational Fluid Dynamics.
I agree with the general sentiment of Overworked_PhD's post #7: it would be nice if systemcell stated the requirements for the range of n, as well as whether an approximation will suffice.
In the meantime, I suspect that the discussion has gotten further and further from the point where systemcell will be able to understand it, at least for the time being.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
