Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote>Question 1: Do erlang, python and haskell loose speed due to using arbitrary length integers or don't they as long as the values are less than MAXINT?</blockquote> <p>This is unlikely. I cannot say much about Erlang and Haskell (well, maybe a bit about Haskell below) but I can point a lot of other bottlenecks in Python. Every time the program tries to execute an operation with some values in Python, it should verify whether the values are from the proper type, and it costs a bit of time. Your <code>factorCount</code> function just allocates a list with <code>range (1, isquare + 1)</code> various times, and runtime, <code>malloc</code>-styled memory allocation is way slower than iterating on a range with a counter as you do in C. Notably, the <code>factorCount()</code> is called multiple times and so allocates a lot of lists. Also, let us not forget that Python is interpreted and the CPython interpreter has no great focus on being optimized.</p> <p><strong>EDIT</strong>: oh, well, I note that you are using Python 3 so <code>range()</code> does not return a list, but a generator. In this case, my point about allocating lists is half-wrong: the function just allocates <code>range</code> objects, which are inefficient nonetheless but not as inefficient as allocating a list with a lot of items.</p> <blockquote>Question 2: Why is haskell so slow? Is there a compiler flag that turns off the brakes or is it my implementation? (The latter is quite probable as haskell is a book with seven seals to me.)</blockquote> <p>Are you using <a href="http://www.haskell.org/hugs/" rel="noreferrer">Hugs</a>? Hugs is a considerably slow interpreter. If you are using it, maybe you can get a better time with <a href="http://www.haskell.org/ghc/" rel="noreferrer">GHC</a> - but I am only cogitating hypotesis, the kind of stuff a good Haskell compiler does under the hood is pretty fascinating and way beyond my comprehension :)</p> <blockquote>Question 3: Can you offer me some hints how to optimize these implementations without changing the way I determine the factors? Optimization in any way: nicer, faster, more "native" to the language.</blockquote> <p>I'd say you are playing an unfunny game. The best part of knowing various languages is to use them the most different way possible :) But I digress, I just do not have any recommendation for this point. Sorry, I hope someone can help you in this case :)</p> <blockquote> Question 4: Do my functional implementations permit LCO and hence avoid adding unnecessary frames onto the call stack?</blockquote> <p>As far as I remember, you just need to make sure that your recursive call is the last command before returning a value. In other words, a function like the one below could use such optimization:</p> <pre><code>def factorial(n, acc=1): if n &gt; 1: acc = acc * n n = n - 1 return factorial(n, acc) else: return acc </code></pre> <p>However, you would not have such optimization if your function were such as the one below, because there is an operation (multiplication) after the recursive call:</p> <pre><code>def factorial2(n): if n &gt; 1: f = factorial2(n-1) return f*n else: return 1 </code></pre> <p>I separated the operations in some local variables for make it clear which operations are executed. However, the most usual is to see these functions as below, but they are equivalent for the point I am making:</p> <pre><code>def factorial(n, acc=1): if n &gt; 1: return factorial(n-1, acc*n) else: return acc def factorial2(n): if n &gt; 1: return n*factorial(n-1) else: return 1 </code></pre> <p>Note that it is up to the compiler/interpreter to decide if it will make tail recursion. For example, the Python interpreter does not do it if I remember well (I used Python in my example only because of its fluent syntax). Anyway, if you find strange stuff such as factorial functions with two parameters (and one of the parameters has names such as <code>acc</code>, <code>accumulator</code> etc.) now you know why people do it :) </p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload