# Tag Info

3

Recursion Improvements In your problem, you end up calling the same recursive function multiple times. For example for partition_tree(6, 3) calls worker(2, 3, d) many many times albeit with updated dictionaries. This ends up costing you quite a bit of performance. You could avoid recomputing the same combinations by using memoization. Meaning you would save ...

3

In terms of code structure, here are my suggestions: Move d = dict() to after the argument checks, so that you only create the dictionary if the inputs are valid. The if/else statements inside the for loop can be removed: for i in range(1, lim+1): n = num - i if n: dic.setdefault(i, dict()) ...

2

{(wl wr)←⍵ ⋄ (al ar)←⍺ ⋄ (al,wl)(ar,wr)} can be ((⊣/⍤⊣,⍥⊃⊣/⍤⊢),⍥⊂⊢/⍤⊣,⍥⊃⊢/⍤⊢), a crazy looking train indeed. Might be a good idea to add ⎕IO←0 at the beginning of the namespace script. U, '+-×÷' ∘.C ↓⍉↑⍺ ⍵ the , is not needed. the string representations keep getting extra whitespace that I don't know where it comes from It is due to the padding of ↑ in ...

1

I got your initial approach, but I couldn't understand your execution... There are a few things I might add to it and few thing I might remove. My style of writing code always goes after readability first and optimization second. If I can achieve both then that's a bonus... Your approach my way Actually I had the same idea as soon as I read your problem ...

1

Optimization / Simplification Your code can be converted into the following // Let X be a subset of Z (the integers) from a to b. // Calculate the shortest distance between x_a and x_b // using the forward and backward metrics // THIS ALGORITHM ASSUMES THAT a < b function findClosest(a, b, x_a, x_b) { // common distance between a and b in the ...

3

pow(2, a) looks wrong. Did you mean pow(a, 2)? frac_vector1_result_pow + frac_vector2_result_pow3 could be negative, yet you blindly sqrt it. To expand on the above point, cubic equations are tricky. The irreducible case is pretty much unavoidable, and even though the roots are real, you have to deal with complex numbers in the process. So my ...

3

In addition to what Pepijn covered, I'd suggest not using double everywhere. Rather, use a type alias for the type to be used. At the very least, this will let you update the whole thing when you decide you have to use extended precision values of some kind. To be more advanced, you can make it a template. But why is it a class? You have a function. Or ...

1

My feedback, note I did a code review that means I did not check the correctness of your calculations. You would need to place your calculation methods in a separate library (and then link to executable) and write unit tests for that. Here are my comments. #include <cmath> // added (c++ of math library, don't use math.h) #include <iostream>...

Top 50 recent answers are included