11–20 of 90 posts
?> sum::{+/x} :" sum + over / the array x
:monad
?> sum([1 2 3])
6
?> count::{#x}
:monad
?> count([1 2 3])
3
Naive array programming is not really high performance in my book, because performing a lot of trivial arithmetic on large arrays leads to poor locality and high bandwidth pressure. The better alternative is SPMD, i.e. something like CUDA or ISPC for CPUs. This is possible with some type of JIT if the numpy style of programming is to be maintained, for example tinygrad.
You are absolutely right, naive array programming might be much faster than raw python but it will never be high performance because you can't use caches and memory bandwidth effectively.
There's also a subset - possibly even a silent majority - of problems where you're doing fairly intensive calculation on data that fairly comfortably fits into a modern CPU cache. For those, I'd still expect SIMD to be a great choice from a performance perspective.
Naive array programming is not really high performance in my book, because performing a lot of trivial arithmetic on large arrays leads to poor locality and high bandwidth pressure. The better alternative is SPMD, i.e. something like CUDA or ISPC for CPUs. This is possible with some type of JIT if the numpy style of programming is to be maintained, for example tinygrad.
I think it's an oversimplification to say SPMD is a better model full stop. Array programming has the advantage that the implementer optimizes a specific function, and its interaction with the rest of the program is much simpler: all the data is available at the start, and the result can be produced in any order. So things like multi-pass algorithms and temporary lookup tables are possible, particularly valuable if the program isn't spending that much time on arithmetic but rather "heavy" searching and sorting operations. Not that I claim NumPy or CuPy do a good job of this. Sections "Fusion versus fission" and "Dynamic versus static" are relevant here, I think: https://mlochbaum.github.io/BQN/implementation/versusc.html#...
I thought I knew python, but then I saw this: ?> sum::{+/x} :" sum + over / the array x :monad ?> sum([1 2 3]) 6 ?> count::{#x} :monad ?> count([1 2 3]) 3 What?
sum::{} is the creation of a monadic function (which I just learned about because I don't have a CS background)
:" is a comment
sum([...]) is calling the function with a list, and the function will iterate over the list adding each of the elements
count::{#x} is another monadic function that returns the number of elements, which then gets called
I thought I knew python, but then I saw this: ?> sum::{+/x} :" sum + over / the array x :monad ?> sum([1 2 3]) 6 ?> count::{#x} :monad ?> count([1 2 3]) 3 What?
I gather where it says `:monad` it is referring to an operation that had an effect on the interpreter state?
No. In APL deriverd array programming languages, verbs (or functions) are monadic or dyadic : they accept only one or two arguments : In '1 + 1', + is a dyadic operator, while in 'exp 5', exp is monadic. In J, and in APL I guess, left arg is usually understood as 'control data', while right arg is the data upon which calculation is done. Left argument is usually left unchanged after calculations. In this way, is it p…
I thought I knew python, but then I saw this: ?> sum::{+/x} :" sum + over / the array x :monad ?> sum([1 2 3]) 6 ?> count::{#x} :monad ?> count([1 2 3]) 3 What?
Earlier quoted context omitted.
No. In APL deriverd array programming languages, verbs (or functions) are monadic or dyadic : they accept only one or two arguments : In '1 + 1', + is a dyadic operator, while in 'exp 5', exp is monadic. In J, and in APL I guess, left arg is usually understood as 'control data', while right arg is the data upon which calculation is done. Left argument is usually left unchanged after calculations. In this way, is it p…
It sounds unrelated to the monads popularized by Haskell tutorials. Naming coincidence or am I missing something?