1

I'm working in the time analysis for an algorithm with two optional optimizations variant applied and followed next approach:

  1. Create inputs of different lengths for the algorithm
  2. Using these inputs to execute the two algorithm variants and count the asymptopic number of operations (steps)
  3. Graph the operations count

  4. Graph typical time complexity curves and compare with result:

    • Polynomial graph graphed by using $N^6$
    • Quasy-Polynomial graphed by using $2^{LOG(N)^6}$ ($K=6$)
    • $N$ = input length

Time Analysis Graph

I'm a newbie on this kind of analysis and some advise on how to proceed to complete the analysis will be welcome as I feel I'm doing something wrong.

So the questions is, how is the right way/process to do a Time Analysis for an algorithm.

Just in case this helps I provide the raw data for both algorithm Optimizations

Optimization 1 (# of steps)
==========
18   168.444   
19   334.625   
20   671.042   
21   1.869.381   
22   2.664.066   
23   5.318.839   
24   10.656.909   
25   21.008.570   
26   42.226.829   
27   84.365.073   
28   143.803.905   
29   343.807.896   
30   676.068.035   
31   1.372.590.031   
32   2.742.788.213   


Optimization 2 (# of steps)
==============

18   109.533   
19   65.720   
20   250.565   
21   1.324.926   
22   866.908   
23   2.638.451   
24   4.328.395   
25   12.265.480   
26   15.808.379   
27   43.385.582   
28   75.952.700   
29   206.996.787   
30   267.098.278   
31   730.593.681   
32   1.278.315.507
Glorfindel
  • 752
  • 1
  • 9
  • 20
Jesus Salas
  • 519
  • 1
  • 4
  • 17
  • 2
    I'm not sure what you're trying to do. If you're trying to measure the running time of the program (i.e., in seconds), whether your approach is good depends on what you're trying to achieve. If you're trying to analyze it from the point of view of complexity theory, you're on completely the wrong track, since "time complexity" refers to the asymptotic number of operations performed by the algorithm, as a function of its input length and you can't measure that by timing actual runs of the algorithm on actual data. – David Richerby Nov 16 '14 at 19:24
  • @DavidRicherby I try to analyze it from the point of view of complexity theory. The raw data provided (and in the graph) is not timing in seconds or ms, is the asymptotic 'number of operations' (steps) used by the algorithm for each input length. I'll note this in the question, thanks. – Jesus Salas Nov 16 '14 at 20:25
  • 2
    In that case, plotting your graphs will guide you as to what the correct answer might be but the only way to actually analyze the algorithm is to analyze the algorithm, not a plot of how many operations it performs for certain inputs. – David Richerby Nov 16 '14 at 20:55
  • @DavidRicherby I understand what you mean, and I know you are right, however the algorithm itself is a 3 nested loop and there is no an approximate way (statically) to know how many steps will the second and third loop take for an initial given input as calculations add and/or remove elements iteratively. I have not been able to approximate the operations count in any other way than execute the algorithm and count them for a given input. What I'm sure is the input instances are worst-case possible for the algorithm performance. There is some good strategy to analyze iterative Algs? – Jesus Salas Nov 16 '14 at 21:08
  • 1
    This is not an analysis as in algorithm analysis, it's guesswork. You should at least use proper fitting methods (e.g. least square) to find the best fitting functions; you'll notice that "everything fits". I recommend you check out our reference questions, one if which presents a "good strategy to analyse iterative algs". (If you don't share the algorithm, there's no way we can help.) – Raphael Nov 17 '14 at 07:31
  • That said, it is possible to make guesses a little bit more educated; see e.g. the series of articles started with Maximum likelihood analysis of algorithms and data structures by Laube and Nebel (2010). – Raphael Nov 17 '14 at 07:35

0 Answers0