i'm going through a few AoC 2017 problems

if you know of any k/apl solutions posted, would be keen to compare

@chrispsn q solutions? github.com/mkst/aoc

@ngn ah that works - thanks!

#3 was a beast relative to how early it appears

this one

@ngn did you learn anything from yesterdays performance analysis?

@ktye yeah, that i need to rewrite "each" :)

empty arrays are so annoying

@ngn that means the main interpreter loop is not a bottleneck?

@ktye there are opportunities for improvement in many areas

"bottleneck" is a misleading analogy with fluid dynamics. software slowness doesn't have to have a single cause.

@ngn about the stack limit when parsing data-lists: maybe constant folding could help here. if we detect that a list contains only data (no code) it could be built before entering execution.

@ktye i don't see that limit as a problem. it's not reasonable to have such long list literals in your code.

but array literals are ok? where is the difference?

@ktye i don't think any k expression that is longer than a certain limit is ok

data should be stored in a separate file, ideally in binary format, not in the source code

small pieces of data like tests for code golf are fine

i'm obviously not a golfer.

@ktye why do you need this?

@ngn let's say i have a table of numbers from a different source. i can quickly edit it with an editor to k syntax and append a small program. just load the file and get the result. You propose to edit two files, where the second loads the first with special parsing code. that seems to be more complicated. separate data from code, is ok for large things, but quick calculations? if lisp can do that, k should too.

#!./k
`j?*|"\n/\n"\1:`argv 1
/
["lots of",
 "data",
 "blah blah"]

@ktye how about ^ ?

yes, that's a workaround to a limitation. k should be able to eat it's own dogfood. k9 can parse (0;..;127) no more. excel had row limits of 16k, now more.

k is "big data, small programs"

and k is simple. no boilerplate.

@ngn if your input data must be in a different type from the code representing it, is that not as bad as non-roundtripping output? :)

@dzaima i don't have a problem with that. input is unlikely to be formatted as k. more likely to be json or fix or csv.. ideally binary.

@ktye it dies on arrays too long too. There's some const-folding optimization before the JIT, but it never gets to JIT if it can't evaluate in the regular interpreter

@ngn (of course by "input" i mean data input to an application written in k. k's stdin is in k, naturally)

@dzaima oh

welcome to the segf club :)

hm, my stack overflow detection was behind #ifdef DEBUG, but even without that it still segfaults..

@ngn another argument you could be open to is roundtripping. you make lots of effort to format floats. you put braces around lists, for k to be able to consume it's output. but just that it can't. k can parse json but not k.

@dzaima ah, my max stack size variable went though a u16 argument, thus losing significant bits

short on its own (not as array) is useless

@ktye dziama made the same argument. ok maybe.. but there are so many more important things to do.

i still have quite a few fields as u16s (local variable count, closure depth, call counter to know when to JIT) but max stack size was a u32. But a wrongly typed function still implicitly truncated it

@ngn i'd rather first implement prototypes, speed up "each", iron out most differences with oK, add more examples, enable ffi, implement \d so programming in the large is less annoying, make a more advanced iKe-like thing..

@dzaima (but they're even not organized, so won't be packed & reduce struct size anyway.. :|)

@ktye it changes the path of the current k namespace, so all new variables and functions will be automatically prefixed with it

convenient for writing modules without risk of name collisions

@chrispsn github.com/xpqz/AoCDyalog 2015-20 in Dyalog. Be warned: when I started I wasn't very good at APL, so the first years are rather sucky

I'd be intereted to see a Dijkstra or A* impelentation in k

there is one in J: rosettacode.org/wiki/Dijkstra%27s_algorithm#J

i dislike translating, J, will try it myself sometime

I have a few APL versions, but they always end up horrid and scalar

example of a nice non-eachy filter: (=':)#x

fun solution for part 2 day 1 aoc 2017: 2*+/*/=\2 0N#t

@rak1507 I have an enormous non-eachy filter in q3 p2

I didn't bother doing that, q3 p1 was painful enough (unless there's a clever method)

this was my p3 (no feedback yet pls, haven't had time to sit down and optimise)

input:312051
f:{x# :/{x>#::/y}[x]{(2+x;y,(1 0;0 1;-1 0;0 -1)@&1 1 2 2+x)}//(0;,0 0)}@

p1:+/{x|-x}@+/f@
p1 input

coords:+\f@100
*(input<)#.((,0 0)!1){x,(,y)!+/x(2<+/+{x*x}y-/:)_!x}/1_coords

f:{(a;b;c;d):(0,+\0 1 1+#x)_y; (c,'(,|b),x,'|a),,d}
g:f/{y_!x}':a*a:1+2*!300
+/|/-:\-/+&~^1 265149?g

my p1, horrible and not optimised

@xpqz thanks!