+- Southperry.net (https://www.southperry.net)
+-- Forum: Social (https://www.southperry.net/forumdisplay.php?fid=14)
+--- Forum: Rubik's Cube (https://www.southperry.net/forumdisplay.php?fid=58)
+--- Thread: Recursion in Java (/showthread.php?tid=41390)
Recursion in Java - Five Second Pose - 2011-05-03
So I'm working on some sorts here, merge and quick. My merge works lovely. I get a stack overflow error with my quicksort method, so I'm not... recursing properly or something. Never exits the recursion. Ignore showProcess, that's for something else. l is the length of the array minus one.
Quicksort
Recursion in Java - Hazzy - 2011-05-03
Oh god, the white space burns....
Could you please add [code]?
Recursion in Java - Five Second Pose - 2011-05-03
I honestly forgot that tag existed. XD
Recursion in Java - Fiel - 2011-05-03
Please don't use "l" as a variable. It's too hard to distinguish what is "l" and what is "1" in the code. Also, why don't you use "toSort.getLength() - 1;" instead?
I really don't know about how quicksort works, so I'll leave that alone.
Recursion in Java - Cyadd - 2011-05-03
Please change the variables as Fiel said, I'm getting confused with the 1 and l.
Recursion in Java - Nikkey - 2011-05-03
Recursion in Java - Five Second Pose - 2011-05-03
Oh. I massively overcomplicated that. I see now, I forgot the conditional statements. derp
Recursion in Java - Kalovale - 2011-05-03
Why do we have that boolean without ever using it? Nevermind, I can't read.
I think the first statement is rather redundant. We've just entered the while loop, there's no reason to check right now whether or not "hi" is truly larger than "lo", is there? I guess you could do it just to be consistent with the other while, it didn't really help clarify things for me when I read it though.
There is also no need to specify that "lo <= length", since hi is always less than or at most equal to length, and you've already forced lo < hi before even doing anything.
Code:
while (lo < hi) {
while (toSort[lo] <= pivot && lo <= length && hi > lo) // <--- right here
lo++;
while (toSort[hi] > pivot && hi >= low && hi >= lo)
hi--;Also, if it were me, I'd choose more distinguishable names,. leftIndex and low for example.
look in indexes on the left of the pivot point to find a value that doesn't belong there translates nicely into:
Code:
while (toSort[leftIndex] < pivotValue) {
leftIndex++;
}I haven't really done any collaborative coding, so I still don't have a good idea what criteria constitute readable codes. I do know, though, that I had trouble reading yours. Could just be my limited understanding regarding quickSort itself, so iunno.
Recursion in Java - Five Second Pose - 2011-05-03
Trust me, it used to be worse before. I used to name all my booleans derpington regardless of what they did. XD
Haven't started commenting yet because it didn't work at the time, so. Is the lack of comments the only confusing thing? Readability is something I've been working on, I'd like to know where I can improve on that.
Recursion in Java - Kalovale - 2011-05-03
Rayquaza2233 Wrote:Trust me, it used to be worse before. I used to name all my booleans derpington regardless of what they did. XD
Haven't started commenting yet because it didn't work at the time, so. Is the lack of comments the only confusing thing? Readability is something I've been working on, I'd like to know where I can improve on that.
Now THAT is something I would use...
At my level, I think it is easier to read cascading levels of conditions than combined ones. While they are essentially the same thing from a logical standpoint; from a programming standpoint, indentation helps you quickly (and accurately) grasp the scope of each conditional.
Another thing I find worth trying is commenting as you go through the logic, kinda like pseudocode. I've always started commenting AFTER everything works as well, it's always been more of a "documentation" for anyone reading my code. But I've come to realize that I could document it for myself as well, multi-tasking on both micro and macro levels is going to take a heavy toll on your head, unless you have a multi-core brain.
Recursion in Java - Stereo - 2011-05-04
I write comments before, during, and after writing code. In order to develop code, I'm thinking about the problem, and I like a record of that, so a multitude of comments. I guess that applies a little less when you're given an algorithm and just have to implement it.
Recursion in Java - SaptaZapta - 2011-05-04
Stereo Wrote:I write comments before, during, and after writing code. In order to develop code, I'm thinking about the problem, and I like a record of that, so a multitude of comments. I guess that applies a little less when you're given an algorithm and just have to implement it.
Same here.
Since we rarely do "flowcharts" and "pseudo-code" except in extreme cases, the comments I put in before the code serve that same purpose of keeping a general overview of the algorithm in my mind and view.
Then, every line or chunk of code that required more than a second's thought to write, gets documented as it is written. So I don't have to spend ten times as long, later, trying to understand what I did (or tried to do) there - and anyone else reading it doesn't mistake what it does, how, and why, either.
After the coding and debugging are done, there are usually very few comments that need adding. Mostly stuff like formal headers required by project documentation rules.