So, I’ve finally reached the point in my latest research endeavor at which numbers need to be crunched. Because I’m a programmer, and thus inherently lazy, instead of using a program like Excel which requires me to click at least 3 buttons to get anything useful I decided to take a look at SciPy.
While I’ve messed with Ruby plenty of times in the past and am actually quite fond of it SciPy was my first real experience with Python beyond reading other people’s code or glancing at examples.
Python is some pretty nice stuff. Really nice stuff.
It has the typical map-reduce-filter array functions that seem to be finding their way into more and more of my code, but after writing:
def f(x):
if x < 0:
return 0
else:
return x
new_array = map(f, some_array)
for the umpteenth time I realized I was probably doing it wrong and took a look at list comprehensions. List comprehension is a pretty cool guy. Eh makes working with arrays easy and doesn’t afraid of anything.
It’s amazing how easy it is to fall into the wrong paradigm in a multi-paradigm language.
Although, I’m not sure if
y_scale_dl = reduce(max, [reduce(max, [y[4] for y in x[1][1]]) for x in experiments])
is really that readable/understandable either 
Maybe I’m still doing it wrong?
If I understand this right:
y_scale_dl = reduce(max, [reduce(max, [y[4] for y in x[1][1]]) for x in experiments])
Are those reduce calls really required? i.e. shouldn’t
max(y[4] for y in x[1][1])
give the same thing as
reduce(max, [y[4] for y in x[1][1]])
? So you could have:
max(max(y[4] for y in x[1][1]) for x in experiments)
I think.
I was unaware at the time (doh) that max() will return the max value in a list not just the max of two values
In fact,
max(1, 2, 3, 4, …, n) works as well. I would guess that it gets turned into a sequence.
Shows what I know! (Very little Python!)
So, ya, the reduce() calls are doing nothing here.
Enurable#max has the same functionality in Ruby.