Re: Fasctode - Sort estimating complexity and B&V
- From: Anders Isaksson <anders.isaksson@xxxxxxxxxxxx>
- Date: Tue, 11 Oct 2005 11:49:23 +0200
On 10 Oct 2005 14:06:43 -0700, "Sasa Zeman" <public@xxxxxxxxxxx> wrote:
> You have vote for that to deliberatly creating worst-case sequence
> for any quicksort version or any other function (if exist)?
Yes, why not. Who says that benchmarks with known killer patterns need
to use lists with a zillion elements. Each benchmark can work in its own
way. All we need is to *find* the losers :-)
> Still there is no exact answer from Avatar or any of who vote for
> that how exact weigthing of time for these sequences and what
> effect will be on total result...
Of course not. There's no use spending time deciding weights until we
have firmly decided what benchmarks should be part of the B&V. One step
at a time.
> All in all, specificly this voting are prematures without
> previously known exact all the facts.
As the B&V is used to *find* some of those facts, I think knowing them
all beforehand is impossible. If *all* facts are known, we don't need a
benchmark.
> And number of voters are too small (only 7?).
All we can do is to have a vote and wait for the responses. We have to
assume that those who don't vote don't care. There is no Fastcode rule
about a minimum number of voters (maybe there should be, but there
isn't).
> Since this will eventually be a Borland function,
There are *no* guarantees/promises at all that Borland will use *any*
Fastcode function. The main purpose of Fastcode has been to produce fast
code. The fact that Borland has incorporated some (very few) of them is
a bonus, but not a main goal (correct me if I'm wrong).
> And ironically, one vote is crucial..
I don't see any irony in that. *Everyone's* vote is important.
>What is a base of decision that target benchmark ammount
>of items be a 2^22 except to see efect on maximum limit
>size items who never used in practice?
I guess Avatar just chose a number that was 'large enough' but not 'too
large'. Of course the limits for the benchmark are open for discussion.
> I do not know anyone who ever use even more than 2^14 items in Tlist.
(Actually I find that a rather stupid remark - you know better than
that!)
OK. Add one. In my BlockCAD program I sort the parts in the 'correct'
drawing order (painter's algorithm). The largest model I've seen so far
had over 56000 parts (to be re-sorted again and again when the model is
rotating). I would think sorting much more than 2^14 elements is quite
common. And the choice of sorting algorithm is mostly irrelevant when
sorting small amounts.
>Some algorithmms better work on such small ammount of
>data instead on 2^22...
And a good function will probably have the sense to choose sorting
method according to the number of elements to sort. Maybe even spend
some time on timing the Compare function, and choose method depending on
the outcome of that. Who knows?
> Many important issues are still open and have no rational/real answers.
Are you saying that rational/real answer cannot be found? If so it would
be a dead end to see it as 'important issues' as we will never solve
them.
Or are you saying that we have not yet found the rational/real answer?
If so, isn't that what we're trying to do with the help of this
discussion?
> Of cours, I can speak only by my own more than 15 years experience,
> but hardly that one man can have all correct answers in hands.
If we're counting years I can add 25 (working) + 6-7 (studying), but I'm
not sure that makes me any wiser. The point of a discussion is to try to
reach a decision using the combined knowledge (and opinions!) of all
participants.
--
Anders Isaksson, Sweden
BlockCAD: http://web.telia.com/~u16122508/proglego.htm
Gallery: http://web.telia.com/~u16122508/gallery/index.htm
.
- Follow-Ups:
- Re: Fasctode - Sort estimating complexity and B&V
- From: Sasa Zeman
- Re: Fasctode - Sort estimating complexity and B&V
- References:
- Fasctode - Sort estimating complexity and B&V
- From: Sasa Zeman
- Re: Fasctode - Sort estimating complexity and B&V
- From: Anders Isaksson
- Re: Fasctode - Sort estimating complexity and B&V
- From: Sasa Zeman
- Fasctode - Sort estimating complexity and B&V
- Prev by Date: Re: Fastcode Library Design
- Next by Date: Re: ScaleDown
- Previous by thread: Re: Fasctode - Sort estimating complexity and B&V
- Next by thread: Re: Fasctode - Sort estimating complexity and B&V
- Index(es):
Relevant Pages
|