Liutauras Vilda wrote:@OP
Very nicely indented and formatted code. Have a cow for disciplined approach on that.
Campbell Ritchie wrote:Once you have passed all your exams and got a job, you will sort your array like this
Winston Gutkowski wrote:
Dawid Smith wrote:Still, what do you think about writing your own version just for practice?
Nothing wrong with it at all; just don't expect too much in the way of enlightenment unless you repeat the process at least 10,000 times, or work with arrays involving millions of objects, which probably isn't very practical.
Winston Gutkowski wrote:I'm with Junilu - right now, you might get more mileage out of looking at sorting algorithms and working out why you might use them; but don't ignore the simple ones simply because they're supposedly "inefficient" (O(n²) or worse).
Junilu Lacar wrote:If it's your first try, then it's a pretty good try. This algorithm, however, is quite inefficient. If I'm not mistaken, it is best case and worst case O(n²) which means that for large arrays, it takes a very long time, even if it's already sorted. You're basically looking through the entire list NxN times to find the largest unsorted element, including the elements that you've already looked at before and determined to be larger than all others.
Sorting algorithms are a basic area of study in computer science so I suggest you take a look at the various ones already existing and commonly used and compare them with yours to see what kind of improvements you might make.
Junilu Lacar wrote:Instead of writing your own printer() method, you could just use java.util.Arrays.toString() to display an int. To display nested arrays, you can use Arrays.deepToString()
Carey Brown wrote:It would be interesting to see some performance numbers for very large arrays comparing your method to a simple bubble sort.
Your method has these nested loops
A bubble sort has these
Note the inner loop gets shorter and shorter as the outer loop progresses.
Liutauras Vilda wrote:Dawid Smith,
CowGratulations, your topic has been published in our CodeRanch Journal August Edition.
A copy of journal you could find here -> https://coderanch.com/wiki/715405/CodeRanch-Journal-August
Other than that, you, as everybody else supposed to get one emailed to you
Winston Gutkowski wrote:
Dawid Smith wrote:Hello. I've attempted to code a recursive version of a binary search algorithm. It seems to be working, but I would love to hear feedback from you guys.
Oddly enough, your program contains the same mistake as almost all binary chops ever written, so don't worry, you're in good company. :-)
The problem is with the expression 'half = (a + z) / 2'.
It may look right, but it contains a dangerous flaw, which you'll likely never reproduce because all the lists you deal with will be too small.
The reason is that it will not always produce the correct result because of integer overflow.
If the sum of a and z is >= 2^31, the result will be a negative number, which the compiler will happily divide by 2, and screw up your lovely calculation.
Luckily, there is more than 1 solution:
1. half = a + ((z - a) / 2) - hopefully fairly obvious.
2. half = (a + z) >>> 1 - as fast as it gets, and guaranteed to work provided a and z are >= 0, but a bit "mystical", and not directly translatable to other languages.
For more info check out this.
Stephan van Hulst wrote:You've already heard good suggestions from my colleagues. I'd like to add that method/class names should not contains hints about their implementation. It doesn't matter whether the search is performed through recursion or by looking in a crystal ball, the important part is that it searches. This restriction does not hold for private methods, as private methods are used solely for implementation.
Validate inputs to non-private methods.
Avoid reassigning values to method parameters, especially if the method is a "pure function" (a static method whose outcome depends only on the arguments).
Perform early returns to avoid the "arrow anti-pattern", where large code blocks are scoped deeply.
Finally, don't use magic values for special results. Use an appropriate type instead. In this particular case, I would use OptionalInt as the return type:
Liutauras Vilda wrote:
Dawid Smith wrote:
I am pleasantly surprised you wrote the comment for private constructor to clarify your intention to your code reader - very well done on that! However, comment is slightly imprecise. Isn't really clear what you mean by empty, whether no parameters specified, or body empty - in anyway, non of these are the reasons which prevent object from instantiation. What prevents is its privatness. So comment probably better would read as: "intentional private constructor to prevent class's instantiation" or similar along those lines.
So you renamed your class. Alright. To ArraysSortingMethods. >? Why? I see one method inside, which performs search within the array. What does it have to do with sorting? If your plans are to have also function(s) which sort array, then give to class some broader name, which covers both. In fact Stephan already suggested seem to be not a bad name for your needs.
Again. You have variables: arr, ar. First they are some sort of abbreviations (personally to me, abbreviations are most annoying things, but that's not the reason to improve). Secondly, they describe implementation details. You don't need to do that, int <-- this is what denotes that it is an array, and in particular ''. Why you don't want to call them simply "numbers"? If you decide at some point to change data structure they are in, you wouldn't need to rename variable, but again, that's not the main reason to change it, main reason is the clarity, what this array holds...
Try to avoid placing array type definition after variable name. That is unconventional. Plus if you read it out loud it doesn't make sense, because this parameter defines "an array of strings", not an array of args. One less known thing, if you ever decide to change it to variable arguments (so called varargs), and you would have it defined as 'String args...' - you'd get compilation error, while 'String... args' would work just fine.
! Your indentation is off again. Lines 4, 5, 22, 26, 27, 32, 33 and 36 this time (indentation level differs). Plus your braces placing style is different in TestingClass as well as in ArraysSortingMethods class - consistency is important.
Liutauras Vilda wrote:Note: don't get annoyed by the things we point out (I know it can be frustrating), but the sooner you become more disciplined, the more better and less chaos in your code will be.
Ryan McGuire wrote:
Yes, it's perfectly valid to leave the braces out. If you scoff at my suggestion, continue to omit braces in such cases and ever admit to getting bitten by something like...
... I will just point and laugh. Ok, maybe that's a bit harsh. I'll probably have some sympathy for you, but you see my point.