Quote:
Originally Posted by connect2janu
-sorry for the code which was written as in word
-i tried, but -my aim is different see in that time[real,user,sys] is giving how much time taken to run the programme,but i want time consumed[taken] to sort a given array[it may be sorted or unsorted array]
|
Okay; that means you need to measure the
user cpu time taken by the sort function only.
Quote:
Originally Posted by connect2janu
-last thing i did what you told:Compile using e.g.
gcc quick_sort.c -Wall -o quick_sort
result:gcc: unrecognized option '-wall'
|
You used
-wall instead of
-Wall , the W must be in uppercase.
Remember that for computers, uppercase and lowercase letters are totally different things. There are features like certain filesystems that are case insensitive, but they are the exceptions, not the rule.
When I compile your program (after renaming it to tjohn.c) using
gcc tjohn.c -Wall -o tjohn I get the following warnings:
Code:
tjohn.c:42:6: warning: return type of ‘main’ is not ‘int’ [-Wmain]
tjohn.c: In function ‘partition’:
tjohn.c:29:1: warning: control reaches end of non-void function [-Wreturn-type]
tjohn.c: In function ‘main’:
tjohn.c:58:8: warning: ‘CLK_TCK’ is used uninitialized in this function [-Wuninitialized]
The first one is because C really expects the main function to be declared
int main(). You should fix that, and end your main with
return 0; (assuming normal, successful exit), or
return EXIT_SUCCESS; if you want to be as portable as possible.
The second one is because sometimes (whenever
i<j) your
partition function falls out of the if clauses, and exits without returning anything.
The third one is because in Linux, there is no such constant as
CLK_TCK. You declared it as a variable in your program, but you don't specify any value. (If it gets set to zero, you'll get a division by zero error.) To convert the result from
clock() you need to use the
CLOCKS_PER_SEC constant instead.
I don't use Windows myself, but the Microsoft references indicate you should use CLOCKS_PER_SEC with clock() there too.
However,
clock() function is very imprecise; it only changes
sysconf(_SC_CLK_TCK) times per second in Linux, CLK_TCK times per second in Windows. Since CLOCKS_PER_SEC is defined by POSIX to always be 1000000, it is increased by several thousand every time it changes; it just changes rather rarely. You get much more precise results by using
getrusage() if possible.
Because your for loops are
(i=0;i<=n;i++) you will actually read and process one more value than you ask for. To loop over the first
n*integers starting with zero, you use
(i=0;i<n;i++). The first
i will then be zero, and the last
n-1. (Just think about it. 0 1 2 3 4 has five integers, doesn't it?)
Your
quick_sort function only handles the case where
low<high. This is not a bug, and actually shields you from another bug: you don't check if the first number,
n, the user first supplies, is sane.
(In a general quicksort function it would be better to add an else case that does the exact same thing, but with
low and
high swapped, so it would do the correct thing even if you supplied them in the wrong order. In your program, you do not need to do that; I'd only add a comment "Since low<high in this program, the case low>high is not handled." into the quick_sort function, mostly to help you remember if you ever choose to reuse the function in some other program.)
Your
partition function fails to do the partitioning. It does a single swap in one case, and copies one element to itself in the other case. (It would not even work as a swap, if j could ever be greater than i).
I could write the function and fix all the other bugs I've mentioned above, but that would be a disservice to you. Besides, I hate cheaters and would never knowingly write anybodys coursework for them; I'd rather gnaw my arms off. (Not because it's wrong, but because it rewards and promotes a type of behaviour that absolutely infuriates me. I really hate cheaters and exploiters, and I'm not talking about schoolwork only; I mean in general.)
Learning to create something new yourself is and should be a great experience. It should boost your self esteem, and open up new possibilities for expression and developing new problem solving skills. It is often hard. Especially at the very beginning it may be very hard, because not only you have to learn something new, but you often must first learn a new way of thinking. It seems that this "pain" -- really, concentration and effort -- is vital to the learning process in humans.
If it was easy, you would not have to learn it at all.
I myself am here because I am addicted to solving technical problems. I, and most members here, won't write or fix your program for you. We usually need to see your efforts first, because without effort, there is no learning; when there is no learning, we get no enjoyment in helping others. (You can always find a mentor to help you learn, but you won't find anyone who'll do your homework for you for free without any form of compensation.)
In this particular case I am a bit frustrated, because I can see you are unaware of the fundamentals of programming. I don't know if you are self-taught and have just accidentally overlooked the introduction, or if you were asleep when they were talked about in the class, or if you have a sub-par mentor or teacher who has for some reason skipped the introduction. It is the part which describes the basic terms and approach; it is like the foundations of a building. Without it, stuff just sinks into the ground, and you may get severe problems later on. It feels like washing a car just before a long trip in rainy and windy weather.
My own background is in physics, so I like to see the terms and assumptions clearly before building anything on them. In most introductions to C programming this stuff is actually interspersed into the first few chapters, probably to get you started as soon as possible without having a few pages of dry text to read first. I guess it works better that way for most people. However, when you jump into algorithms (like quick sort here), you need to have the background or introduction solidly beneath your feet first; otherwise, it's going to be very hard and frustrating. As an example, check out the
C tutorial at cprogramming.com.
If you are following some course instead, I recommend you read the introduction and first few chapters first to see if there are concepts and themes that may "jolt" your thinking. Or perhaps review the previous courses. Do not bother remembering any details like function prototypes, just try to
understand the terms and descriptions and explanations in the text. The syntax and details can be checked later on.
My own first commercial gig as a programmer was more than half a lifetime ago, and I've never needed to rely on my memory for the details. I always have a spare window open to peruse the man pages and documentation, to check and verify. And I do. What I do have, is a very deep and thorough understanding. (I'm very proud, perhaps a bit too proud, of my skills.) A good memory may make you a faster coder, but it is not at all important. But, without understanding, you'll never get beyond the basics, or to where you can enjoy programming.
In practical terms, I'll be glad to help you further, but only if you're willing to spend some serious effort yourself first. You'll find you get much better response and help, if you make sure you express yourself, your efforts, and your problem carefully and in detail. No need to call anyone sir either, we're all peers here.
Hope this helps,
