destructhub / projecteuler Goto Github PK

Polyglot solutions for www.projecteuler.net mathematical challenges

Home Page: https://destructhub.github.io

License: MIT License

Python 48.46% C++ 2.72% Haskell 8.51% Makefile 1.07% Clojure 4.19% C 3.69% Elixir 12.97% Lua 2.95% Go 2.01% Common Lisp 4.89% Objective-C 0.10% PHP 0.26% Swift 1.46% Shell 1.08% Ruby 3.45% JavaScript 1.22% Rust 0.07% R 0.02% D 0.19% OCaml 0.67%

projecteuler solvers polyglot haskell python clojure common-lisp elixir lua contests

projecteuler's Introduction

ProjectEuler

Compilation of some solutions of the challenges existent in the website www.projecteuler.net

Graphs

Test

You can now test the algoritms just using on our Docker image hosted on destructhub/project_euler just calling: docker-compose run async or docker-compose run sync. Assuming of course that you have a docker installation with docker-compose. On the end of execution, will be print a tabular-like structure with information about problem, language, time execution and if the answer is correct.

The asynchronous build is written in Elixir, the synchronous version is written in Python. You can look on both systems at stats.exs and stats.py.

Status

Check the status of our roadmap here: STATUS.md

Rules

Check the rules of the repository here: RULES.md

Authors and Contributors

Check the ProjectEuler badges and tables by nickname: SOLVERS.md

projecteuler's People

Contributors

Stargazers

Watchers

projecteuler's Issues

Fix Elixir Warnings

Building next Problem007/Elixir/solution_2.exs:  warning: variable "prime_sequence" does not exist and is being expanded to "prime_sequence()", please use par
entheses to remove the ambiguity or change the variable name   
  solution_2.exs:3                                                                   
                                                               
warning: variable "acc" is unused                                                    
  solution_2.exs:24                                            
                                                                                              
@Building next Problem016/Elixir/solution_1.exs:  warning: Kernel.to_char_list/1 is deprecated, use Kernel.to_charlist/1
  solution_1.exs:2                                                                   
                                                               
@Building next Problem032/Elixir/solution_1.exs:  warning: Kernel.to_char_list/1 is deprecated, use Kernel.to_charlist/1
  solution_1.exs:6

[Lua] BigInt operation at Lua solution gave to us the wrong answer of P016 and P015

Maybe we can factorize this the same way of the problem048 #8, operator A ^ B mod C. If we implement that, can be used here.

Doing this we can split the operation 2 ** 1000 like 2 ** 1000 mod 10 ** C and (2 ** 1000) / 10 ** C , and sum the digits individually at each part, recursively using divide and conquer.

Whose C is the mean of length of the 2 ** 1000, whose we can check mathematically that way:

10 ^ x => had (x + 1) digits, and x is a integer.

2^1000 = 10^x 
log(2)*1000 = x log(10)
0.30103*1000 = x 
x = 301,03 -> x = 301

if x = 301, So 2 ^ 1000 have 302 digits and C = 151.

Enhancement to the P005 Elixir solution

Change the range to 20,40...infinity using lazy evaluation, it is better. I don't know how to do a range with steps in Elixir, so I just opened this issue.

Migrate travis to github actions

Since github actions domination, free tier of travis turned to be a shit, we need to set a credit card to use the FREETIER?!

[travis] correct setup of swift enviroment at .travis.yml

We need the correct setup of Swift environment to build and check the solutions.

[travis][P006] Clojure solution doesn't execute at travis server, curious

The log show us that:

$ python stats.py --search python --build --search commonlisp --search ruby --search haskell --search clojure --search go --search php --search python --search elixir --search lua --search bash

Command: Search Build

Builded Problem001/Clojure/solution_1.clj: Answer: 233168: 1.10s

Builded Problem002/Clojure/solution_1.clj: Answer: 4613732: 0.58s

