Solved part 1 similarly. For part 2 I calculated all ocean trench
coordinates t and all possible initial velocities i - so that the target is
reached and not overshot - as well as the list of steps s - up to the
maximum reached with the highest shot from part 1.
Then just test if the parabola coordinates - calculated with verb pc -
intersect with t. J session follows:
rd=: [: ". [: rplc&('-';'_';'=';'=:';',';' [';'..';' ') (}.~ [: >:
i.&':')
rd 'target area: x=20..30, y=-10..-5'
20 30
-: (*<:) -{.y NB. (*)
45
cp=: {@(,&<) NB. Cartesian product
rg=: [ + i.@>:@-~ NB. Range
t=: >, cp&>/ <@({. + [: i. >:@-~/)"1 x,:y NB. Ocean trench coordinates
x=: ({:x) rg~ >. -: <: %: >: 4&* +: {.x NB. x(x+1)/2 has to reach the
trench
i=: >,x cp y=: (rg <:@-) {.y NB. Possible initial velocities
s=: i. +: >: {: y NB. List of steps
pc=: {{ +/\ (- *)`<:"0^:s x, y }} NB. Parabola coordinates
+/ 0&< ([: +/"1 e.&t"2) pc/"1 i NB. (**)
112
On Fri, Jan 7, 2022 at 5:21 PM Raul Miller <rauldmil...@gmail.com> wrote:
> I should add: this messy code reveals an approach which I use a lot:
>
> Concise, elegant J is for problems which I have a good or at least ok
> understanding of. (The distinction here, between a good understanding
> and an ok understanding, is perhaps best illustrated by the quip "If
> you can't explain it to a six year old, you don't understand it
> yourself.")
>
> But when I do not have something working, then "whatever works" is a
> rough approximation of where I need to start, and baby steps are often
> appropriate.
>
> Here, I would normally have gone back and spent some more time on it,
> built up my understanding of the concepts and cleaned up the code.
> But... I'm still behind on day 24. (Among other things...)
>
> So, instead, I am hoping to use this as an opportunity to engage
> someone else in this puzzle.
>
> FYI,
>
> --
> Raul
>
> On Thu, Jan 6, 2022 at 9:33 PM Raul Miller <rauldmil...@gmail.com> wrote:
> >
> > https://adventofcode.com/2021/day/17
> >
> > Day 17's puzzle was a change of pace from previous puzzles. Instead of
> > a multiline chunk of text representing the puzzle, we got a single
> > line, which looked like this:
> >
> > target area: x=20..30, y=-10..-5
> >
> > All that would vary would be the numbers.
> >
> > The puzzle itself was about a quasi-physics simulation process, with
> > integer positions, velocities and accelerations.
> >
> > The target area represents a rectangular region on a two dimensional
> > map. We get to "launch a probe" with some initial x velocity and y
> > velocity. It starts at time=0 at location x=0, y=0.
> >
> > Additionally, after each step, x velocity is reduced by 1 in magnitude
> > until it reaches 0. And, after each step, y velocity is reduced by 1
> > and will can reach arbitrary negative values.
> >
> > Additionally, since this is an integer based simulation, our probe
> > would fall or fly right past the target area if probe's velocity is
> > sufficient to cross that target area, in one step. For the probe to
> > hit the target area, it has to be in the target area at the end of one
> > of it's steps.
> >
> > For part A, we were asked: how high can our probe go while still
> > landing in the target area.
> >
> > The key here, for our puzzle input (which had a negative value range
> > for y where ymax-ymin was significantly smaller in magnitude than
> > ymin) was to realize that "maximum height" corresponded to a velocity
> > moved the probe from position 0 (which is where it would fall to after
> > being launched upwards) to the bottom of our puzzle input.
> >
> > Our launch velocity would be 1 unit less than that (since each step
> > increases the proble's negative velocity by 1).
> >
> > In other words, given trian=: -:@* >: for our puzzle input the height
> > for part A would be trian >./|targetY
> >
> > My implementation for part B was nothing nearly as elegant. My problem
> > was visualizing the possibilities. Also, I did not document my
> > thinking adequately, and I mostly used a trial and error approach to
> > quickly simulate the possibilities. And, I included a simplification
> > (that Y would be significantly negative) which means that my part B
> > implementation does not work on the sample data (which would be
> > sample=: 20 30,.10 _5 ).
> >
> > Anyways... here's what I had for part B
> >
> > simy=: {{
> > Y0=. {:<./m
> > Y1=. {:>./m
> > Y=.0
> > k=.0
> > y=.-1+y
> > while. Y >: Y0 do.
> > Y=.Y+y
> > if. (Y>:Y0) * Y <: Y1 do. 1 return. end.
> > y=.y-1
> > end.
> > 0
> > }}
> >
> > simX=: {{
> > k=.0
> > X=.0
> > r=.i.0
> > X0=: {.<./m
> > X1=: {.>./m
> > while.(X <: X1)*y>0 do.
> > k=.k+1
> > X=. X+y
> > if. (X>:X0)*X<:X1 do.
> > r=.r,k
> > end.
> > y=.y-*y
> > end.
> > critical=: I. (X0&<: * X1&>:) trian i.X0
> > if. y=0 do. ~.r,(*#r)#(#~ k&<:) critical return. end.
> > r
> > }}
> >
> > b17=:{{
> > N=. 0
> > 'X0 Yp0'=. <./|y
> > 'X1 Yp1'=. >./|y
> > Ypos=. I.y simy"0 i.1+Yp1
> > Xref=: y simX"0 i.{.1+>./|y
> > V=: i.0
> > for_s. i.>./critical do.
> > V=:V,<I.Xref+./ .= s
> > end.
> > Yneg=. 1+Ypos
> > N=. N+(#Ypos)*#critical
> > for_Y. -Yneg do.
> > py=. +/\(|Y)+i.20
> > steps=. 1+I.(Yp0 <: py)*Yp1>:py
> > if. (>./critical) > <./steps do.
> > Vs=. i.0
> > for_s.steps do.
> > Vs=.~.Vs,(s {::V)-.0
> > end.
> > N=. N+#Vs NB. r=.r,>{Y;Vs
> > else.
> > N=.N+#critical
> > end.
> > end.
> > N
> > }}
> >
> > That's not a very good approach, though it did work for me...
> >
> > If someone has an elegant solution to part B, that would be great to see.
> >
> > Thanks,
> >
> > --
> > Raul
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
