the k tree

ngn

12:40

@coltim
non-eaching f# affects some of our golfs (coltim: [0](https://codegolf.stackexchange.com/questions/229375/decode-usb-packets/229440#229440) [1](https://codegolf.stackexchange.com/questions/142555/exponentiation-sequence/214133#214133) [2](https://codegolf.stackexchange.com/questions/71172/find-the-largest-and-the-smallest-number-in-an-array/216975#216975) [3](https://codegolf.stackexchange.com/questions/216113/for-what-block-sizes-is-this-checksum-valid/216122#216122) [4](https://codegolf.stackexchange.com/questions/217328/help-stack-exchange-transpose-tables/217343#217343) [5](http…

coltim

@ngn happy to update them - same pull request process?

ngn

second try to deal with markdown:

coltim: 0 1 2 3

4 5 6 7

ngn: 0 1 2 3

@coltim i think most of the work would be in updating the explanations. collecting the new solutions is easy - i can do it manually.

coltim

@ngn gotcha, no issues there

ngn

@coltim i haven't ~~committed~~ pushed the change yet

@JohnE i don't think having two slightly different versions of filter (or any other primitive) would be good for the language long-term. are you worried about existing oK programs? or about compatibility with the original k6?

chrispsn

@ngn call it replicate instead?

ngn

12:53

@chrispsn possible

