[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]
2023-11: Warosu is now out of extended maintenance.

/sci/ - Science & Math

View post   
File: 350 KB, 859x626, Porgr.png [View same] [iqdb] [saucenao] [google]
3956885 No.3956885 [Reply] [Original]

Alright /sci/, I posted this about 4 days ago, and even though some came close, no actual solution had been found.

So, let's try to get it this time, I hope you programmers out there can help me.

How to find all the answers to the equation in the pic (a^3 + b^4 = c^5) for c ≤ 10000 (so, all the answers up to a 10000) and display them in a list. God tier would be to only display whole numbers (no decimals) in the list (because those are the solutions I'm looking for).

Please help!

>> No.3956905

Are you retarded?
Any monkey can code three for-loops.
As a programming task this shit is ridiculous, though the mathematical procedure of finding solutions would be interesting. But that's not what you're asking for.

>> No.3956904

Presumably a must also be positive.

>> No.3956918

>>3956904
Exactly.

>>3956905
I'm sorry, but that is why I'm asking for help. Maybe you can help me out, if this is as easy as you say it is (we already discussed a method in a different thread, that was interesting indeed, but I really need some programmers in here. Would appreciate your help too, if you could)...

>> No.3956923

>>3956905
If you're so smart, then HELP.

>> No.3956927

If the problem is to return a list of values which satisfy this, then the answer is simple. Return the empty list.

>> No.3956933

Go through all triples of integers, print if they form a solution.

>> No.3956938

double result

for(int a=0;a< 4 641588; a++)
for(int b=0;;b++){
result = pow(pow(a,3)+ pow(b,4), (float)(1/5));
if(result < 10000 && (int)result == result)
cout<< ", a = " << a << ", b= " << b << ", c= " << c;
else
break;
}
}

There's probably a way to optimize this I haven't thought of yet.

>> No.3956954

>>3956938
I derped a little. It should be:

double result

for(int a=0;a< 4 641588; a++)
for(int b=0;;b++){
result = pow(pow(a,3)+ pow(b,4), (float)(1/5));
if(result < 10000){
if((int)result == result)
cout<< ", a = " << a << ", b= " << b << ", c= " << c;
} else
break;
}

>> No.3956962

>>3956938
Beal conjecture says that it is only possible if a,b,c have a common factor.
Though it is a conjecture, these values have already been searched through for a counterexample, so we can assume it for c <= 10000.

>> No.3956966

>>3956938
Excuse me for being such a pr.-noob, but what is this written in? Java, Python etc?

And what exactly do you mean by double result?

>> No.3956971

>>3956933
Yes, and written out that would be?

>> No.3956976

>>3956971
That would be something similar to what our tripfriend posted.

>> No.3956980

>>3956966
It will run in C and C++. It will run in Java if you change cout << to System.out.println, and pow to Math.pow().

"double result" declares a variable of type double with the name "result". A "double" is a double precision floating point number. Its a variable that can store decimals.

>> No.3956987

>>3956966
The cout statement indicates it is c++.
Though it probably wouldn't work properly due to floating point errors.

>> No.3956996

>>3956980
Only has to go through 999700029999 possibilities. Should be done in a jiffy.

>> No.3957000

>>3956987
I see - do you know of a way to fix those errors?

>> No.3957009
File: 9 KB, 250x201, confused_baby_crop-250x201.jpg [View same] [iqdb] [saucenao] [google]
3957009

>>3956987 floating point errors
You serious bro? Point out where you think there would be floating point errors.

>> No.3957032

>>3956987
These numbers will fit in 67 bits, no problem.

>> No.3957060

>>3957009
So, let me get this straight: your solution will calculate all the solutions for a^3 + b^4= c^5 for c ≤ 10000, wherein a, b and c are all whole numbers? Will it display it in a list?

>> No.3957090

>>3957060 your solution will calculate all the solutions for a^3 + b^4= c^5 for c ≤ 10000, wherein a, b and c are all whole numbers?

