Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Do nesting level
Message
From
03/10/2001 03:02:30
 
 
To
02/10/2001 14:34:08
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
00557186
Message ID:
00563443
Views:
30
Hi!

I agree with you, and I know this algorithm and can make a couple of other sorting algorithms in VFP that have their own cons and pros. However, let me point you once again: we're talking about GENERIC situation where we do not know distribution. In such case the most effective algorithm is a binary sorting algorithm, that is implemented in asort() using C++.

Take care.

>Vlad:
>
>>>> Custom algorithm over large number of object will work slowly, it cannot be more quick than a C++ routine in ASORT(). Also, there are only a few lines of code for this approach, when custom sorting algorithm is a lot of programming...
>
>>> I disagree.
>>>
>>> ASORT is not always faster than a custom program because ASORT uses one of the sorting algorithms and there is no single algorithm that is faster than all other algorithms when sorting arrays whose elements may or may not be randomly ordered. ASORT is fast but it's not always the best thing to use if you have a good idea how the elements are distributed within the array.
>
>> Do you want to discuss this topic from the sciense point of view? Here we do not used ANY assumption about distribution of record. Anyway, a loop and a lot of statements in VFP FAR slower than ASORT() for ANY distribution, as far as I know, just because VFP commands are done by pure interpreter, when ASORT() is a C++ code done by processor. Maybe, for little number of elements VFP routine can be more quick, however, with large number of elements it is not comparable.
>
>I disagreed with your blanket statement that ASORT is always faster than a custom algorith, nothing else. For example, the following program
>
>Dimension laData[50000]
>
>For i = 1 To 50000
>   laData[i] = i
>EndFor
>laData[1] = 2
>laData[2] = 1
>
>llLoopAgain = .T.
>lnFirstSwitch = 1
>lnLastSwitch = 49999
>lnStart = Seconds()
>Do While llLoopAgain
>   llLoopAgain = .F.
>   For i = Max(1, lnFirstSwitch) To Min(lnLastSwitch, 49999)
>      If laData[i] > laData[i+1] Then
>         lnLastSwitch = i + 1
>         If Not llLoopAgain
>            llLoopAgain = .T.
>            lnFirstSwitch = i - 1
>         EndIf
>         lnTemp = laData[1]
>         laData[i] = laData[i+1]
>         laData[i+1] = lnTemp
>      EndIf
>   Next
>EndDo
>MessageBox(Str(1000 * (SECONDS() - lnStart), 8, 1))
>
>will perform faster than ASORT on the data provided. I am aware that the data is quasi-ordered but that's the whole point: if you have a good idea of the distribution of the data, you may be able to write a custom algorithm to take advantage of it. Note that the program is just a few lines long and you could even remove all references to lnFirstSwitch and lnLastSwitch if you are willing to take a performance hit (but not always).
>
>You and Cetin suggested to pad the array elements with blanks to make them all the same size, sorting the array, and then removing the trailing blanks to retrieve the initial values. You harcoded the maximum length and assumed that none of the initial values contain trailing blanks. You took advantage of some facts you knew about the data, which is exactly my point!
>
>I have responded to your "absolute truths" statement because you are (correctly) recognized as an expert by this community and I didn't want programmers to accept your truth without questionning its veracity. A programmer may decide to always use ASORT and I am fine with that as long as they know why they made that decision.
>
>Daniel
Vlad Grynchyshyn, Project Manager, MCP
vgryn@yahoo.com
ICQ #10709245
The professional level of programmer could be determined by level of stupidity of his/her bugs

It is not appropriate to say that question is "foolish". There could be only foolish answers. Everybody passed period of time when knows nothing about something.
Previous
Reply
Map
View

Click here to load this message in the networking platform