1

Possible Duplicate:
Are there any O(1/n) algorithms?

Any algorithm whose complexity decreases with increase in input size?

I am talking about worst case performance.

In general we know math graphs whose magnitude decreases with the input size but do we have any meaningful algo that matches these graphs?

Community
  • 1
  • 1
P K
  • 8,662
  • 12
  • 48
  • 90

2 Answers2

1

How about this?

 Mystery(array[1..n])
 1. x := fn(0)
 2. for i = 1 to floor(1,000,000 / n) do
 3.    x = fn(x)
 4. return x

All such algorithms are constant-time, asymptotically speaking, for obvious reasons.

EDIT:

Actually, this is asymptotically O(log n), if integer division is logarithmic, which I believe it is. http://en.wikipedia.org/wiki/Computational_complexity_of_mathematical_operations As such, my answer would be that there aren't really any O(1/n) algorithms. O(1) is the smallest complexity class there is... unless there's a way to make an algorithm that can know the inverse of its input size without computing it!

EDIT2:

I just thought of perhaps passing 1,000,000 / n to the function as input... but that's not really a genuine solution, since the algorithm would have no way to tell if that condition were violated, and the caller would need to compute it anyway. Note that a lot of this discussion isn't particularly relevant if you're taking arithmetic operations to be constant time, as I'm pretty sure they are on computers with fixed-size intrinsic types and instruction sets operating on defined register sizes.

Patrick87
  • 25,592
  • 3
  • 33
  • 69
0

Something like

f(Collection c, query q):
  if q in c:
    do something fast!
  else:
    compute Ackermann function!

f*(Array a, int i):
  if a[i] == i: //Or some other condition that takes constant time to verify,
                //assume i is within bounds
    do something fast!
  else:
    compute Ackermann function!

Well, of course, the performance of this relies on the probability that a[i] == i. I haven't done any thorough analysis but I guess, to compute this probability, you need some form of assumptions about the nature of the array and how f* gets called.

It's fun to think about but I can't imagine a case I'll ever actually encounter this scenario.

EDIT: original answer was f, but changed it to f* in an attempt to accommodate harold's comment. After f* I rest my case and will just be lurking.

skytreader
  • 10,673
  • 5
  • 39
  • 57