rank-sensitive find in ngn/k. if it breaks anyone's code, please tell me and i'll revert.

@ngn nono keep it we need more reference links

@Razetime github.com/JohnEarnest/ok/blob/gh-pages/docs/Programming.md and github.com/JohnEarnest/ok/blob/gh-pages/docs/Trees.md may be of general interest. My blog also has a few articles demonstrating/discussing algorithms in (o)K: beyondloom.com/blog/index.html

special-K isn't really a K implementation but it might be entertaining to some

@JohnE special-K is a cereal right

@JohnE I've added a few links to the loom blog

philosophical question: what is the rank of a dictionary?

and another: should rank-sensitive find tolerate non-uniform rank? e.g. find a record in a table with columns of different rank:

t:+`name`age!(("alice";"bob";"charles");23 34 45)
t?`name`age!("bob";34)

@ngn may need to separate the concepts of rank of keys and values?

@chrispsn ok but x?y needs to compute a single rank for the object in order to decide what to do

@ngn whats the K way of finding rank

@Razetime we're trying to define it now

aha

it's just a concept, there's no primitive that returns rank

@JohnE this tree article is really useful. I once came across a cp question which needed a tree structure and it was very annoying to try and implement.

@ngn rank of values

@chrispsn yeah, that's probably the one that makes most sense

i'm also considering rank(dict)=0

is it computing it on demand, or does it already know what the rank is behind the scenes (the former as no prototypes?)

@chrispsn my current implementation computes it every time it's needed and makes sure it's unirank

from an indexing perspective, a dict is a function just like a list, so if lists have rank, dicts have rank

@chrispsn but dicts are less likely to be unirank (e.g. records in a table), so treating them as rank0 could help avoid the restriction

i'm not sure this restriction for unirank is a good thing - it's too expensive to compute and in cases like this it gets in the way

i'm trying to extend ngn's approach to sublists to replace each-left/right, or at least provide a way to generate a table without having to raze the result

odometer lets us generate the desired element indices 'flat' but we still need a self-reference to index back in

the possible {y!x y} primitive lets us avoid the self-reference (at least until we apply except or drop), but it seems to take a lot of memory, and it's messy

any thoughts on how to improve the latter?

@chrispsn what am i supposed to do to the result

@Razetime normally each-right would apply the verb directly, but this approach instead generates the pairs independently of the operation done on them (in this case a multiply) which is instead done by */

heh. @ngn if deep where worked on a keyed table then that could generate the pairs for the prime sieve without using each-right or indexing

@chrispsn what's a keyed table? i forgot

a table that's a dict

:D

ah, i think i get it

something like ngn.bitbucket.io/k/#eJzTOL9V06q6UrFCobKWS1+hoCg/…

^ everything up to the deep where works

ϵ is a bit misleading

sorry, it's a terrible choice of greek, it was just the first one to come to mind

just a placeholder character to get it infix

can't resist the urge to golf :) i!+i!1|=#i:2+!8

Identity matrix - exactly what I was looking for

@ngn I think I found your comparison table a few weeks ago linked from hn or from a repo, amazing resource, I'd keep it up if it isn't too much of a hassle (perhaps link to the wiki or another place if it should go out of date for some reason?)

@tosh yeah, i don't have time and desire to keep it up to date, so i thought it might be better to move it to the wiki

@ngn neat! I'll definitely play around with it

@ngn is "unirank" == "all values in the list have the same rank"?

@coltim yes

list or table or dict

and the issue is what happens if you have a list or dictionary that contains truly variable data...

I mean there always is the "backup" of where-equals or where-match, which you would probably want to use anyways if your list/dict contains duplicates

@coltim yes, for instance this example

@ngn but that's just a table and a row from the table

@coltim but the table is not unirank

a value in the first column is a string (rank1) and in the second column an int (rank0)

the problem can be illustrated with a plain matrix (not table) too:

m:(("alice";23);("bob";34);("charles";45))
m?("bob";34)

hmm, maybe this is the general list vs. rank thing

like intuitively when you have a table and you want to see if a given row is contained within it, you would check each row of the table individually, seeing if the whole of that row matches the whole of whatever "row" you are looking up

@coltim you could be looking for multiple rows though, like table?table

@ngn hmm, there I guess it would be something like "search for each y (each as a whole) among the elements/major cells of x"

the q/k4 docs have what appears to be a somewhat recently updated explanation of find here: code.kx.com/q/ref/find

every time i read k4 docs i end up more confused

yeh the terminology keeps changing. "simple list" vs. "mixed list" is new to me

so, it starts with a nice simple description of what i call "flat find", and by the end it contradicts itself by describing "rank-sensitive find"

the difference between a "list of lists" and a "mixed list" hides a lot of nuance I bet

and in the middle there's a section on "type-specific find" in which i don't see anything type-specific

"x?y can’t deal with mixed-rank x" - literally, the previous example (with u:("abcde";10 2 -6;(2 3;`ab))) showed that :)

I think the difference is if y is a "simple list"; any form of nested list (even if the "leaf" lists are "simple") isn't itself simple?

I mean there's some real flowchart logic going on here

@Razetime beyondloom.com/tools/specialk.html

@JohnE woah that is so cool

is there anyplace i can read up on to use this

oht here's a manual

perfect

k.miraheze.org/wiki/K_primitives

would love some help with the table and the pages here

@Razetime good starting point

@Razetime these are adverbs: ' / \ ': /: \:, k has no schizos like apl

maybe merge the columns for k3-k6, as they are not too different?

@ngn updated find. it's now like that: github.com/ktye/i/blob/master/k.t#L76,L83 (type based not rank)

@ktye "abc"?(("bc";"a");"cc") /((1 2;0);2 2) - interesting, seems logical

"abc"@((1 2;0);2 2) is (("bc";"a");"cc"), so it passes my test for being an inverse of @

as discussed yesterday, finding a single item of a nested list, i need to enlist: (...)?,() which returns an enlisted index, which is also compatible with @

@ktye you mean like in this test: ((1;"a");(2;"b"))?,(2;"b") /,1?

yes

@ktye shouldn't ((1;"a");(2;"b"))?(2;"b") /1 work too?

L?L treats y as a vector and loops over each item.

following the same logic, ((1;"a");(2;"b"))@1 is (2;"b")

the lists may have any structure. i don't assume uniformity

started a wiki page on grammar