I guess I'm a real computational scientist, because that first line to me wasn't special, that's how I've always written python.
What learning APL taught me about Python
61–70 of 104 posts
Re: What learning APL taught me about Python
#62I feel like this kind of operation on a list feels more naturally expressed by filtering the list and taking the length of the filtered list. Like this line of JS feels so much easier to read than that line of python: ages.filter(age => age > 17).length Directly translating this approach to python: len(list(filter(lambda age: (age > 17), ages))) Although a better way to write this in python I guess would be using lis…
> Obviously if the function is on a hot path iterating and summing with a number is far more efficient versus filtering. I got curious and checked this in Rust, the generated assembly is the same! https://rust.godbolt.org/z/jhGWdYPz1
Because you're not actually creating a filtered list, you're just filtering an iterator.
Re: What learning APL taught me about Python
#63I feel like this kind of operation on a list feels more naturally expressed by filtering the list and taking the length of the filtered list. Like this line of JS feels so much easier to read than that line of python: ages.filter(age => age > 17).length Directly translating this approach to python: len(list(filter(lambda age: (age > 17), ages))) Although a better way to write this in python I guess would be using lis…
[deleted]
Re: What learning APL taught me about Python
#64Someone else has mentioned it, but I would have gone with:
sum(1 for age in ages if age > 17)
Re: What learning APL taught me about Python
#65> Another big thing that APL made me realise is that the Boolean values True/False and the integers 1/0 are tightly connected Amen! It's of course also a C language tenet, and a great one. Life is so much simpler and more flexible when true and false are 1 and 0. It drives me crazy when I need to use a language where the logical operators only work on bools and the arithmetic only on ints, or some coercions work and…
> Another big thing that APL made me realise is that the Boolean values True/False and the integers 1/0 are tightly connected
Not that tightly. Which is why C and Python, which both started out with boolean values just being integers, eventually retrofitted booleans to the language. Conversions come back to bite you.
Re: What learning APL taught me about Python
#66I find that the more language you learn the better you can utilize all of them. Also, Python is a wonderful functional language when used functionally.
It is a poor functional language. List comprehensions (from Haskell) are nice, but the rest is garbage. Crippled lambdas, no currying, "match" is a clumsy statement, weird name spaces and a rigid whitespace syntax. No real immutability.
IIRC, Haskell’s list comprehensions are lifted from Erlang.
Re: What learning APL taught me about Python
#67What is it about Python? A pretty trivial feature that has been known for 30 years (and is present in NumPy) is made into a whole blog post, linked to APL to sound more interesting and is on the front page for a day.
If the allegedly "most popular language" (confirmed by Gartner and Netcraft) needs that much proselytizing, perhaps it is artificially popular? Or has voting rings?
Re: What learning APL taught me about Python
#68I feel like this kind of operation on a list feels more naturally expressed by filtering the list and taking the length of the filtered list. Like this line of JS feels so much easier to read than that line of python: ages.filter(age => age > 17).length Directly translating this approach to python: len(list(filter(lambda age: (age > 17), ages))) Although a better way to write this in python I guess would be using lis…
The blog starts out with mentioning other reduce operations in Python: 'prod from the math module; min; max; any; all; and "".join'. In APL those are: ×/ product reduce ⌊/ min reduce ⌈/ max reduce ∨/ logical OR reduce (any bool set) ∧/ logical AND reduce (all bools set) ,/ catenate reduce (join without spaces) These all show a pattern of connection clearly where the Python names don't, that they are related operation…
Interestingly most (if not all) python examples also work in julia.
Instead of using sum one can also use count, which might be more readable:
julia> count(age > 17 for age in ages)
Or even shorter:
julia> count(ages .> 17)
Under the hood many of the functions are implemented using the reduce function (similar to / in APL):
julia> reduce(+,ages .> 17)
I think many languages in data science have been influenced by APL. But sometimes this influence come from an intermediate language like matlab.
Re: What learning APL taught me about Python
#69I feel like this kind of operation on a list feels more naturally expressed by filtering the list and taking the length of the filtered list. Like this line of JS feels so much easier to read than that line of python: ages.filter(age => age > 17).length Directly translating this approach to python: len(list(filter(lambda age: (age > 17), ages))) Although a better way to write this in python I guess would be using lis…
I like to leverage some FP to bring readability to python
from toolz import curried, pipe
pipe(ages,
curried.filter(lambda age: age > 17),
list,
len)
You can make your own pipe function to avoid 3rd party dependencies
import functools
pipe = lambda *args: functools.reduce(lambda acc, el: el(acc), args)Re: What learning APL taught me about Python
#70The only thing this does for me is ask why its not named count instead of sum.
numpy (which is inspired by Matlab which is inspired by APL) does indeed have a count_nonzero function, which is intended to be used in situations like this. Unfortunately, it (like most of numpy) doesn't work with generators, just array-like objects (aka numpy arrays and python lists), so it has the same memory performance issues as filtering and using len. If your input was a numpy array to begin with you could ski…
Here, is "broadcasts" like apply or map of functional programming?