@chrispsn apl has a similar thing (though it's more like x@&x, as it has no first-class functions) and it calls it that

chrispsn

@ngn exactly

ngn

other options: "select", "sift", "which", "that"

Razetime

hhow would a non-eaching f# work

ngn

@Razetime like x@&f x

Razetime

lemme try that real quick

chrispsn

12:57

@ngn if it can still repeat like this then the name should reflect that

ngn

@chrispsn good point

@chrispsn in apl it is called by (at least) two names, depending on how you use it: replicate or compress

chrispsn

'repeat' might also capture the 'cycle' nature of overtake

even just 'copy'

or 'clone'

ngn

@chrispsn i think calling n# "take" is wrong

(though it may be just because of my apl background)

coltim

13:16

@ngn assuming nice simple/flat vectors doesn't "take" go all the way back?

(terminology-wise)

chrispsn

'have' as in "i'll have 7 of a, 3 of c' and also captures presence/absence

ngn

@coltim in apl the difference between "take" and "reshape" is that overtake fills with the prototype and overreshape cycles

@chrispsn maybe we should organize a poll

Traws

for naming I like "copy" (same as J), "select" or maybe "pick"

ngn

@Traws ah, i was thinking of "pick" too but forgot to mention it (it also clashes with apl but so what)

chrispsn

which meanings of dyadic # is the word intended to capture? all of them?

ngn

13:26

@chrispsn i was thinking only of "filter"

whether "reshape" is a good word or not is a separate question..

chrispsn

I think 'take' captures the vibe (similar to 'pick' or 'have')... 'copy' implies presence

coltim

I think the term doesn't have to cover all the use cases so long as it's thematically on point, e.g. "where" implies booleans, even though it does the replicate thing under the hood

JohnE

15:13

@ngn both

user

Hi, I was trying to solve this challenge in K, and tried doing f:{a:x;$[x;*/o[x-1]'1+!y;y]} (so f[x;y] would be y!x), and for some reason, it tells me the maximum call stack size is exceeded with o[x-1] but not with {f[a-1;x]}. Can anyone help me out with why that happens?

Smaller example: f:{a:x;$[x;{f[a-1;x]}'!y;y]}

dzaima

works in ngn/k fwiw

user

Interesting

I've got a shorter solution now, but I feel like this one should work too. Is currying not guaranteed?

ngn

15:38

@user where is the currying in that?

user

When o[x-1] only gives x and waits for y

ngn

ah, in your previous solution. i think that should work.

possibly a bug in oK

user

By the way, do normal integers overflow in ngn/K?

ngn

@user yes, they are 64bit

user

Are there any bigints available?

ngn

15:44

no

user

Oh, I see

ngn

i think most challenges like this are fine with overflows, as long as your algorithm works in theory

btw, you probably want *| instead of -1#

see also the comments under the top answer

user

@ngn Ah, thanks!

coltim

@ngn interesting that the function gets parsed/converted to {[x;y]a:x;$[~x=0;o.,x-1'!y;y]} (the x-1'!y part seems like it'd be different...)

ngn

@JohnE ^

coltim

15:48

better link

dzaima

maybe something about the fact that o can be infix? (also considering that f:+; (f[3;30];f[3];f[3;]) is 33 3 3)

ngn

or maybe it's just the way oK pretty-prints projections

missing parentheses around o.,x-1

@ngn i mean, not projections per se, but the pretty-printed k code that creates a projection

coltim

I think it's that brackets and whatnot are syntax sugar that get de-sugared. I think @razetime ran into a similiar-ish issue a few weeks back

ngn

@coltim that's probably right: {a[b]} prints as {a.,b}

coltim

I think it was this

dzaima

16:03

huh

Razetime

yeah it was a problem with having projections

user

@Razetime What's the 0, for? (I stumbled upon a similar solution (and with ngn's help, almost the same as yours), but I didn't see an edge case that needed 0,) — user 2 mins ago

@Razetime Since you're here ^

Razetime

I just responded lol

user

Oops

Razetime

{*|0,x*\/1+!x}[0] gives 0N instead of 0

user

16:09

Didn't realize you had to handle 0 - the superfactorial one said x >= 1

Razetime

seeing the test cases helps

user

Yeah lol

Thanks for the help, I'll check out the tests next time :P

coltim

@ngn if, hypothetically, I've been compiling several other wonderful "ideas" for modifications to existing behavior, does this message, ensuing discussion, etc. etc. establish a precedent for a process? =P

ngn

@coltim hehe :) i live in a country with a civil law system (not common law, which is precedent-based), so i'll make judgments case by case :P

@coltim but of course, please share ideas so everyone can comment on them

coltim

16:25

wonderful! attempting to exercise some restraint, I've limited them to things present in at least one other K implementation:
https://ngn.bitbucket.io/k/#eJyFVMFuGjEQve9XvNIegkK6y0JCwjZV7pV6zSFCkfEO4OK1LdubsFJ/qr/QL+t4CUmbogQJ8I498968ed48q5WMyhrhO9TeurwmTZEQH0lss+s3PhmgcI+Uj+uvfTJWyofIYU/S+jqMeBFbbxC9ahqq+8MZJzpPgQyfNHNspyPYbyNsZ/y9SrvR7qsJwwcircljS90IbaA5b2OPeY/dMy5v5w9CtwQnlMejipsUwy7LMuGXKvrU3+NGRQpOSOK6CBw0dXizx32bu/lJCUyAKXAOXPQcMAMugSuMC4zHw+NdcVC23nNQd3Mcinxh2iVu+OEG05TIja1ajZX1c0hbE4RWa9NwWs6xRsSozJpbacSWzrRiiZ23P6gf3FH+e9LjqhreldVkkXQaM+Tkf5av4PvWpDWBQcjIbi/lqjU91t+wWXaYjTIrZVRUdEx…

ngn

16:41

huh, i didn't realize all other ks have a different interpretation of i_dict from mine

ok, i'll have to fix that one, it's practically a bug

JohnE

"make list projection" is very subtly strange

oK does have infinities, but it does not have integers

  1 -1%0
0w -0w

ngn

multi-statement blocks ("progn"-s?) - yes, i agree there's a need for that. i didn't implement them before because i wasn't sure if [ ] should be reserved for dict literals.

coltim

@JohnE re: make-list projections being subtly strange - how so?

@JohnE they have unusual properties I guess but I mostly like FP NaNs/infs/etc. integer infinities are definitely just a cosmetic thing though

ngn

16:57

@coltim (1;;) looking like a list but being a dyadic function?

ngn

17:47

@JohnE most existing oK programs are either in your repo (should be easy to go through and fix) or here at codegolf.SE (those use tio, and it's not being updated anymore, so they won't break). as for the original k6, it's been gone for years, so there's little danger of someone approaching our implementations with strong expectations.

ngn

21:34

@coltim i edited your golf answers that were broken due to the non-eaching filter, i hope you don't mind

coltim

23:07

@ngn 1) of course not 2) what a joy it is to be an entitled user (versus the one on the other side) 3) it's not as bad as it may look 4) thanks!

Transcript for