Yes. There is a little optimization such as breaking the second loop when the combination of a and any higher b values can't satisfy the equation. As said there could be more ways to optimize it. Things like that take a few hours to come to me.


>>Will it display it in a list?
If I had remembered to include <<" /n" at the end of the output statement it would.

>> No.3957106

>>3957090
Thank you for all your good work here so far, you have no idea how much you just helped me!

Just a quick note, where should I include the <<" /n" to get that list you were talking about (?):

double result

for(int a=0;a< 4 641588; a++)
for(int b=0;;b++){
result = pow(pow(a,3)+ pow(b,4), (float)(1/5));
if(result < 10000){
if((int)result == result)
cout<< ", a = " << a << ", b= " << b << ", c= " << c;
} else
break;
}

>> No.3957139

>>3957106
" /n " just makes the text output start a new line. Without it you will get a massive wall of text that's hard to read. Also since you appear to be a complete novice I've added the program structure for you:

#include <iostream>
using namespace std;

int main ()
{
double result;

for(int a=0;a< 4641588; a++)
for(int b=0;;b++){
result = pow(pow(a,3)+ pow(b,4), (float)(1/5));
if(result < 10000){
if((int)result == result)
cout<< " a = " << a << " , b= " << b << " , c= " << c << "/n";
} else
break;
}

return 0;
}

>> No.3957148

>>3957139
Yes. It's actually a backslash and not a slash, though.

>> No.3957151

>>3957139
I caught another result
>>cout<< " a = " << a << " , b= " << b << " , c= " << c << "/n";

should be

>> cout<< " a = " << a << " , b= " << b << " , c= " << result << "/n";

>> No.3957158

>>3957090
I can see that you are indeed an engineer.
Using floats, nested loops.
Look at the problem.
What would be an immediate improvement?

>> No.3957163

Aren't there an unlimited amount of answers to this equation?
Like letting a = 0.000000...1, then 0.000000...2 etc

>> No.3957167

cout<< " a = " << a << " , b= " << b << " , c= " << c << "\n";

>> No.3957183

>>3957158
Well I'm not doing the complete retard thing of using three nested loops and testing every possible combination. I'm using two, computing he final answer, and checking if it satisfies the special criteria OP asked for. Can you please explain what this obvious thing I'm missing is?

>> No.3957189

>>3957158
I'll give you a hint.
If k + n = m, for natural k,n,m, then k>=m/2 or n>=m/2.
See it yet?

>> No.3957195

>>3957163
You do know what a whole number is, right?

>> No.3957224

>>3957189
I'm still drawing a blank.

>> No.3957231

>>3957183
>>3957189
Sorry, my bad.
The guy's talking about integers, not naturals.
Both our solutions will fail.

>> No.3957242

>>3957231 Both our solutions will fail.
What the fuck is your solution? Where do you think mine will fail?

>> No.3957260

>>3957224
As I said, it doesn't work for ints, but for nats.
Loop over all values for c^5.
If a^3 + b^4 = c^5, then either a^3 > c^5 / 2, or b^4 > c^5 / 2.
Make a case distinction. Wlog, we look at the first case:
We can trivially find the largest a, s.t. a^3 <= c ^5. If a^3 < c^5 / 2, then there is no solution for this c. If c^5 / 2 <= a^3 <= c^5, then we trivially check whether there exists a b, s.t. c^5 - a^3 = b^4.

>> No.3957271

