-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Just brings the code for the new sorting. Intentionally have not yet … #1541
base: develop
Are you sure you want to change the base?
Conversation
…changed the names to avoild name collision, nor included in the build system
contains | ||
|
||
subroutine SORTL(A,Bi,Bl,Br,Bd,Ci,Cl,Cr,Cd,Di,Dl,Dr,Dd,DIM) | ||
integer(kind=8), intent(INOUT) :: A(:) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I imagine we'll need to generalize these for NAG, since kind=8
doesn't work there...
if (present(Bi)) then | ||
call QSORTL44(A,Bi,Dm,len,1,0) | ||
elseif(present(Bl))then | ||
call QSORTL84(A,Bl,Dm,len,1,0) | ||
elseif(present(Br))then | ||
call QSORTL44(A,Br,Dm,len,1,0) | ||
elseif(present(Bd)) then | ||
call QSORTL84(A,Bd,Dm,len,1,0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah - no, this is a terrible/unacceptable style. In theory all 4 of these args could be present. The proper way todo this is to have separate interfaces for each case.
// If the length of the sort exceeds a critical value (MAX_SORT_LEN), | ||
// it halves it repeatedly until it is below this value, does | ||
// order LEN/MAX_SORT_LEN sorts, and shuffles these in ascending order. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment leaves out the "why". Is it to give better performance? To avoid some memory limitation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only Max could answer "why". My guess is for better performance... I do not think we exceed the threshold currently. Which brings the question, if the "swap-and-shuffle" scheme was well tested
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember one thing. I changed the sort so it pickd the middle item as pivot point. Before that, it chose the first one as the pivot point. So if an array is already sorted, it takes O( n^2) to sort again. If the array is very large, it would be very slow. It helps if it limits the max size.
Probably should be replaced with radix-sort in any event. |
This issue has been automatically marked as stale because it has not had recent activity. If there are no updates within 7 days, it will be closed. You can add the "long term" tag to prevent the Stale bot from closing this issue. |
Marking as long-term |
…changed the names to avoild name collision, nor included in the build system
Description
Related Issue
Motivation and Context
How Has This Been Tested?
Types of changes
Checklist: