Re: Median: Oasis and Fast Sorting Algorithm

Right, maybe my explanation was unclear. I'll try to repeat (and ask
other people to check my math).

On 2/10/07, Leonard Mada <discoleo gmx net> wrote:

So, even in the worst scenario, this algorithm should work faster than
n* log(n). Also, (n/2 -1)! is worst case, when all residual elements
would fall inside the sorted array, so we can NOT drop them. So,
No, log((n/2 -1)!) is the worst case for finding where to insert the
elements. It is not the cost of actually inserting them.

In order to insert an element into the middle of a N-sized array, you
must move N/2 elements. Are you assuming that moving N/2 elements can
be done at the same cost of moving 1 element?
This might be possible, but it means you need another N-sized array as filler.

T(n) <
O(n log(n)), even IF I penalize for inserting one value into the sorted
array as there would be maximum n/2 inserts and that should cancel out
with (-n/2) [or add another n/2].
Again, assuming that you can shift N elements of an array with a cost
of 1. Are you convinced it can be done?

Also note, that as x[0] and x[last]
are dropped, some of the new x[i] will be either < x[1], so replacing
x[0] (NO or minimal cost) or > x[last -1], so replacing x[last], without
Wrong assumption - when assuming worst case, you assume never to  gain
from actions that cost less then your worst case.

Because the insert would mean
moving a contiguous memory segment (NO need to create new array, because
array is shrinking: insert 1, drop another 2 => array still shrink by
one), this operation would be very fast.
Yeah, your basic assumption is that moving a contiguous memory segment
takes a cost of 1. If it takes a cost related to the size of the
memory (N), then the continuous movements need O(N*N).


Uri David

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]