@Building next Problem006/Clojure/solution_1.clj:  Exception in thread "main" java.lang.ClassCastException: clojure.lang.Symbol cannot be cast to java.lang.Number (solution_1.clj:0)

    at clojure.lang.Compiler.eval(Compiler.java:4658)

    at clojure.lang.Compiler.load(Compiler.java:4972)

    at clojure.lang.Compiler.loadFile(Compiler.java:4939)

    at clojure.main$load_script__7405.invoke(main.clj:213)

    at clojure.main$script_opt__7442.invoke(main.clj:265)

    at clojure.main$main__7466.doInvoke(main.clj:346)

    at clojure.lang.RestFn.invoke(RestFn.java:413)

    at clojure.lang.Var.invoke(Var.java:359)

    at clojure.lang.AFn.applyToHelper(AFn.java:173)

    at clojure.lang.Var.applyTo(Var.java:476)

    at clojure.main.main(main.java:37)

Caused by: java.lang.ClassCastException: clojure.lang.Symbol cannot be cast to java.lang.Number

    at clojure.lang.Numbers.add(Numbers.java:123)

    at clojure.core$_PLUS___4509.invoke(core.clj:683)

    at clojure.core$reduce__4500.invoke(core.clj:668)

    at clojure.core$reduce__4500.invoke(core.clj:659)

    at user$solve__1.invoke(solution_1.clj:2)

    at user$eval__4.invoke(solution_1.clj:6)

    at clojure.lang.Compiler.eval(Compiler.java:4642)

    ... 10 more

(⣽) t: 0.521

Hmm, I'm curious with that because in my machine execute fines that solution at Clojure 1.8.

Script `add` was wrongly designed and put unnecessary newline on each answer before hash it

All the hash files of this repository are wrong, but they are equally wrong: each hash was calculated with a newline appended on the answer. Sorry for this.

Main points of this issue:

To fix that we need:

Use (printf $answer | md5sum) on add
Regenerate the hashs without a newline on the answer.

I think we can modify a little the stats.py to generate the hashs only for the problems which has a correct solution.

[travis] setup swift and obj-c environment on Dockerfile

We should able to compile and execute code written in Swift or Obj-c on a Ubuntu 14.04 machine (Dockerfile image). The test build system defined on stats.py which support Swift and Obj-c should pass. If not, let me know if something is wrong.

To be implemented (env):

Swift
Obj-c

How to test:
docker-compose run test python3 stats.py -s swift -s obj-c --build

And this is all.

[travis] Correct setup of .travis.yml for build status, languages environment

[stats] show the correct answer next to answer of solution in stats.py table

Suggestion:

       Problem Language        Time        Result    Answer  Solved
0   Problem001  Haskell    2.338591        233168    233168    true
1   Problem002  Haskell    0.193601       4613732
2   Problem004  Haskell    2.136195        906609
3   Problem005  Haskell   10.057893     232792560
4   Problem006  Haskell    0.179550      25164150
5   Problem007  Haskell    1.145031          7929
6   Problem009  Haskell    0.415062      31875000
7   Problem010  Haskell   57.452556  142913828922
8   Problem012  Haskell    0.178839        126253
9   Problem013  Haskell    0.596420    5537376230
10  Problem014  Haskell  130.642537        837799
12  Problem015  Haskell    0.182069  137846528820
13  Problem015  Haskell    0.189623  137846528820
14  Problem016  Haskell    0.170585          1366
15  Problem020  Haskell    0.166739           648
16  Problem032  Haskell    3.739970         45228
17  Problem048  Haskell    0.192586    9110846700

Add support for Scheme on build system

Dockerfile
stats.py
stats.ex

We should use Racket or guile to build?

[travis] C building: weird behavior at travis server, -lm not found

$ python stats.py --all --build

Command: All Build
Builded Problem001/C/solution_1.c: Answer: 233168: 0.00s
Builded Problem002/C/solution_1.c: Answer: 4613732: 0.00s
@Building next Problem027/C/solution_1.c:  /tmp/cch6tzam.o: In function `is_prime':

/home/travis/build/DestructHub/ProjectEuler/Problem027/C/solution_1.c:36: undefined reference to `sqrt'

collect2: ld returned 1 exit status

Fail builds when solutions are uncorrect or timeout

We can implement this in stats.py to make travis-ci build status clearer

Fix SBCL Warnings on Docker container

