[ art / civ / cult / cyb / diy / drg / feels / layer / lit / λ / q / r / sci / sec / tech / w / zzz ] archive provided by lainchan.jp

lainchan archive - /λ/ - 22478



File: 1489362099263.png (876.97 KB, 300x284, Screen Shot 2017-03-12 at 4.41.11 PM.png)

No.22478

I've recently gotten really into ProjectEuler and wanted to dedicate a thread to it and similar recreational programming websites. What have your experiences with them been?

At least for me,after progressing to Level 2, I feel like I've sort hit a wall... I try to program the answers for the problems, but most of the times I go about things the wrong way and my solutions take forever to run (and they're not even right most of the times)

I really enjoy doing these problems, but I feel like I'm not thinking about things the right way.

Any thoughts?

  No.22484

I used to do project euler but I stopped for some reason. Great way to learn a new language is to do the first 20 or so challenges.

I think I should start setting aside time for it on weekends, I really liked doing them.

  No.22486

>>22484
This
Will start this weekend, have too much soykaf on university

  No.22608

>>22478
What are some optimizations you guys tend to use? Something I've seen a lot is using arrays/vectors instead of STL maps

  No.22623

File: 1490308370303.png (6.48 KB, 128x128, rest_of_problems_I_am_working_on.rb.txt)

Ive done 20 of the first 30 Project Euler problems. A lot of the problems simply have too long of a runtime and I just had to use smaller inputs and trust that it would work for the inputs asked for. I used Ruby which is a perfect language for PE kind of problems as they have great array/list mapping functions and block functionality built into methods. If anyone wants to help me or give me hints on the problems Im still stuck on then take a look at the code I attached to this post. (I had to add .txt extension to upload it)

  No.22625

>>22623
>A lot of the problems simply have too long of a runtime

then you were solving them wrong

  No.22626

File: 1490311739734.png (1.26 KB, 128x128, long_runtime.rb.txt)

>>22625
ok, here Ive attached 4 problems I did that gave correct results with the smaller inputs specified in the problem but have too long a run time, Im talking 6+ hours and not terminating. If you can show me how to optimize the runtime Id be very curious, but I bet you cant.

  No.22628

File: 1490313114292.png (62.21 KB, 200x89, Capture.jpg)

>>22626
I won't show you how because I'm lazy and a bastard but I will tell you, you need to learn how to calculate primes better.

  No.22630

  from numpy import prod

def lagrange(dp):
l = lambda i: lambda x: (prod([(x - dp[j][0]) / (dp[i][0] - dp[j][0]) for j in range(len(dp)) if i != j]))
return lambda x: sum([l(i)(x) * dp[i][1] for i in range(len(dp))])

My lagrange interpolator for PE 101^

  No.22631

>>22630
You know python lambdas can take multiple arguments right?
  [...] lambda i, x: [....]
[...] l(i, x) [...]
IMO that should be a global function with a better name anyway, just have it take dp, i, and x. Conciseness in simplicity/logic > conciseness in code length. I guess that's up to taste though.

  No.22636

>>22631
>lambda i, x:
I never used that. l is a closure, not a multivariable function.

  No.22637

>>22636
>I never used that. l is a closure, not a multivariable function.
I know you didn't. I'm saying you should have, and that l should be a multivariable function. It's even shorter this way, which is apparently something you prioritize too much with function names like l.

Let me be more clear. You code would be better like this:
  from numpy import prod

def lagrange(dp):
l = lambda i, x: (prod([(x - dp[j][0]) / (dp[i][0] - dp[j][0]) for j in range(len(dp)) if i != j]))
return lambda x: sum([l(i, x) * dp[i][1] for i in range(len(dp))])
And it would be even better like this:
  from itertools import product  # numpy arrays aren't necessary for this

def lagrange_help(dp, i, x):
return product([(x - dp[j][0]) / (dp[i][0] - dp[j][0])
for j in range(len(dp)) if i != j])

def lagrange(dp, x):
return sum([lagrange_help(dp, i, x) * dp[i][1] for i in range(len(dp))])
PE101 is about finding a sum, not finding a function that returns a function which finds a sum. Just write it normally.

  No.22638

>>22637
You also don't need to use list comprehensions for either of those functions. Iterator comprehensions would be better for memory usage.

  No.22639

>>22637
>you prioritize brevity too much.
I don't think so, given that it was my entire objective in this instance.

>just write it normally

Sorry I didn't do it the exact way you would have.

  No.22640

>>22639
>Sorry I didn't do it the exact way you would have.
If you hate comments like this so much don't post your code.

  No.22641

>>22640
>don't post your code if you don't want passive aggressive posts about how you're not doing it right because it's slightly different syntactically from how another guy would do it.
Whatever. I'm not going to propagate this useless argument any further.

  No.22642

>>22641
I should say, however, your post is absolutely correct in that the first snippet shortens the code segment and the second snippet makes it faster. Just try not to be an asshole, eh?

  No.22643

>>22641
>>22642
Sorry, you're right