if len(mid) % 2 == 0:
x = int((len(mid))/2.0) -1
y = int((len(mid))/2.0 + 1) -1
new = (int(mid[x]) + int(mid[y]))/(2.0)
y = ((len(mid))/2.0) - 0.5
n = mid[int(y)]
One of the avenues of approach when debugging problematic code is to catalog the function calls within the code.
1. int() 5 in total
2. len() 3 in total
3. print 5 in total
A couple of the print statements (currently appears a part of debugging with log outs) will be replaced with return statements, so # 3 is not a concern.
The first two, though, are a concern. They are adding bulk to the code that messes with readability and logical thought process during the design phase.
The sample comes in as a structure with length. We know this, and can cache that value away in a simple variable. It is not uncommon to see learners store this in a length variable, but again, all that adds to the code is bulk, not real meaning. We can read the statement and know what it is. We are the designer.
n = len(x)
We are not dealing with a full-fledged program, but a utility that an application would call upon to perform a simple task, return a median from a given unsorted data sample in the form of a list. It is up the to caller to manage the labeling, not the utility, in my view.
Our argument tells the reader what is being passed to the utility function. Now when the reader goes to that function,
s = sorted(sample)
they can see that the function takes a sorted copy of the sample_space in the argument. This has no effect upon the original sample which is left unsorted.
Next we begin caching the constants.
n = len(s)
m = int(n / 2)
Now working with only the cached constants and the sorted sample, we can return a median. I leave this to you for your pleasure. Remember to pass your sum to the float() function before dividing by 2 (a counting number that is not expected to be a float).
Another thing to weed out is gratuitous variables…
n serves no function here but to add code bloat. If all we are doing is printing the variable, then just print the value.
That is probably moot by now, but nonetheless revealing. Weed out the pointless.
We’ve already pointed out how repetitive int(y) is.
The bottom line is this… An amateur tore down your program to point out the excesses. That means that you, as an amateur possess, or will soon possess the skill to do the same thing. Bear in mind this is a skill only geared to tearing down YOUR OWN CODE. Don’t stretch your wings in other people’s domains until you are fully satisfied that your own is well in hand.