Linear algebra - I wouldn't say so. Vectorization - yes, to a certain extent; whenever you'd have a loop, you have to remind your self that it's implicit - and that forces you to think about the collection as a whole instead of a single element of the collection. Sometimes there is apparently no collection to begin with. That, in turn, makes you think why - is it actually correct, do you have a good design?
In J it's much more natural to load a whole dataset into memory and then work with it as a whole. To make it easier, you're strongly nudged to design your data structure simply and uniformly. Thinking about clarity of data structures has many advantages - e.g., clearly seeing the algorithm as a whole, being able to pinpoint (and question) exceptions, optimize on the high(est) level...
That doesn't mean J can't do sequential processing - but if you choose that, you want to understand why: is it the nature of the problem or is it a (questionable) implementation detail?
Some start learning J by using it as a calculator. Indeed, what could be easier in the beginning - typing 2 + 2 <Enter> produces expected result, same for 3 * 4 and 5 - 1, then you have built-in exponent (^3 produces 20.0855), logarithm (^. 20.0855 - kinda easy to remember, an inverse function), factorial (!6 makes 720)... Gradually it becomes less conventional - order of operations is always right-to-left (as in sqrt(sqrt(sqrt 2))) - that would be %: %: %: 2), negative numbers look like _1, _2, _3, sine and cosine are in the family of o. functions - 1 o. 1.5 gives 0.997495, 2 o. is 0.0707372 - and you're also allowed something like 5 + 1 2 3 which returns 6 7 8. A few more iterations - and you can use moderately complex expressions with infix notation, typing quite economically. Then vectorization gradually grows in more complex expressions...
So concretely, consider the following problem. I'll tell you the python way, maybe you could tell me the J way. I want to simulate a random walk, run a statistical test on it at each time, then find the first time when the test returns positive.
In numpy:
data = cumsum(bernoulli(p).rvs(1024*16))
test_statistic = special.xlogy(data, p) * ... other stuff...
first_pos = where(test_statistic > b)[0][0]
bernoulli(p).rvs(1024*16) generates a random array of the form [0,1,0,0,1,0,1], and where(...) returns an array of places where the condition is true.
If we translated this code to J, would it be idiomatic?
(Incidentally it does happen to be wildly inefficient - a simple for loop (in C) with no arrays is about 100x faster.)
In J it's much more natural to load a whole dataset into memory and then work with it as a whole. To make it easier, you're strongly nudged to design your data structure simply and uniformly. Thinking about clarity of data structures has many advantages - e.g., clearly seeing the algorithm as a whole, being able to pinpoint (and question) exceptions, optimize on the high(est) level...
That doesn't mean J can't do sequential processing - but if you choose that, you want to understand why: is it the nature of the problem or is it a (questionable) implementation detail?
Some start learning J by using it as a calculator. Indeed, what could be easier in the beginning - typing 2 + 2 <Enter> produces expected result, same for 3 * 4 and 5 - 1, then you have built-in exponent (^3 produces 20.0855), logarithm (^. 20.0855 - kinda easy to remember, an inverse function), factorial (!6 makes 720)... Gradually it becomes less conventional - order of operations is always right-to-left (as in sqrt(sqrt(sqrt 2))) - that would be %: %: %: 2), negative numbers look like _1, _2, _3, sine and cosine are in the family of o. functions - 1 o. 1.5 gives 0.997495, 2 o. is 0.0707372 - and you're also allowed something like 5 + 1 2 3 which returns 6 7 8. A few more iterations - and you can use moderately complex expressions with infix notation, typing quite economically. Then vectorization gradually grows in more complex expressions...