>>3957242
I don't think yours fails unless:
- OP means relative integers (which I doubt),
- it does approximation errors (which can happen, since 10000^5 = 10^20 which is roughly 2^67 so if your double is 64bits long, it has less than integer precision.

I've done a fast test with big ints instead of doubles, in OCaml, but it's slow. Output of the first few results was:
Solution: a=0, b=1, c=1
Solution: a=1, b=0, c=1
Solution: a=32, b=0, c=8
Solution: a=0, b=32, c=16
Solution: a=243, b=0, c=27
Solution: a=256, b=64, c=32
Solution: a=1024, b=0, c=64
Solution: a=0, b=243, c=81
Solution: a=3125, b=0, c=125
Solution: a=7776, b=0, c=216
Solution: a=9375, b=625, c=250
Solution: a=0, b=1024, c=256
Solution: a=16807, b=0, c=343
Solution: a=32768, b=0, c=512
Solution: a=0, b=3125, c=625
Solution: a=59049, b=0, c=729

Haven't checked them (or removed those with zeros).

>> No.3957269

>>3957139
Kraken, thank you ever so much! I will keep on monitoring this thread, but you seem to have found the closest thing to a solution so far!

>> No.3957267

>>3957242
Your (and mine) consider only natural a and b. You start with a = 0, b = 0.

>> No.3957284

>>3957260
Thanks. That is a more efficient solution than mine. I had that feeling I get when there should be a more efficient solution but it hadn't come to me yet.

>> No.3957285

>>3957271
What if (-12902354, 39328, 9823) is a solution?
He says 'whole numbers', which I interpret as integers, not natural numbers.

>> No.3957301

>>3957285
I'm not going to debate over terminology. Some people use "whole number" for any integer, for integers greater or equal to zero, or for integers greater to zero. I don't really care about that. If what I did was wrong and OP though "relative integers" (which is possible even though I don't think it's the case), then he'll have a partial solution anyway.

>> No.3957302

>>3957284
How would this be turned into a program, like you made?

>> No.3957303 [DELETED] 

>>3957285
Also
>mfw I realise there is only an upper bound to c, no lower bound

>> No.3957306

>>3957302
>Cannot into programming

>> No.3957335

>>3957260
I'm not sure if I understand your algo well.
You say that you use two cases depending on whether a^3 or b^4 is greater than the other. I don't mind that, but how does it make your algorithm faster? I'm not sure your "wlog" is true here. There is no symmetry of the problem by exchanging a^3 and b^4.

>> No.3957338

>>3957301
Usually, you are not completely retarded in CS topics. You are now.
First off, whole numbers can only properly be interpreted to mean integers.
Second off, if you read what I post, you'll see that I also assume natural numbers in my solution, since otherwise the problem seems infeasable.
Third off, why didn't anyone notice that 10,000^5 > 10,000?

>> No.3957358

>>3957338
>whole numbers can only properly be interpreted to mean integers
LOL

>> No.3957364

>>3957338
>First off, whole numbers can only properly be interpreted to mean integers.
http://en.wikipedia.org/wiki/Whole_number says that whole number can mean any of the 3 sets I have just described depending on the author. I am saying that I'm not trying to debate over which one is right and only assume that OP might mean "non-negative integers". I don't think that makes me retarded? I mean, I'm being very cautious by doing that. And OP puts only a "non-zero" and a "c<10000" limits on his solutions, which hints "they can be zero" and "they cannot be as low as you want". So really, "non-negative integers" is the most likely option, whether it makes sense to define whole numbers like that or not. If you don't like this denomination, argue with OP, not with me.

>Second off, if you read what I post, you'll see that I also assume natural numbers in my solution, since otherwise the problem seems infeasable.
Yes, there are probably infinitely many solutions otherwise.

>Third off, why didn't anyone notice that 10,000^5 > 10,000?
What do you mean by that?

>> No.3957363

>>3957338
Apologies - it should be the bare c, without the exponent. So 10,000^5 would be possible in this case.

>> No.3957381

>>3957335
My algorithm is a factor O(n) faster.
We iterate only over the values for c, and check, for each value, whether a solution exists.
This can be done in constant time.
Case 1:
We take the cubic root of c^5, and round the answer down to a natural number. This is our a. We check whether a^3 > c^5 / 2, and whether the 4th root of c^5 - a^3 is an integer (b). If both are the case, congrats, we found a solution.
Case 2
We take the 4th root of c^5, and round the answer down to a natural number. This is our b. We check whether b^4 > c^5 / 2, and whether the cubic root of c^5 - b^4 is an integer (a). If both are the case, congrats, we found a solution.
If we didn't find any solution, then no solution exists for this c (for natural a,b).
The argument for that is that there can be at most one c^5 / 2 < a^3 (or b^4) < c^5, and that for any natural k+n = m, k>=m/2 or n>=m/2.

>> No.3957387

>>3957364
>Yes, there are probably infinitely many solutions otherwise.

Proving that:
Assume you know a<0, b non-zero and c<0, integers, such that a^3+b^4=c^5.

Consider any positive integer k.
<span class="math">(ak^20)^3 + (bk^15)^4 = a^3k^60+b^4k^60 = k^60(a^3+b^4)=k^60c^5=(ck^12)^5[/spoiler]

You can build infinitely many solutions if you can build one. I'm too lazy to build one but I'm sure anyone here can do it.

>> No.3957394

>>3957364
What I meant was that even a linear algorithm is infeasable for n = 10,000^5 = 10^20. There must be a number theoretical way to solve this problem.

>> No.3957400

>>3957381
So, take the non-trivial solution my OCaml code found:
a=9375, b=625, c=250

The cubic root of c^5 is <span class="math">250^{5/3}\approx9921.26[/spoiler], which does not yield the good a.
The 4th root of c^5 does not yield the good b either, but 994.

Your algo is O(n) but it doesn't find every solution.

>> No.3957402

>>3957381
>The argument for that is that there can be at most one c^5 / 2 < a^3 (or b^4) < c^5
Er, no. Take c=10; then 36^3 up to 46^3 are all between c^5 and 0.5 c^5.

>> No.3957408

>>3957394
You mean it's infeasible assuming that a>0 b>0 and 0<c<=10000? I disagree. My algo isn't optimized and it has checked everything up to c=2500 already. It's quadratic, so it'll take it roughly 16 times longer to go to 10000 (a bit more since big_int operations are not constant time). Nothing impossible.

>> No.3957422

>>3957400
>>3957402
I should go to bed now.
Fuck me. I'm retarded.

>> No.3957432

>>3957422
Though, after seeing many projecteuler problems in which there was an arithmetic simplification to this kind of loops to make your algo gain an exponent in terms of complexity, it didn't strike me as absurd at first. I had to actually read it to be sure: I couldn't be sure that what you had written without formalizing it was incorrect. I suck at arithmetics :<

>> No.3957440

>>3957432
Yeah, project euler is awesome.

>> No.3957465

So I should stick with Kraken's solution? Anyone wrote something better?

>> No.3957473

>>3957422
At least you weren't smug about your potentially optimized solution.

>> No.3957483

>>3957465
I have something that might be better (find more solution and don't find incorrect solutions) assuming that Kraken's code actually does approximation errors, but my solution is also slower. I only reached c=3000 right now... I think I underestimated the time consumed by operations on large big_ints.

Anyway, I can give you the code, but it's OCaml code, so unless you're on a Linux machine or you are willing to spend some time installing it properly, you won't be able to run compiled code, only bytecode, which will be 100 times slower...

The new results starting from where I stopped in my last report are:
Solution: a=100000, b=0, c=1000
Solution: a=0, b=7776, c=1296
Solution: a=161051, b=0, c=1331
Solution: a=248832, b=0, c=1728
Solution: a=209952, b=11664, c=1944
Solution: a=371293, b=0, c=2197
Solution: a=0, b=16807, c=2401
Solution: a=268912, b=19208, c=2744
Solution: a=537824, b=0, c=2744
and then nothing until at least c=3000.

>> No.3957494

Trolololo let's troll /sci/ wit a variation on Fermat's last theorem

>> No.3957496

>>3957483
Maybe there's a bug in my code somewhere. The value of "a" should keep on increasing, but your output shows it dropping down to zero for some reason sometimes.

>> No.3957508

>>3957496
Nah, I just chose to loop on c first and a afterward because it's one less test to do. I haven't tested your code but I don't think it's wrong. It's just that I haven't done it exactly as you have.

>>3957494
>Trolololo let's troll /sci/
I see you've already started.

>> No.3957522

>>3957508
You have to check the least numbers if you're looping over c's and b's. Since 5th root of 10^20 < 4th root of 10^20 < 3rd root of 10^20.

>> No.3957524

>>3957508
Also, to avoid using big integers (which supposedly is the reason why my code is so slow), using "long double"s on a 64bit machine should do the trick.
As long as sizeof(long double) is 16 (which might actually be true on some 32bit machines too?), there should be no approximation problem. 16*8=128, and it appears that there are 112 bits for the precision part, which allows integers up to roughly 10^33 (much more than 10^20).

>> No.3957525

>>3957522
Yes, but I don't have a build-in method for the cubic root of a big integer :-)

>> No.3957563

>>3957525
Implementing your own version will be way more efficient. It's a lot easier to find an integer approximation of any root. Floating point operations are way more expensive.

Anyway, I'm thinking about solving this problem with modular arithmetic. No more expensive operations, we'd find classes of solutions, and we could discount classes of solutions.
Let me think about a general approach.

>> No.3957576

>>3957563
Binary search for cubic root is already O(log n), for example.

>> No.3957588

>>3957563
>Implementing your own version will be way more efficient.
Well, I'm lazy, and computing the 4th root is two calls to the sqrt_of_big_int that is already available, so I've kept b as a function of a and c there by laziness. Also I'm not an expert when it comes to big_int operations so it wouldn't surprise me if the methods to compute the root of a big integer were:
- Far faster when it's the square root,
- Not so trivial to implement optimally.

>It's a lot easier to find an integer approximation of any root. Floating point operations are way more expensive.
Floating point operation is 1 proc operation. Working on big integers is far heavier than that. Give me 3 minutes, I'll give you some numbers.

>> No.3957599

>>3957588
Alright, I'm not too sure about the exact datatypes. Fact is, that if you have a float/double/whatever, with enough precision to exactly represent a particular integer, operations on such a datatype are way more expensive.

>> No.3957620

>>3957599
Operations on floats/doubles/long doubles are fast.
Operations on "big integers" are slow.
Operations on "normal" integers are fast, but I don't think they are faster than on their floating point counterparts.

I tried the following:
Compute the 5th powers of the numbers from 1 to 5'000'000.

With big ints:
real 0m3.365s
user 0m3.348s
sys 0m0.008s

With floats:
real 0m0.680s
user 0m0.676s
sys 0m0.004s

My floats didn't have the required precision here, it was merely to show the speed of the operations.

I'll do float vs int now, for smaller values.

>> No.3957658

>>3957620
Pseudo code:

res = 1
for i from 1 to 500000000 do
res = res + 1
done

With ints:
real 0m0.576s
user 0m0.572s
sys 0m0.000s

With floats:
real 0m0.761s
user 0m0.760s
sys 0m0.000s

Looks like floats are slower. I think both were 64bit types. I hope this wasn't optimized stupidly... I'll do a few more tests to see if it really meant something.

>> No.3957733

>>3957658
Okay, so once I remove the influence of the loop, the operation:
res = res + 1
takes 3 times longer for floats as for ints, and 200 times longer for big ints as for ints.

This doesn't seem to be affected by the value added (which makes sense) for ints and floats. I haven't tested for big ints but I assume that it would get even slower once the big ints are large enough to require many integer operations to do a single big int operation.

I am too lazy to check the assembly and see if the registries are handled the same way or if there's a difference, for ints and floats. For big ints, well... obviously the code is going to be different.

>> No.3957734

>>3957733
You know you should go to bed when you can't sage properly anymore...

>> No.3957757

everyone below except one person:

you guys retarded? Fermat's Last Theorem states "n number theory, Fermat's Last Theorem states that no three positive integers a, b, and c can satisfy the equation a^n + b^n = c^n for any integer value of n greater than two."


fucking worthless pieces of shit wasting their time, go die and stop wasting my air.

OP, well done. 10/10 trolling effort.

>> No.3957788

>>3957757
But this isn't a^n+b^n=c^n. It's a^x+b^y=c^z, where x, y, and z are all natural numbers.

>> No.3957795

>>3957788
cant tell if trolling, or severely mentally retarded to the point must be put out of their misery.

going to assume trolling, no one can be that stupid.
1/10

>> No.3957800

>>3957795
Any chance you can tell me the value of n in OP's question?

>> No.3957805

>>3957800
Don't bother. He's the one trolling, and he's not funny.

>> No.3957939

why is this bad

#include <stdio.h>
#include <math.h>

int main(void) {
double a, b, c;
double amax, bmax, cmax;
double ar, br, cr;
double tol;

a = 0; b = 0; c = 0;
cmax = 10000;
tol = 1.0 / pow(10, 6);

while(c <= cmax) {
cr = pow(c, 5);
bmax = pow((cr/2.0) , (1.0/4.0));
while(b <= bmax) {
br = pow(b, 4);
amax = pow(br, (1.0/3.0));
while(a <= amax) {
ar = pow(a, 3);
if(fabs(ar + br - cr) < tol) {
printf("%f %f %f\n", a, b, c);
}
a += 1;
}
b += 1;
a = 0;
}
c += 1;
b = 0;
a = 0;
}
}

>> No.3959605

Alright, I thought about it while I was asleep.
And with modular arithmetic, we should be able to eliminate the root operations entirely.

>> No.3959685

cout exists in C?

>> No.3959693

k = 0;
for i=1:10000
for j =1:10000*10000
c = i^5-j^4;
d = c^(1/3);
if d = round(d)
x(k,1) = d;
k = k+1;
end
end
end

After merely 1 billion loops we'll have our solution. Problem solved.

>> No.3959738
File: 15 KB, 200x200, asset.JPG?id=4A9CD6BB-4550-447F-9134-63ECC2F128D2&amp;ext.jpg [View same] [iqdb] [saucenao] [google]
3959738

>>3957805

Yeah we found two solutions in our run:

(a, b, c) = (256, 64, 32) and (9375, 625, 250)

You be trollin'.

>> No.3959767

for a in xrange(10000):
for b in xrange(10000):
for c in xrange(10000):
if a**3 + b**4 == c**5: print a,b,c

here's a few solutions right of the bat:

0 0 0
0 1 1
0 32 16
0 243 81

>> No.3959776

>>3959767
abc can't be zero so a can't be zero. D:

>> No.3959792

>>3959776

so I add about 5 characters of changes

import time
for a in xrange(1,10000):
for b in xrange(1,10000):
for c in xrange(1,10000):
print a,b,c
if a**3 + b**4 == c**5:
print a,b,c, "found!"
time.sleep(2)

>> No.3959850

>>3959792
Why Sleep?

>> No.3959869

>>3959850
Optimization.

>> No.3959928 [DELETED] 
File: 1.44 MB, 330x262, cutey_Emma_approve0.gif [View same] [iqdb] [saucenao] [google]
3959928

I came up with a cute little algorithm.

But something's buggy, it claims

a=356811923176489970264571492362373784095686656

b=2596148429267413814265248164610048

and

c=618970019642690137449562112

is a solution.

>> No.3960052
File: 452 KB, 500x600, cutey_Emma_redsihuett.png [View same] [iqdb] [saucenao] [google]
3960052

k, I solved the general problem, i.e. I can produce arbitrary long solutions with one line of code. Example:

a=3694996538828703790315942547190898328670611222221868918057591349235569\
5971522571646382588322181456441019585843510318042615314146631217880578\
9840198391326265901348880609849727273167283902556161975231705883342461\
4110624578113471433477414065204276476051958392724360121375347428160810\
9610799675286345296697944223826534125470485443242615501813543293275215\
3398531344837093897912562035402799365033165842170929306561998614179008\
4817371035232284193164664750961765319938749613323756414116179852816709\
7965001124537430678047052893150982557580582109901968532046915496376296\
3331655240316872613927692765989815443171326074154448182062707077170579\
1793880797612731198347898161209406891053964252788450350095861297680783\
4403182954574734767995730434744774287734131632023487477115531187494404\
1524420341166557860122893242320963175914705504662337649206070583113275\
2172006935125353697771020037391024831798625453782914699806493796102159\
8330949948793788613543832424070832321389668501250664310477448685263740\
7034846662419652223833308129016593797428555733454425236451047243650374\
8084060257932187242057783528102547188258157394898244734036970065615698\
2735858867434193854404387033374859523602400250965978001536549853499119\
3431366495704644118763104954118300131967919301536807171031370224726288\
2797753913388817467080809067874648294635290928951594003093613742323239\
3719803371339479467902044595806581593904506472193856425783348133813042\
5082810158762285336052544843611109278435882533085869251532845143559293\
4140985826809487386800501537143261630842587723144567214476152928898290\
3882585189805719415676217218393604608377384973148492116351998110474829\
0770923011803355777469636240840913614273924961757767628323859543613082\
8045113477394580926866095569819096758137217445982430157609241605909420\
94136634531505884139335133042625626714638867345965056

>> No.3960057
File: 1.02 MB, 1334x1832, cutey_Emma_pocket.jpg [View same] [iqdb] [saucenao] [google]
3960057

b=8427728317826362164800352254994477002110569781197756583670323713615535\
1359707396198158899108886592315242144740419325148531586395447591641357\
8506737490903376325525025562434018078376470890141650070501919778894392\
9677878711952003556471700885496846989035750636774911954848638632327388\
0230767554599899543005531431959226399372524606933733887653098318462471\
4910679532555293220314752254066239031550931360280633284852198098516783\
3153738157779407273128640785941342574364523034146778291387891621804045\
2354752877570186376015049260953013568755121755610853886979783557391332\
2782204575625088888402785163825558493515218072183328142851460912743191\
7637134590747431294734299829814442470865971816898577661051069940734318\
0964809537307888703876685563980985952453420520008149388627379493295512\
9558450308722590646773983108028006559985507224359926622781211821552441\
3954499479954132595576669632281148845405260592129242064055611100195955\
5678909411788139965199779427358900014872238036369371187142288721075373\
4549440555356346471316040279189893046996880808653666237128195987752817\
8058446995120707379238632393481189950607134129208693624406843401745545\
9470689640686144926520341483936277544676751712758327372716733705240994\
5315707302107625271029079091734870075445319152730086945168505738963130\
6571678704864923661900114279275859724922915974229997743641000981029008\
0604035605917962600448

>> No.3960065
File: 250 KB, 379x304, Reaction_Face_ASR_happy_win.png [View same] [iqdb] [saucenao] [google]
3960065

c=3988176964329644992742845821537720250079430440578360638514753585768708\
6137929603198643623963481355660494932944012482532245757397784735013920\
3828949217699481073554624236182534472783944498957261115198233192527116\
2705245989861631083098502414784485455864241749885138575784297303397576\
8373775463327476921287920090879096642530684779248792880761069334420690\
3788007238338936217504780686736621850803777685447822180892970174579685\
5667221022546045800827584431623681528408657045583028553842971029361912\
6183847842110200602141663949658597856431617143742169505015434190186412\
1205798169820542091103450484268039189409333186998563087655262011765279\
2099861557127895170352145650535954768812357507727339211886364688451762\
4000146120200065196828461660090788220392984740043614711167883879716989\
7075600022080678574821231594164359014554157837101761443323408804541776\
5430130285489921756495259575063962994932276939944399907407708738200429\
1477045219843868992721417359082063439702211271142268332494328495076845\
9442673103790672931675613857338888296866788067109175754539544900149206\
48387949140380475916337694113792

>> No.3960754

>>3960065
OK, tell us what it is then.