Re: Fastcode Sort B&V version 0.8
- From: "Avatar Zondertau" <avatarzt@xxxxxxxxx (please reply to newsgroup)>
- Date: 27 Sep 2005 12:47:36 -0700
> > What do you mean?
>
> Concrete here with log distribution, Qucksort will swap element in
> first loop closer to plase where he need to be in finaly sorted
> order. That is main reason. For example (maybe not exact, but just
> to clear):
>
> 1. 100 2 200 3 400 6 800 - pivot is 3
> 2. 2 3 .. 200 100 6 800 - pivot is 100 for right part recursion
> 3. 2 3 .. 6 100 200 800 - end
>
> Recursion calls are on minimum here.
>
> Perhaps, standard random distribution will be much difficult for
> Quicksort. Anyway, can be tested a bit first to be sure.
This has nothing to do with what i was speaking of. It was about the
list length, not the list contents. When testing more list lengths
there will have to be an appropriate list-length distribution.
The list-length distribtion might even be different for the different
list sorting states.
> > > 1. Sorting random data
> > > 2. Sorting (almost) sorted data (adding situation included, as
> > > well) 3. Sorting (almost) reverse sorted data.
> >
> > So in fact these scenarios would match your experiences quite well.
>
> Perhaps to add just a bit less common situation:
>
> 4. Data with many equal elements (range of elements is quite small,
> say 2^8 different elements with size of 1000+).
Yes, a situation with many equal elements might be useful too.
> > In making the benchmark we should just care about realism, not about
> > the algorithms used. Adding pathological cases specific to some
> > algorithms on purpose doesn't make sense for a benchmark.
>
> What is your pioint to test N sorted parts in data anyway?
> By my opinion that is very rare (in practice it is practically
> impossible).
>
> I think I have explain that mentioned created data are pointless.
> Median of three will have not problem with two sorted parts, but in
> generally may be slower than middle element variant.
>
> If you to concat two sorted Tlist, Megesort is much better solution.
> Anyway, why complicate banchmark for that and similar preparation?
>
> Perhaps is better that we concenrate on first three mentioned
> situations, which theory also suggest for testing sort algorithm
> effectiveness.
The benchmark should not take the algorithm used into consideration.
For RTL use there should be one function which performs best on a
series of tests we consider representative for realistic usage.
Pathological cases are not likely a large fraction in this, unless the
alogirthm in question happens to have many realistic pathological cases.
QS pathological cases are a very small fraction of the total list space
BTW. With normal pivot choices (middle element or median-of-three)
these are also very unrealistic cases. Note that first element pivot
implementations do get realistic worst cases (namely the sorted lists).
.
- References:
- Fastcode Sort B&V version 0.8
- From: Avatar Zondertau
- Re: Fastcode Sort B&V version 0.8
- From: Sasa Zeman
- Re: Fastcode Sort B&V version 0.8
- From: Avatar Zondertau
- Re: Fastcode Sort B&V version 0.8
- From: Sasa Zeman
- Re: Fastcode Sort B&V version 0.8
- From: Avatar Zondertau
- Re: Fastcode Sort B&V version 0.8
- From: Avatar Zondertau
- Re: Fastcode Sort B&V version 0.8
- From: Sasa Zeman
- Re: Fastcode Sort B&V version 0.8
- From: Avatar Zondertau
- Re: Fastcode Sort B&V version 0.8
- From: Sasa Zeman
- Fastcode Sort B&V version 0.8
- Prev by Date: Re: Fastcode Sort B&V version 0.8
- Next by Date: Fastcode Sort benchmark design
- Previous by thread: Re: Fastcode Sort B&V version 0.8
- Next by thread: Re: Fastcode Sort B&V version 0.8
- Index(es):
Relevant Pages
|
Loading