This was the first Advent of Code problem that I tried. It seemed very easy. Indeed, as you suggested, parsing the text input is harder than doing the calculations.

Dedicated integer solution techniques are not needed. It can be done in each case by finding the rational-number solution of a pair of linear equations and discarding any non-integer solutions. Some extra work might be required if there were cases of multiple solutions, but that didn't occur. My CPU time for all 640 problems (both parsing and computation) was less than 1/2 second.

Download AoC_2024_Dec_13.mw

@Carl Love Nevermind, I've confirmed that the essential difference is the use of "C", "P", and "T" rather than C, P, and T.

@Samir Khan Could you please explain how your CP, which works, is different from the OP's CP(T1(t)), which doesn't work? Is it simply the quotation marks on the C, P, and T that are the crucial difference?

@nm Yes, the only reason that I did it with sprintf instead of concatenation was to get the leading zero(s) in a programmatically general way. The reason to use leading zeros is so that a standard string sort of the filenames will come out in numeric order.

Also, sprintf is a standard command in many languages, and it's much older than Maple.

@dharr I'd like to see your syntax error. This works perfectly for me:

restart;
P:= proc(x) sin(x) end proc:
P2:= subs(sin= evalhf@sin, subsop(3= (op(3,eval(P)), hfloat), eval(P)));
P2(3);

@mehdi jafari Sorry, I don't know how to use these commands or if they work in the current version of Maple, and I don't have the time right now to figure it out. Note that I wrote the above Answer over 6 years ago, and even at that time I suspected that those commands weren't up to date.

Is the SaveAll given by @stefanv above sufficient for your needs?

@dharr Yes, you are correct if we are using the standard definition of cycle, and I was sloppy not to think of that. However, for the purpose of checking transitivity, it is sufficient to consider any walk that returns to its starting vertex to be a "generalized cycle".

Since we need to forbid edges that are the reverse of each other, we could check that A *~ A^+ = 0 as a first step.

Thank you for this Post. I will start looking at these puzzles.

As you noted, checking the transitivity of the rules while ignoring the subsets of the rules that are actually used for the needed sorts is a red herring. However, if one did need to check the acyclicity of a digraph on n vertices, a computationally efficient way to do it (just off the top of my head) is to add the first n powers of its adjacency matrix. Calling this sum T, the graph is acyclic iff trace(T) = 0, and any nonzero on the diagonal corresponds to a vertex that is part of a cycle. (For an adjacency matrix A, (A^k)[i,j] is the number of walks of length k from i to j. A cycle containing i is a walk from i to i.) I suspect that this is more computationally efficient (again, just off the top of my head) because it doesn't keep track of what the actual cycles are, only which vertices are part of any cycle.

By the way, why is this the Advent of Code 2025 rather than 2024?

Like most food, pizza has a substantial quantity of water, even after it's baked. If it didn't, it would be extremely crunchy, more so than a cracker. The boiling temperature of water is 212 degrees F (at standard atmospheric pressure). Just because it comes out of a 350-degree oven doesn't mean that its temperature is 350 degrees: Its temperature never equilibrated in the oven. (This also means that the surface temperature is more than the maximum internal temperature, so Newton's Law can't be easily applied.) The standard food-safety recommendation in the USA is to cook things until they reach an internal temperature of 165 degrees.  

@Preben Alsholm Ah, thanks Preben. So the reason that I've never seen this is that I don't use 2D Input.

@C_R I use Maple 2023, but I've never seen this problem.

@mmcdara The syntax for local declarations has been updated in recent versions, and they no longer are required to be before any statements of a procedure. So, there's no syntax error in the OP's original. However, I do consider your modification to be a stylistic improvement because there's no need for the variable difference.

@Kitonum Yes, I was simultaneously computing that (using discrim), and it's now posted.

The maximum range of m can be determined thus:

eqBJ := y = m*(x - xJ) + yJ; 
eq1 := x^2 + y^2 - r^2;
solve(discrim(eval(eq1, eqBJ), x), m);

For your particular values of xJ, yJ, and r, that's

eval([%], [xJ,yJ,r]=~ [5,1,3]);
             [(5-sqrt(153))/16, (5+sqrt(153))/16] 

That's approximately m = -0.46 .. 1.08. Using this range in the animate command produces good results.

@dharr When using forget, it is often difficult to figure out exactly which procedures need to be forgotten; sometimes I find it impossible. Two things that should help in this example:

1. Int is just an inert unassigned name, not a command or procedure. Thus it can't have a remember table. It's a shame that forget(Int) doesn't return an error.

2. Although evalf is builtin, you can still extract its remember table via op(4, eval(evalf)). If you do this after a numeric integration, you will see the corresponding entry. This is likely one of those remembered results that is removed by garbage collection; if so, you'd need to extract it before it gets collected.