On all solutions:

Built Problem500/Bash/solution_1.sh: Answer: 35407281: 3.38s                         
WARNING:                                                       
Couldn't re-execute SBCL with proper personality flags (/proc isn't mounted? setuid?)
Trying to continue anyway.                                     
Built Problem001/CommonLisp/solution_1.lisp: Answer: 233168: 1.33s                   
WARNING:                                                       
Couldn't re-execute SBCL with proper personality flags (/proc isn't mounted? setuid?)
Trying to continue anyway.                                     
Built Problem002/CommonLisp/solution_1.lisp: Answer: 4613732: 0.06s                  
WARNING:                                                                       
Couldn't re-execute SBCL with proper personality flags (/proc isn't mounted? setuid?)
Trying to continue anyway.                                     
Built Problem003/CommonLisp/solution_1.lisp: Answer: 6857: 0.03s                     
WARNING:                                                       
Couldn't re-execute SBCL with proper personality flags (/proc isn't mounted? setuid?)
Trying to continue anyway.                                     
Built Problem004/CommonLisp/solution_1.lisp: Answer: 906609: 0.26s                   
WARNING:                                                       
Couldn't re-execute SBCL with proper personality flags (/proc isn't mounted? setuid?)
Trying to continue anyway.                                     
Built Problem005/CommonLisp/solution_1.lisp: Answer: 232792560: 0.03s                
WARNING:                                                       
Couldn't re-execute SBCL with proper personality flags (/proc isn't mounted? setuid?)
Trying to continue anyway.                                     
Built Problem006/CommonLisp/solution_1.lisp: Answer: 25164150: 0.02s                 
WARNING:                                                       
Couldn't re-execute SBCL with proper personality flags (/proc isn't mounted? setuid?)
Trying to continue anyway.                                     
Built Problem007/CommonLisp/solution_1.lisp: Answer: 104743: 0.32s                   
WARNING:                                                       
Couldn't re-execute SBCL with proper personality flags (/proc isn't mounted? setuid?)
Trying to continue anyway.

How to replicate: docker-compose run sync python3 stats.py -b --commonlisp

Blame Board: the worst solutions

I'll add the --blame option to stats.py print the solutions tagged as _slow_. Would be great if we had the time of each one, but some solutions is reaaally bad, take almost hours to finish. After implemented that, I print the path of the solutions here.

stats.py it's broken after partial build integration: handle_files has bugs

After the PR #160 we can check this following error at this log:

