@coltim heh.. already golfing with the new filter? :) you can drop the t: there

@ngn cool, will need to edit this in

@coltim i changed key_dict to dict_key and updated the only breaking answer

@ngn i’ll play around with it more but i think it may be more nuanced than my original examples. like x_dict is still "remove keys in x from dict", except when x is a single integer, when it’s "drop first x items". dict_x removes the item with key x, provided x is an atom (thereby handling the gap in x_dict). I don’t think dict_list is generally supported

hmm

so going back to this discussion

the win of the actual algo over the simple one is small lists?

@chrispsn yeah, i optimized grade only for large lists (radixsort instead of mergesort or something else)

@chrispsn typo in "supercalifragilisticexpialidocious" :)

@ngn speaking of performance.. have you taken a look at this find slowdown? k7 vs ngn/k

@Traws there are many factors that contribute to the slowness there

find is linear search

tio runs j on a good 64-bit machine hosted somewhere in the cloud, the ngn/k web demo runs 32-bit wasm in your browser

also, my scans are not optimized

@ngn I see.. yeah I was thinking it must have been multiple factors to get this kind of difference

@ngn I compared with k7 32-bit wasm too btw

@Traws i'll have a better look later, there might be easy ways to optimize the new find impl

@Traws hm, actually my find seems to be well-optimised.. i suspect j has a special case for "small-domain" find (i know roger loves this kind of optimisation)

or: {&0^&/@[&1+|/x;x;:;1](x+\:x;x-\:x)}@+\1+3*!2500

tbh, i'm a bit surprised k7 (probably) uses this optimization too. in general k relies much less on special-casing, but maybe in this case it was worth it.

both j and k7 have the advantage of not having to deal with 0N-s which take up 64 bits

now i wonder if i too should optimise small-domain find

@ktye have you done that?

@ngn does it have to inspect everything to determine if it’s dealing with variable rank values?

@coltim it just assumes uniform rank for now