<ArneBab>taw10: an article on my site sometimes gets published prematurely when I publish another article <ArneBab>taw10: transpose is the much more mathematical description than my technical apply map <atka>rgherdt: thanks, bookmarked. <avp>sneek: Later tell civodul Yeah, I'm the under-the-cover version of Artyom V. Poptsov ;-) <taw10>ArneBab: the receieve is just to have one procedure for reading the two parts of input (numbers to be called, and list of boards) <taw10>ArneBab: About the transpose: I like the formulation of the win condition this gives, but I was very unhappy with the transpose function itself. Your solution with (lambda (.x)) would never have occurred to me. Works much better! <pinoaffe>hi folks, this may be somewhat of a weird question, but is there an analogue of unfold/unfold-right that can deal with a "multiple values" seed? <ArneBab>taw10: the lambda (. x) is awfully deep magic — I use it because my try to apply didn’t work otherwise; there should still be a much cleaner way <lilyp>pinoaffe: you ought not abuse multiple values as list <lilyp>but you can values->list and then unfold <pinoaffe>lilyp: values->list and unfold is what i've been doing, but abusing multiple values as list would make my code a bunch more pretty :) <lilyp>why can't you return a list though? <lilyp>like all you need to do is to write (list ...) instead of values <pinoaffe>I can return a list, that's what I've been doing, but (ab)using multiple values would mean I wouldn't need to unpack the seed three times for p, f, and g <pinoaffe>I really like how compose deals with multiple values, allowing you to compose a function that takes n arguments after one that returns n values <lilyp>is there really some reason to use unfold here at all? <lilyp>I don't quite get what you're trying to achieve here, perhaps it's a typical X-Y problem <rgherdt>it doesn't use values, but you still don't have to unpack in each function <lilyp>y'all do know that (lambda args ...) exists, right? <rgherdt>I use keyword to distinguish between tail-gen and the rest <lilyp>that does look like some bad recursion thouugh <lilyp>you want to make that tail-recursive <pinoaffe>rgherdt: ah thanks, that looks like it would work <rgherdt>lilyp: thanks, with (tail-gen (lambda args '())) it looks better. Always forget that syntax <chrislck>I did AOC until day3 then my binary tally didn't work, so, I rage quit :) <lilyp>pinoaffe: weird question, but have you tried using iota or something like it? <lilyp>what does change-coordinates-towards do? <pinoaffe>lilyp: change-coordinates-towards does very crude integer-based line interpolation <lilyp>why integer-based? is it used to color individual pixels or something? <pinoaffe>lilyp: similar, it's to calculate which cells of a discrete 2d grid are part of a given line (it also works in higher dimensions) <lilyp>why not use a closed-form solution, though? <lilyp>there's probably some advent-of-code context I'm missing here <pinoaffe>it's (part of) my solution for todays challenge <lilyp>pinoaffe: For now, only consider horizontal and vertical lines: lines where either x1 = x2 or y1 = y2. <lilyp>so you can fix one and use iota on the other axis <lilyp>use match-lambda to detect which case you're in <pinoaffe>lilyp: in part two, diagonal lines where (= (abs (- x1 y1)) (abs (- x2 y2))) are also permitted <lilyp>but even then, if it's always 45 degrees, you can still iota it <lilyp>just extend your match-lambda :) <pinoaffe>I started out writing that (using cond rather than match-lambda, though) but I quickly found it to be somewhat unruly, so I changed my approach <lilyp>lemme code something up real quick <lilyp>pinoaffe: though since you should assign a number to each of the squares, a closed-form solution still ought to be preferred imo <lilyp>rather than manually expanding it <pinoaffe>is (zip . args) equivalent to (map list . args)? I've not seen it before <pinoaffe>I didn't go with a closed-form solution since the size of the grid is not known in advance ***yewscion44 is now known as yewscion
<pinoaffe>so I expand 'm and use a hash table to count how often each coordinate occurs <lilyp>wdym the grid size is unknown? <lilyp>you can just shrink it to the line extents <lilyp>i.e. pick the smallest and largest x and y values from your point cloud <pinoaffe>they did not provide min/max x/y values, and I didn't feel like looping through the input twice <lilyp>I'm pretty sure looping just once isn't enough either, though <lilyp>oh wait, the question is the crossing number right? <lilyp>so you don't have to output the whole grid is what you're saying <pinoaffe>yeah, you just have to count the number of cells that have a crossing number greater than 1 <sailorTheCat>Hi there. I use one guile program (namely guix) and sometimes I get the "Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS". I've tried to create an env vars with that names and a big numbers for a value but either the numbers were wrong or I don't understood something. So, what should I do in that case? ***yewscion is now known as Guest2713
***yewscion_ is now known as yewscion
***kir0ul54 is now known as kir0ul5
<lilyp>sailorTheCat: Perhaps try to set those values for the daemon instead of the CLI. <lilyp>other than that, this is #guile, not #guix even if there's an overlap, there are 3x more users in the other one :) <sailorTheCat>yep, but there is a generic problem about the interpreter <sailorTheCat>also, how can I get good initial values for those variables? <lilyp>I think good ol' powers of 2 ought to do the job, but you don't really want to see that warning in the first place <lilyp>I think it's discussed in the Guix mailing lists somewhere