Traceback (most recent call last):
  File "stats.py", line 747, in <module>
    main()
  File "stats.py", line 743, in main
    handle_options(options)
  File "stats.py", line 677, in handle_options
    uncommited_solutions, uncommited_core_files = handle_files(options.files)
  File "stats.py", line 512, in handle_files
    solutions += [(f, lang, solution) for lang in os.listdir(os.getcwd() + '/' + f)

This bug is related to the function handle_files and this it's definition:

ProjectEuler/stats.py

Lines 497 to 516 in e675460

 def handle_files(files): 

 """ 

  Analyse files to return two lists : 

  - solutions : list of files as 3-uple of strings that are more likely solutions 

  on the format: (ProblemXXX, 'Lang', 'solution_x.y') 

  - build_files : list of files that are more build files (stats.py, 

  stats.exs, ...) 

  """ 

 solutions = [] 

 build_files = [] 

 for f in files: 

 if f.count("/") == 2: 

 solutions.append(tuple(f.split("/"))) 

 elif f.count("/") == 1 and "Problem" in f: 

 f = f.strip('/') 

 solutions += [(f, lang, solution) for lang in os.listdir(os.getcwd() + '/' + f) 

 if lang in BUILD_SUPPORT for solution in os.listdir(os.getcwd() + '/' + f + '/' + lang)] 

 elif f.count("/") == 0: 

 build_files.append(f) 

 return list(filter(lambda x: is_solution(x[2]), solutions)), build_files

Discussion: Push master events

@lubien and I was thinking about testing all the solutions when the push event is on master (only on master). This will ensure that after a merge all the solutions is working as expected. This is not a big problem on delay because no one cares about push events on master, since only occurs after a PR is merged.

Why do you think about it?

[stats] selected build: test only the files on diff between master

Filter files with: git diff master --name-only

Send to stdin of stats.py and process the intersection of python stats.py --path --all (all solutions) and the diff. That way we will get just the path of solutions files.

Fix wrong solutions :: False or Empty

Total DataFrame solutions:


        Problem    Language       Time  Correct
0    Problem001         C++   0.006047     True
86   Problem001           C   0.005698     True
87   Problem001           C   0.007892     True
96   Problem001        Ruby   0.127348     True
114  Problem001         Lua   0.040627     True
123  Problem001     Haskell   1.804946     True
26   Problem001      Python   0.020391     True
202  Problem001  CommonLisp   1.325499     True
25   Problem001      Python   0.021414     True
153  Problem001      Elixir   1.117581     True
198  Problem001         PHP   0.012523     True
197  Problem001         PHP   0.614283     True
192  Problem001          Go   1.593802     True
7    Problem001     Clojure   2.414442     True
203  Problem002  CommonLisp   0.063643     True
154  Problem002      Elixir   0.450984    False
115  Problem002         Lua   0.003856     True
199  Problem002         PHP   0.040730     True
88   Problem002           C   0.005138     True
27   Problem002      Python   0.019705     True
124  Problem002     Haskell   0.235917     True
97   Problem002        Ruby   0.027462     True
1    Problem002         C++   0.005100     True
8    Problem002     Clojure   1.051332     True
9    Problem002     Clojure   1.030529     True
155  Problem003      Elixir   0.439890     True
204  Problem003  CommonLisp   0.029995     True
28   Problem003      Python   0.224155     True
200  Problem003         PHP   0.011860     True
10   Problem003     Clojure   5.140394     True
125  Problem003     Haskell   0.214294     True
126  Problem003     Haskell   0.183292     True
98   Problem004        Ruby   1.530451     True
116  Problem004         Lua   0.096275     True
11   Problem004     Clojure   1.903960     True
156  Problem004      Elixir   1.588496     True
127  Problem004     Haskell   1.787284     True
29   Problem004      Python   0.519159     True
205  Problem004  CommonLisp   0.255462     True
206  Problem005  CommonLisp   0.030354     True
89   Problem005           C   0.006104     True
2    Problem005         C++   2.717263     True
157  Problem005      Elixir   3.534270     True
158  Problem005      Elixir   0.402972     True
128  Problem005     Haskell   7.504487     True
30   Problem005      Python   0.021950     True
117  Problem005         Lua   0.012968     True
31   Problem005      Python   0.239631     True
99   Problem006        Ruby   0.039326     True
3    Problem006         C++   0.006073     True
159  Problem006      Elixir   0.415376     True
12   Problem006     Clojure   1.115050     True
207  Problem006  CommonLisp   0.017781     True
129  Problem006     Haskell   0.170697     True
32   Problem006      Python   0.025256     True
118  Problem007         Lua  11.966530     True
33   Problem007      Python   4.930726    False
13   Problem007     Clojure   7.243609     True
208  Problem007  CommonLisp   0.315884     True
160  Problem007      Elixir   1.166178     True
130  Problem007     Haskell   0.780792    False
4    Problem007         C++   0.014955     True
14   Problem007     Clojure   2.080807     True
209  Problem008  CommonLisp   0.021125     True
131  Problem008     Haskell   0.247857     True
161  Problem008      Elixir   0.394700     True
34   Problem008      Python   0.031260     True
100  Problem009        Ruby   0.063504     True
132  Problem009     Haskell   0.383797     True
35   Problem009      Python   0.372851     True
210  Problem009  CommonLisp   0.077022     True
162  Problem009      Elixir   0.476834     True
5    Problem010         C++   0.582837     True
211  Problem010  CommonLisp   4.094782     True
15   Problem010     Clojure   5.188783     True
36   Problem010      Python   5.264319     True
37   Problem011      Python   0.029777     True
133  Problem011     Haskell   0.233407     True
163  Problem011      Elixir   0.441041     True
134  Problem012     Haskell   0.168442    False
39   Problem012      Python   8.504144     True
40   Problem012      Python   9.438844     True
164  Problem012      Elixir   5.787180     True
38   Problem012      Python   7.720938     True
119  Problem013         Lua   0.004514     True
101  Problem013        Ruby   0.025262     True
41   Problem013      Python   0.021222     True
165  Problem013      Elixir   0.451481     True
135  Problem013     Haskell   0.188178     True
16   Problem014     Clojure   1.075607    False
166  Problem014      Elixir   6.674990     True
120  Problem015         Lua   0.003865    False
102  Problem015        Ruby   0.035846     True
167  Problem015      Elixir   0.454982     True
42   Problem015      Python   0.047648     True
137  Problem015     Haskell   0.185540     True
17   Problem015     Clojure   1.015579     True
136  Problem015     Haskell   0.188926     True
212  Problem016  CommonLisp   0.017821     True
213  Problem016  CommonLisp   0.016142     True
121  Problem016         Lua   0.004010    False
18   Problem016     Clojure   1.144317     True
168  Problem016      Elixir   0.414291     True
138  Problem016     Haskell   0.178569     True
103  Problem016        Ruby   0.018057     True
43   Problem017      Python   0.038089     True
169  Problem017      Elixir   0.546869     True
44   Problem018      Python   0.156960     True
170  Problem018      Elixir   0.480037     True
171  Problem019      Elixir   0.446823     True
45   Problem019      Python   0.020447     True
214  Problem020  CommonLisp   0.019065     True
19   Problem020     Clojure   1.120206     True
139  Problem020     Haskell   0.171399     True
20   Problem020     Clojure   1.018514     True
46   Problem020      Python   0.028717     True
104  Problem020        Ruby   0.016626     True
172  Problem020      Elixir   0.424012     True
173  Problem021      Elixir   4.694971     True
47   Problem021      Python   0.526113     True
48   Problem022      Python   0.053637     True
49   Problem023      Python   3.498294     True
50   Problem024      Python   0.028667     True
105  Problem024        Ruby   9.101835     True
140  Problem024     Haskell   8.819935     True
174  Problem025      Elixir   3.706562     True
21   Problem025     Clojure   1.605076     True
51   Problem025      Python   0.072949     True
52   Problem026      Python   0.052813     True
6    Problem026         C++   0.006749     True
90   Problem027           C   0.229675     True
53   Problem027      Python  10.766468     True
215  Problem027  CommonLisp   0.990137     True
193  Problem027          Go   4.036005     True
54   Problem028      Python   0.020358     True
175  Problem028      Elixir   0.439083     True
141  Problem029     Haskell   0.952615     True
55   Problem029      Python   0.675814     True
176  Problem029      Elixir   0.419150     True
56   Problem030      Python   0.069463    False
177  Problem030      Elixir   2.059542     True
106  Problem030        Ruby   0.931921     True
57   Problem031      Python   0.481110     True
91   Problem031           C   0.018049     True
178  Problem031      Elixir   0.474610     True
216  Problem032  CommonLisp  16.643692     True
179  Problem032      Elixir   6.596178     True
22   Problem032     Clojure   3.195140     True
142  Problem032     Haskell   3.102111     True
122  Problem032         Lua   9.357629     True
58   Problem033      Python   0.076819     True
180  Problem034      Elixir   1.465369    False
143  Problem034     Haskell   0.404449     True
107  Problem034        Ruby   0.559421     True
59   Problem035      Python   5.086462     True
181  Problem036      Elixir   3.055429     True
108  Problem036        Ruby   1.379445     True
60   Problem036      Python   0.696999     True
217  Problem036  CommonLisp   0.944753     True
61   Problem037      Python  14.011646     True
62   Problem038      Python   0.388626     True
182  Problem038      Elixir   0.461059     True
183  Problem039      Elixir   1.982466     True
92   Problem039           C   0.176807     True
218  Problem039  CommonLisp   0.712423     True
63   Problem040      Python   0.290226     True
184  Problem040      Elixir   3.373723     True
219  Problem041  CommonLisp   1.532947     True
185  Problem042      Elixir   0.624826     True
64   Problem042      Python   0.043304     True
220  Problem043  CommonLisp   5.570950     True
65   Problem044      Python   0.101013     True
66   Problem044      Python   0.568997     True
221  Problem045  CommonLisp   0.067349     True
93   Problem045           C   0.010786     True
186  Problem045      Elixir   0.622019     True
109  Problem045        Ruby   0.040716     True
67   Problem045      Python   0.154765     True
194  Problem045          Go   0.410416     True
110  Problem046        Ruby   1.947136     True
68   Problem046      Python   0.169106     True
69   Problem047      Python   2.748775     True
70   Problem048      Python   0.047018     True
222  Problem048  CommonLisp   0.031225     True
94   Problem048           C   0.011331     True
111  Problem048        Ruby   0.031665     True
144  Problem048     Haskell   0.200841     True
195  Problem048          Go   0.512697     True
23   Problem048     Clojure   2.256229     True
71   Problem049      Python   0.519101     True
112  Problem052        Ruby   1.653711     True
145  Problem052     Haskell   0.904203     True
146  Problem053     Haskell   0.291883     True
223  Problem055  CommonLisp   0.059611     True
224  Problem056  CommonLisp   0.145197     True
113  Problem056        Ruby   0.703848     True
147  Problem056     Haskell   0.570248     True
24   Problem056     Clojure   2.285537     True
72   Problem058      Python   4.076428     True
148  Problem059     Haskell   0.371634     True
73   Problem062      Python   0.059138     True
95   Problem063           C   0.007311     True
225  Problem063  CommonLisp   0.016799     True
149  Problem063     Haskell   0.178669     True
196  Problem063          Go   0.400629     True
187  Problem063      Elixir   0.441893     True
74   Problem063      Python   0.036130     True
188  Problem067      Elixir   0.439617     True
75   Problem067      Python   0.122429     True
76   Problem069      Python   0.041014     True
77   Problem070      Python   0.444427     True
189  Problem076      Elixir   0.467963     True
78   Problem080      Python   0.059912     True
79   Problem081      Python   0.157127     True
80   Problem085      Python   0.041628     True
81   Problem087      Python   1.864039     True
190  Problem089      Elixir   0.438173     True
226  Problem097  CommonLisp   0.016580     True
150  Problem097     Haskell   1.420837     True
82   Problem097      Python   0.096350     True
83   Problem099      Python   0.044758     True
191  Problem099      Elixir   0.379611    False
151  Problem102     Haskell   0.343252     True
84   Problem104      Python   1.691094     True
152  Problem206     Haskell   0.207312     True
85   Problem500      Python   4.375206     True
201  Problem500        Bash   3.380749     True

Incorrect solutions DataFrame filtered:

154  Problem002      Elixir   0.450984    False
33   Problem007      Python   4.930726    False
130  Problem007     Haskell   0.780792    False
134  Problem012     Haskell   0.168442    False
120  Problem015         Lua   0.003865    False
121  Problem016         Lua   0.004010    False
180  Problem034      Elixir   1.465369    False
191  Problem099      Elixir   0.379611    False

[travis] Build error because of Elixir script

The Elixir solution_1 in Problem001 seems to be wrong and the scripts return with a build error, hence the build error status. The error can be seen below and maybe @lubien could give us a hint in how to solve it:

Builded Problem001/Elixir/solution_1.exs: Answer: =INFO REPORT==== 1-Sep-2017::20:14:24 ===
    application: logger
    exited: {{shutdown,
                 {failed_to_start_child,'Elixir.GenEvent',
                     {undef,
                         [{gen,debug_options,[[]],[]},
                          {'Elixir.GenEvent',init_it,6,
                              [{file,"lib/gen_event.ex"},{line,535}]},
                          {proc_lib,init_p_do_apply,3,
                              [{file,"proc_lib.erl"},{line,247}]}]}}},
             {'Elixir.Logger.App',start,[normal,[]]}}
    type: temporary
233168: 0.47s
@Building next Problem002/Elixir/solution_1.ex:  ** (UndefinedFunctionError) undefined function: Enum.reduce_while/3
    (elixir) Enum.reduce_while(#Stream<[enum: #Function<43.95910526/2 in Stream.unfold/2>, funs: [#Function<31.95910526/1 in Stream.filter/2>]]>, 0, #Function<2.106859709 in file:solution_1.ex>)
    (elixir) lib/code.ex:307: Code.require_file/2

[P048] Overflows operation of type A^B. Langs: C, C++ and Go affected

Overflow is the problem, very large number for large operation, need refactor (A^B) mod C operation.

[travis] correct setup of elixir environment at .travis.yml

The actual setup doesn't works, elixir not found. The machine of travis
apparently runs ubuntu.

Proposal - 10 Next Problems

For the 10 Next Problems, can we actually create a new .md file named "Status.md" in order to get to know who is doing what?

Yesterday we were doing the Problem038 at the same time and I only realized after I pull it down from the server ... In that way, we could attack more solutions at the same time... That would be something like:

Problem041 [In Progress, @luizperes]
Problem042 [Done, @Someone]

and so on...

[stats] ShaSum hash solutions for each problem at ProblemXYZ/.hash

We need generate the hash acceptable answer for each problem done and save on Problem folder.

Differential builds for each PR on travis

The approach ideal is using the git differential like codecov does. We need to figure out how we can make this happens yet. That changes should reflect and we need changing the stats.py and stats.exs to receive the files to test optionally (or from stdin to the solution can be piped).

The discussion about that was made here #135

Roadmap

script for given the ref of PR return the filepaths of the files change using only git and shell script
change stats.py to receive optionally the filepaths instead to given by the flags -s and --search
same as above but for the Elixir asynchronous version on stats.exs
integrate that solution to .travis.yml

Cache docker images to speed up more travis build

Our bottle-neck for now on time-issues is that always on PR we need to download sometimes unnecessary a new docker image, even if no updates was found on dockerhub. On these days, our PR build takes about 2 minutes to finish. Probably we can reduce to 1 minute if we cache docker images.

[docker] Setup locale to utf-8

We need that the image use locale utf-8 to avoid annoying warnings on Elixir builds and further problems.

warning: the VM is running with native name encoding of latin1 which may cause Elixir to malfunction as it expects utf8. Please ensure your locale is set to UTF-8 (which can be verified by running "locale" in your shell)

Sending result of build system output of travis to currently PR as comment

This should simplify a lot of things to analysis PRs of new comers about efficiency and correctness, as described briefly on the end of this PR #137

Allows stats.py receive --files as directory to build

python stats.py --build --files Problem001/

Should build all the solutions of the Problem001. For now this is misleading

python stats.py --build --files Problem001 doesn't build anything
python stats.py --build --files Problem001/ build all solutions (?).

Fix stats.py: solutions for compiled languages when load files it fails

There is some attempt to do this at fix/file-load branch.

Problems 004 and 006 wrote in Ruby doesn't execute

$ python stats.py --search ruby --build

Builded Problem002/Ruby/solution_1.rb: Answer: 4613732: 0.05s @Loading next:    Problem004/Ruby/solution_01.rb:5: syntax error, unexpected keyword_end, expecting ')'
Problem004/Ruby/solution_01.rb:12: syntax error, unexpected end-of-input, expecting ')'
puts(solve)
           ^
Builded Problem004/Ruby/solution_01.rb: Answer: : 0.04s @Loading next:     Problem006/Ruby/solution_1.rb:5:in `solve': undefined local variable or method `list' for main:Object (NameError)
    from Problem006/Ruby/solution_1.rb:10:in `<main>'
Builded Problem009/Ruby/solution_1.rb: Answer: 31875000: 0.08s @Loading next:   
Builded Problem013/Ruby/solution_1.rb: Answer: 5537376230: 0.05s @Loading next: 
Builded Problem015/Ruby/solution_1.rb: Answer: 137846528820: 0.06s @Loading next
Builded Problem020/Ruby/solution_1.rb: Answer: 648: 0.05s @Loading next:     
      Problem Language      Time        Answer
0  Problem001     Ruby  0.045931        233168
1  Problem002     Ruby  0.045124       4613732
2  Problem004     Ruby  0.044450              
3  Problem006     Ruby  0.046187              
4  Problem009     Ruby  0.083425      31875000
5  Problem013     Ruby  0.054098    5537376230
6  Problem015     Ruby  0.055732  137846528820
7  Problem016     Ruby  0.055178          1366
8  Problem020     Ruby  0.054945           648

[Suggestion] Different travis builds method at each PR

Hey !

Since pull requesting any changes makestats.py/ stats.exs run all the solutions for all the languages. I suggest to make these build independent from "already builded solutions" and only build new suggested solutions. Also make running all the solutions a possible option (when stats.py is modified for example).

My idea is to try to use destruct.github.io as a data source for ProjectEuler repo since it is hosted 24/7 and we have control of it.
If destruct.github.io contains a list of solutions and configurations (as hidden frame, REST page or visible frame ( well presented for visitors too)), we can parse and make sure stats.py / stats.exs make the right job

Building and validate news problems
Building news solutions to already existing problems.
Build all solutions & problems ( actual default build )
A combination of the listed build ( sync / Async )

C crazy float operation at Problem045, answer wrong, solution_1.c

I don't know exactly what is wrong, but we have other 3 examples whose the answers are right: Go, Python and Swift.

[travis] Put all the language and compiler dependencies on a docker image

With this we reduce the time on build tests and we can use packages more updated. Remember that: travis use ubuntu 12.04 LTS. Very very legacy.

Maybe after that we can fix #13

  - sudo apt-get update
  - sudo apt-get install elixir -y
  - sudo apt-get install php5 -y
  - sudo apt-get install golang -y
  - sudo apt-get install clojure -y
  - sudo apt-get install ghc -y
  - sudo apt-get install g++ gcc -y
  - sudo apt-get install lua5.2 -y
  - sudo apt-get install ruby-full -y
  - sudo apt-get install clisp -y

[CommonLisp] Problem 027 doesn't work

Some crazy statement on loop, I happy if somebody fixes. (the logic is probably right)

[go-hell-stdin] Check repository's consistency and execution time measurement

Proposal

1.Check if all the solutions process doesn't read nothing from stdin and print only the answer.
2. Create a script for run all solutions and get the time of each.
3. After all, we would compare the time solutions and rank by language or developer. Graphic representation can be cool.

Hints/Ideas

Create a script for each language for executing and check if appears some gap reading from stdin
Again, create one script for each language only for execute.
Join all the scripts in [2] so we call them to rank all the stuff and make graphics of benchmark.

Stdin go hell Check and only-answer printing

Building/Executing support on stats.py

Add OCaml support

There are some OCaml solutions that didn't get the chance to get built here :)

Update repo docker image to support OCaml (i need your permission to do so guys)
update ./Stats.py
Run build test for all OCaml solutions, and the new coming ones !

Differential build PR bugs

Need to fix:

python3 stats.py --build --files test build all solutions and shouldn't.
push travis events fails on build as this

Related to #137 #139 #136

[stats] make stats.py build concurrent using asyncio

Would be better if stats.py execute solutions concurrently instead sequentially. This would reduce the time of tests on travis, which for now is almost ten minutes!!!

	def handle_files(files):
	"""
	Analyse files to return two lists :
	- solutions : list of files as 3-uple of strings that are more likely solutions
	on the format: (ProblemXXX, 'Lang', 'solution_x.y')
	- build_files : list of files that are more build files (stats.py,
	stats.exs, ...)
	"""
	solutions = []
	build_files = []
	for f in files:
	if f.count("/") == 2:
	solutions.append(tuple(f.split("/")))
	elif f.count("/") == 1 and "Problem" in f:
	f = f.strip('/')
	solutions += [(f, lang, solution) for lang in os.listdir(os.getcwd() + '/' + f)
	if lang in BUILD_SUPPORT for solution in os.listdir(os.getcwd() + '/' + f + '/' + lang)]
	elif f.count("/") == 0:
	build_files.append(f)
	return list(filter(lambda x: is_solution(x[2]), solutions)), build_files