21–30 of 34 posts
The problem I've seen with these languages is they are tough to debug syntax and semantics errors. A typed array programming language would be interesting. When are J or APL expressions well-formed and would some kind of type system help incrementally build and compose expressions?
What's the advantage of using array programming versus using list/array types in other languages? Nothing I saw in this article seems particularly unique to J except the syntax.
Probably the built in support for vectorization, which reduces the amount of code you need to write, and allows your code to be closer to mathematical expressions. Of course there are other languages like R, Julia and Fortran that also have built-in vectorization, and Python adds that with the Numpy library. It makes certain operations much easier to express than with your normal lists/arrays. That's why the Python s…
The problem I've seen with these languages is they are tough to debug syntax and semantics errors. A typed array programming language would be interesting. When are J or APL expressions well-formed and would some kind of type system help incrementally build and compose expressions?
J syntax is very strictly enforced; the rules for verbs are unambiguous and fairly easy to parse as a human. The difficulty arises in learning and committing these rules to memory. For example, every verb is infix, but the right side is evaluated before the left. thus expressions like '2+3 4' is unambiguously different from '4 3+2' (the former evaluates to 14 while the latter is 24). J is a language similar to C in t…
I really hope the markdown has mangled this.
For example, I have a meta language in which we can define a box and unbox:
subcode: box_a
instructions that un-boxes a type ...
BLOCK
instructions that boxes a type ...
subcode: box_b
instructions that un-boxes b type ...
BLOCK
instructions that boxes b type ...
main_code:
&call box_a
&call box_b
your code
Earlier quoted context omitted.
J syntax is very strictly enforced; the rules for verbs are unambiguous and fairly easy to parse as a human. The difficulty arises in learning and committing these rules to memory. For example, every verb is infix, but the right side is evaluated before the left. thus expressions like '2+3 4' is unambiguously different from '4 3+2' (the former evaluates to 14 while the latter is 24). J is a language similar to C in t…
'2+34' is unambiguously different from '43+2' (the former evaluates to 14 while the latter is 24) I really hope the markdown has mangled this.
So, 2 + 3 * 4 is indeed 14 in J. The reason is J does calculations from right to left, so first 3 is multiplied to 4 making 12 and then 2 is added to that making 14.
The expression 4 * 3 + 2 would evaluate in J to 20 - not to 24. That's because first 3 + 2 makes 5 and then 4 * 5 makes 20. All verbs in J are of equal priority and evaluated right to left - no exceptions for arithmetical + - * % they are all equal and only right to left order matters.
May be I got it wrong and it wasn't 2 + 3 * 4 versus 4 * 3 + 2 but something else which would make 14 and 24 as results. But may be it's just a typo.
To me the most interesting part of this article is the part that nobody else seems to be commenting on: the ability to automatically invert a function, even a programmer-defined function. That seems magical! What if I define a hash function? How can it possibly invert that? Clearly there's something interesting going on behind the scenes, and I wish the article discussed what it is, and how (and when) it works. Every…
Basically, you can represent each invertible function by a pair of functions (pseudo-Haskell, because I don't use it very often and can't test on mobile):
data Invertible a b = Invertible { forward :: a, backward :: b }
apply :: Invertible (a -> b) (b -> a) -> a
apply f a = forward f a
invert :: Invertible (Invertible a b -> Invertible b a) (Invertible b a -> Invertible a b)
invert = Invertible { forward = invert', backward = invert'}
where
invert' :: Invertible a b -> Invertible b a
invert f = Invertible { forward = backward f, backward = forward f}
apply invert invert == invert
Earlier quoted context omitted.
I love J. It's elegant, expressive, and concise. Just like regex, it looks like line noise at first, but that is because it's designed to get its job done as efficiently as possible. I think it would be a wonderful way to write deep learning modules, since it is such a powerful tensor manipulation language. Unfortunately however, even although it should be perfectly suited to SIMD and GPU acceleration, this work hasn…
APL (and J by extension) are more tricky to parallelise than you might expect. The frequent reliance on boxing leads to irregular pointer structures, and the absence of compile-time type information makes it hard to generate code at all. APL is usually based on efficient implementations of primitives, but that is certainly too fine-grained to be sufficient for bandwidth-starved devices such as GPUs. I contributed to…
Interesting article. I'm playing with J currently and it is one powerful, yet difficult to learn language. Simple things are simple, but being able to efficiently chain trains of verbs together and think not in terms of loops and normal data structures, but arrays and math/matrix operations takes some training and time to get used to. I'd like to keep it up to obtain a powerful data analysis tool in my arsenal, but I…
(But apparently they can support libraries that have C shared library interfaces, so... there's that?)
Interesting article. I'm playing with J currently and it is one powerful, yet difficult to learn language. Simple things are simple, but being able to efficiently chain trains of verbs together and think not in terms of loops and normal data structures, but arrays and math/matrix operations takes some training and time to get used to. I'd like to keep it up to obtain a powerful data analysis tool in my arsenal, but I…
Yes, it looks like they dropped library support for xml apparently because of some problem with the C implementation of sax (presumably some of the same things that prompted others to migrate to sax2)? (But apparently they can support libraries that have C shared library interfaces, so... there's that?)
The problem I've seen with these languages is they are tough to debug syntax and semantics errors. A typed array programming language would be interesting. When are J or APL expressions well-formed and would some kind of type system help incrementally build and compose expressions?
You may be interested in some recent research[1] on “static rank polymorphism”, a way of statically describing & enforcing the implicit structure in an array language. [1] http://lambda-the-ultimate.org/node/5329