top | item 44510821

(no title)

leprechaun1066 | 7 months ago

It's not because of the left of right evaluation. If the difference was that simple, most humans, let alone LLMs, wouldn't struggle with picking up q when they come from the common languages.

Usually when someone solves problems with q, they don't use the way one would for Python/Java/C/C++/C#/etc.

This is probably a poor example, if I asked someone to write a function to create an nxn identity matrix for a given number the non-q solution would probably involve some kind of nested loop that checks if i==j and assigns 1, otherwise assigns 0.

In q you'd still check equivalence, but instead of looping, you generate a list of numbers as long as the given dimension and then compare each item of the list to itself:

  {x=/:x:til x}3
An LLM that's been so heavily trained on an imperative style will likely struggle to solve similar (and often more complex) problems in a standard q manner.

discuss

order

wat10000|7 months ago

A human can deal with right-to-left evaluation by moving the cursor around to write in that direction. An LLM can’t do that on its own. A human given an editor that can only append would struggle too.

anticensor|7 months ago

Idea: feed the language model the parse tree instead of the textual sequence.

gabiteodoru|7 months ago

Or, even better, also from the cookbook: {(2#x)#1,x#0} But this really borders on obfuscation :P

leprechaun1066|7 months ago

That does require someone to know that the take operator continues to treat the y list as circular when x is a list.

I think this form might be a bit easier: {(x,x)#(x*x)#1,x#0}