Ad
  • Custom User Avatar

    timeit is the best way to check execution time of code
    I like your comment. Thanks!

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    Looks like the timings were not gathered with a tool like Timeit. For small snippets of code, which are affected most by even smallest stuff your CPU can be doing in the background, you should use modules like timeit (or the %timeit in ipython) which will run your snippet multiple times, millions of loops each, to average the result. Timeit can also set up the environment for you (like imports) and not count time for it. For me, in a timeit test of 7 runs, 10 million loops each the results are 30.3ns/27ns/26.3ns confirming the common sense that the sign flip on the int - being a single-bit operation - is the fastest (obviously there is Python layer on top of this but it applies to all three approaches). Hopefully I'm not coming through as a smartass, I "discovered" timeit just recently myself!

  • Custom User Avatar

    Not really, with enough number of executions the differences in individual runs should diminish and you will see true performance difference between the solutions. That's why for small snippets of code, which are affected most by even smallest stuff your CPU can be doing in the background, you should use modules like timeit which will run your snippet 10-100 thousand times to average the result. Timeit can also set up the environment for you (like imports) and not count time for it.

  • Default User Avatar

    So what you need to realize is that these three operations did NOT take 87ms/109ms/150ms. What took that long was initializing the python runtime and executing your code.

    (I mean ... seriously ... think about it ... are you trying to say your computer can only do ~10 multiplication operations per second? I think computers exceeded that level of performance in the 1940s.)

    The time to negate an integer is so fast that it is borderline impossible to measure. You'd need to write a VERY carefully written benchmark program that repeats this operation many many times, carefully removes the time for the necessary jump operations, and never gets switched off the CPU by the OS before you could even begin to claim that you've acquired an accurate measurement of performance.

  • Default User Avatar
  • Custom User Avatar

    I agree with paime. Given that Python uses C under the hood, I assume that the change of the sign is done like in C/C++, that is, the two's compliment. With that in mind, both -n and n*-1 are carried out by the same assembly instruction(optimised by the compiler) and should have on average the same execution time if you perform this an infinite amount of times. The n - n * 2 operation seems unreasonable to be the fastest since it involves two operations. Again, for a couple of executions the difference might not be obvious. But, for a sufficiently large amount of executions, the averages should have a distinct difference with the "n - n * 2" being the slowest. At least, theoretically.

  • Default User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    the test fails as your recursive function has been called fewer times than expected.
    please note that expected and actual data should be swapped

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    I'm successfully reversing the strings, but it looks like the expected count is off. For example, for 'hello world' N=11. When I submit, the test shows expected as 12 and actual as 11.

  • Default User Avatar

    This comment is hidden because it contains spoiler information about the solution