Live data from Hacker News

Trap – Transformers in APL

github.com

21–30 of 32 posts

Re: Trap – Transformers in APL

#21

Earlier quoted context omitted.

There is the famous '17 line' compiler here https://scholarworks.iu.edu/dspace/items/3ab772c9-92c9-4f59-... (I got the t-shirt)

That's a phd dissertation with hundreds of pages, wrong link maybe?

No, it appears on page 210 (logical page 220).

Re: Trap – Transformers in APL

#22
post #12

> Though APL may strike some as a strange language of choice for deep learning I've actually spent the better part of last year wondering why we _haven't_ been using APL for deep learning. And actually I've been wondering why we don't just use APL for everything that operates over arrays, like data lakes and such. Honestly, APL is probably a good fit for compilers. I seem to remember a guy who had some tree-wrangling…

> I've actually spent the better part of last year wondering why we _haven't_ been using APL for deep learning.

JAX?

Re: Trap – Transformers in APL

#25
post #11
post #6

Earlier quoted context omitted.

> APL could work well with gpus I've seen at least an APL implementation running on top of Julia, thanks to macros. Julia has good GPU support, and it makes it easy to compose that support with any library. However, kdb+ and q, which are APL descendants, have good GPU support already: https://code.kx.com/q/interfaces/gpus . But licenses are not cheap...

GPUs can even run APL as a higher level programming language. It's the only abstract language I've ever heard to run on a GPU. Arrays in, Arrays out. A gpu is array programming hardware. I hope one day its normal like the 1000s of CPU languages. Would be nice to have more than 10 gpu languages.

Check out https://github.com/Rust-GPU/rust-gpu if you have not seen it

Re: Trap – Transformers in APL

#26
post #15
post #11

Earlier quoted context omitted.

GPUs can even run APL as a higher level programming language. It's the only abstract language I've ever heard to run on a GPU. Arrays in, Arrays out. A gpu is array programming hardware. I hope one day its normal like the 1000s of CPU languages. Would be nice to have more than 10 gpu languages.

StarLisp on the Connection Machine, which is kind of early attempt to what GPU became. Futhark is another more recent example.

CM-Lisp was closer to that vision, though it was never (TMK) fully implemented, unlike StarLisp.

https://dl.acm.org/doi/pdf/10.1145/319838.319870

Re: Trap – Transformers in APL

#27

Hello everyone, I am the author of this project. If anyone has any questions concerning trap, I'd be more than happy to address them.

I’m too ignorant on the subject to have smart questions, so I’ll state instead: that’s brilliant. Terrifying, but brilliant. If someone locked me in a box and said I had to use this for everything, I imagine I’d either break down crying or write an AGI in a page.

Well done.

Re: Trap – Transformers in APL

#28
post #6

> Though APL may strike some as a strange language of choice for deep learning, it offers benefits that are especially suitable for this field: First, the only first-class data type in APL is the multi-dimensional array, which is one of the central object of deep learning in the form of tensors. This also signifies that APL is by nature data parallel and therefore particularly amenable to parallelization. Notably, th…

> APL could work well with gpus I've seen at least an APL implementation running on top of Julia, thanks to macros. Julia has good GPU support, and it makes it easy to compose that support with any library. However, kdb+ and q, which are APL descendants, have good GPU support already: https://code.kx.com/q/interfaces/gpus . But licenses are not cheap...

This looks like an invocation of a C++ CUDA kernel through an FFI. It is not running k or q directly on the GPU.

Re: Trap – Transformers in APL

#29

Earlier quoted context omitted.

> APL code can be directly mapped to algorithms or mathematical expressions on a blackboard and vice versa After looking at the code, I find this claim questionable.

After looking at HN comments for years, I find this low effort dismissal downvoteable. APL was originally a rewrite and normalisation of traditional math notation for use on blackboards. Before it was anything to do with computers it was linear algebra without all the bizarre precedence rules and with some common useful operations.

Ok, well, I understand it may have been invented with that goal, but it frankly does not look like blackboard notation at all. This is not lower effort than your rebuttal “yes it does, in fact it was invented that way”.

I agree with a sibling comment, also heavily downvoted, that the real blackboard notation is linear algebra notation. Either that, or pseudocode. Python and Haskell look like pseudocode. This doesn’t, and it doesn’t matter what the developer was targeting, he didn’t hit the target.

Re: Trap – Transformers in APL

#30
post #10
post #7

Earlier quoted context omitted.

APL was invented by Iverson as a blackboard notation because he felt the existing notation was awkward/insufficent for describing computation/algorithms

linear algebra notation is the real notation (on a blackboard). aka the language of AI. the medium is just the message format.

I agree, linear algebra or pseudocode.
Post reply on HN