Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't Force Your LLM to Write Terse [Q/Kdb] Code: An Information Theory Argument

medium.com

Post reply on HN
Print view View original

11–20 of 56 posts

Re: Don't Force Your LLM to Write Terse [Q/Kdb] Code: An Information Theory Argument

#11

Post by dapperdrake »

krackers wrote: post #6
gabiteodoru wrote: post #4

Earlier quoted context omitted.

I agree with you, though in the q world people tend to take it to the extreme, like packing a whole function into a single line rather than a single screen. Here's a ticker plant standard script from KX themselves; I personally find this density makes it harder to read, and when reading it I put it into my text editor and split semicolon-separated statements onto different lines: https://github.com/KxSystems/kdb-tick…

When Q folks try to write C: https://github.com/kparc/ksimple

When EAX and RAX take too long to type.

Re: Don't Force Your LLM to Write Terse [Q/Kdb] Code: An Information Theory Argument

#12

Post by neprotivo »

This approach of solving a problem by building a low-perplexity path towards the solution reminds me of Grothendieck's approach towards solving complex mathematical problems - you gradually build a theory which eventually makes the problem obvious.

https://ncatlab.org/nlab/show/The+Rising+Sea

Re: Don't Force Your LLM to Write Terse [Q/Kdb] Code: An Information Theory Argument

#13

Post by Veedrac »

> Let’s start with an example: (2#x)#1,x#0 is code from the official q phrasebook for constructing an x-by-x identity matrix.

Is this... just to be clever? Why not

    (!x)=/:!x
aka. the identity matrix is defined as having ones on the diagonal? Bonus points AI will understand the code better.

Re: Don't Force Your LLM to Write Terse [Q/Kdb] Code: An Information Theory Argument

#14

Post by quotemstr »

Veedrac wrote: post #13

> Let’s start with an example: (2#x)#1,x#0 is code from the official q phrasebook for constructing an x-by-x identity matrix. Is this... just to be clever? Why not (!x)=/:!x aka. the identity matrix is defined as having ones on the diagonal? Bonus points AI will understand the code better.

The vibe I get from q/kdb in general is that its concision has passed the point of increasing clarity through brevity and is now about some kind of weird hazing or machismo thing. I've never seen even numpy's verbosity be an actual impediment to understanding an algorithm, so we're left speculation about social and psychological explanations for why someone would write (2#x)#1,x#0 and think it beautiful.

Some brief notations make sense. Consider, say, einsum: "ij->ji" elegantly expresses a whole operation in a way that exposes the underlying symmetry of the domain. I don't think q's line noise style (or APL for that matter) is similarly exposing any deeper structure.

Re: Don't Force Your LLM to Write Terse [Q/Kdb] Code: An Information Theory Argument

#15

Post by dzaima »

Veedrac wrote: post #13

> Let’s start with an example: (2#x)#1,x#0 is code from the official q phrasebook for constructing an x-by-x identity matrix. Is this... just to be clever? Why not (!x)=/:!x aka. the identity matrix is defined as having ones on the diagonal? Bonus points AI will understand the code better.

Unless the interpreter is capable of pattern-recognizing that whole pattern, that will be less efficient, e.g. having to work with 16-bit integers for x in the range 128..32767, whereas the direct version can construct the array directly (i.e. one byte or bit per element depending on whether kdb has bit booleans). Can't provide timings for kdb for licensing reasons, but here's Dyalog APL and CBQN doing the same thing, showing the fast version at 3.7x and 10.5x faster respectively: https://dzaima.github.io/paste/#0U1bmUlaOVncM8FGP5VIAg0e9cxV...

Re: Don't Force Your LLM to Write Terse [Q/Kdb] Code: An Information Theory Argument

#16

Post by rak1507 »

gabiteodoru wrote: post #4
sanjayjc wrote: post #3

> I think the aesthetic preference for terseness should give way to the preference for LLM accuracy, which may mean more verbose code From what I understand, the terseness of array languages (Q builds on K) serves a practical purpose: all the code is visible at once, without the reader having to scroll or jump around. When reviewing an LLM's output, this is a quality I'd appreciate.

I agree with you, though in the q world people tend to take it to the extreme, like packing a whole function into a single line rather than a single screen. Here's a ticker plant standard script from KX themselves; I personally find this density makes it harder to read, and when reading it I put it into my text editor and split semicolon-separated statements onto different lines: https://github.com/KxSystems/kdb-tick…

There's a difference between one line and short/terse/elegant.

  {m:(x,x)#til x*x; r:til[x]-x div 2; 2(flip r rotate')/m}
generates magic squares of odd size, and the method is much clearer. This isn't even golfed as the variables have been left.

Re: Don't Force Your LLM to Write Terse [Q/Kdb] Code: An Information Theory Argument

#17

Post by quotemstr »

haolez wrote: post #9
benjaminwootton wrote: post #7

The bigger issue is that LLMs haven’t had much training on Q as there’s little publically available code. I recently had to try and hack some together and LLMs couldn’t string simple pieces of code together. It’s a bizarre language.

I don't think that's the biggest problem. I think it's the tokenizer: it probably does a poor job with array languages.

Perhaps for array languages LLMs would do a better job running on a q/APL parse tree (produced using tree-sitter?) with the output compressed into the traditional array-language line noise just before display, outside the agentic workflow.

Re: Don't Force Your LLM to Write Terse [Q/Kdb] Code: An Information Theory Argument

#18

Post by 1718627440 »

dapperdrake wrote: post #10
sanjayjc wrote: post #3

> I think the aesthetic preference for terseness should give way to the preference for LLM accuracy, which may mean more verbose code From what I understand, the terseness of array languages (Q builds on K) serves a practical purpose: all the code is visible at once, without the reader having to scroll or jump around. When reviewing an LLM's output, this is a quality I'd appreciate.

Perl and line noise also share these properties. Don’t particularly want to read straight binary zip files in a hex editor, though. Human language has roughly, say, 36% encoding redundancy on purpose . (Or by Darwinian selection so ruthless we might as well call it "purpose".)

Language is often consciously changed and learned, so it is sometimes quite designed.

Re: Don't Force Your LLM to Write Terse [Q/Kdb] Code: An Information Theory Argument

#19

Post by quotemstr »

krackers wrote: post #6
gabiteodoru wrote: post #4

Earlier quoted context omitted.

I agree with you, though in the q world people tend to take it to the extreme, like packing a whole function into a single line rather than a single screen. Here's a ticker plant standard script from KX themselves; I personally find this density makes it harder to read, and when reading it I put it into my text editor and split semicolon-separated statements onto different lines: https://github.com/KxSystems/kdb-tick…

When Q folks try to write C: https://github.com/kparc/ksimple

Representative example:

  //!malloc
  f(a,y(x+2,WS+=x;c*s=malloc(y);*s++=0;*s++=x;s))     //!
Reminds me a bit of both the IOCCC and 70s Unix C from before anyone knew how to write C in a comprehensible way. But the above is ostensibly production code and the file was last updated six months ago.

Is there some kind of brain surgery you have to undergo when you accept the q license that damages the part of the brain that perceives beauty?

Post reply on HN