claude.ai can write and explain many facits in the feild of prime number theory. Look what was created.

https://claude.ai/public/artifacts/b5b0697c-01a2-4e42-843b-7ddecc63c568

Testing tesing 123. Testing tesing 123.Testing tesing 123.Testing tesing 123.Testing tesing 123.Testing tesing 123.Testing tesing 123.Testing tesing 123.Testing tesing 123.Testing tesing 123.Testing tesing 123.Testing tesing 123.Testing tesing 123.Testing tesing 123.Testing tesing 123.Testing tesing 123.

The link below goes to the Proceedings of the Maple 2024 Conference, which includes several articles that will be of interest to the readers of Maple Primes.

There may be one more paper coming in to the proceedings later as per policy; since most things are ready, away we go!

Proceedings of the Maple 2024 Conferenc

For a long time, triggered by a disagreement with one of my teachers, I wanted to demonstrate that Euler equations are not absolutely necessary to reproduce gyroscopic effects. Back then, there were no computer tools like Maple or programming languages with powerful libraries like Python. Propper calculations by hand (combining Newton’s equations and vector calculus) would have required days without guarantee of immediate success. Overall, costs and risks were too high to go into an academic argument with someone in charge of grading students.

Some years ago, I remembered the unfinished discussion with my teacher and simulated with MapleSim the simple gyroscope with two point masses that I had in mind at the time. It took only 10 minutes to demonstrate that I was right. At least I thought so. As I discovered recently when investigating the intermediate axis theorem, MapleSim derives behind the scenes Euler equations. This devalued the demonstration.

This post is about a second and successful attempt of a demonstration with Maple employing Lagrangian mechanics.  A rotating system of three point masses connected by rigid struts is used. The animation below from the attached Maple worksheet exactly reproduces a simulation of an equivalent T-shaped structure of three identical masses presented here.

Lagrangian Mechanics

The worksheet uses Lagrangian mechanics to derive equations of motion. Only translational energy terms are used in the Lagrangian to prevent Euler equations from being derived. To account for the bound motion of the three point masses, geometric constraints with Lagrange multipliers were added to the Lagrangian L of the system. This lead to a modified Lagrangian L’ that can be used with dedicated Maple commands to derive with little effort a set of Lagrange’s equations of the first kind and the corresponding constraints

(source https://en.wikipedia.org/wiki/Lagrangian_mechanics)

For the system of three point masses the above equations lead to 9 coupled second-order ordinary differential equations (ODEs) and 3 algebraic constraints 

(Maple output from the command Physics,LagrangeEquations)

where x_i, y_i and z_i are the components of the position vectors _i of the masses 1 to 3 and the l_i,j are the constraints between the masses i and j, and b and h are the base and the height of the triangle.

The 12 equations together are also referred to as differential algebraic equations (DAEs). Maple has dedicated solvers for such systems which make implementation easy. The most difficult part is setting the initial conditions for all point masses. In this respect MapleSim is even easier to use since not all initial conditions have to be exactly defined by the user. MapleSim also detects constraints that allow for a simplification of the problem by reducing the number of variables to solve. This leads automatically to 3 instead of 12 equations to be solved. Computational effort is reduced in this way significantly.

Newtonian Mechanics

One could argue now that the above is a demonstration with Lagrangian mechanics and not with Newtonian mechanics. To treat the system in a Newtonian way, the masses must be isolated and internal forces acting on each mass via the struts are applied to each mass and effectively become external forces. This leads to 9 ODEs with 27 unknows

Following actio=reactio for each of the (massless) struts reduces the number of unknows to 18

To solve for the 18 unknows, 9 more relations are required. 3 algebraic constraints that keep the distance between the masses constant have already been listed in the previous section. 6 further algebraic constraints can be established from the fact that the force vectors point towards the opposing mass (see also below).
The effort to solve this system of equations will be even greater but with the benefit of having information about the internal forces in the system. Before making this effort, it is advisable to take a closer look at the equations of motion derived so far.

Forces and the "mysterious" Lagrange Multipliers

Rearranging equations of motion from Lagrangian mechanics to

and comparing this to the equations of motion from Newtonian mechanics yields in vector notation 

or more general for the forces

where the _i are the position vectors of the individual masses and the  are the constraint forces between them.  

In the case of a triangle formed by struts all internal forces must act in the direction of the edges of the triangle. If they would not act this way, opposing pairs of  and   would create a torque around the struts which would lead to an infinite angular acceleration of the massless struts. The above equation confirms this reasoning: The internal forces act in the direction of the difference vectors between the position vectors of the masses (which describe the edges) and scale with l_ij.

The beauty of the Lagrange multipliers in this case is that they hit 3 birds (three components of the vectors ) with one stone. This reduces the number of unknowns.

However, the Lagrange multipliers are somehow mysterious because they do not represent a physical quantity, but they can be used to calculate meaningful and correct physical results.

What makes them even more mysterious is the fact that positions constraints can be expressed in different ways. In the above example the square of the distance between the masses is kept constant instead of the distance. There are many more possibilities to formulate the constraint of constant distance and each of them results in different multipliers l_ij with different units. In principle they should all work equivalently but might not all be usable with dedicated solvers.

According to the above equation, the internal forces in a strut scale with the Lagrange multipliers and the length of the strut. During the back and forth flip of the triangle in the above animation the forces vary which can be appreciated from the l_ij in the following plot. 

Some observations:

• At the start, only the strut between the red and the green masses is tensed by centrifugal forces. This would have been intuitively expected.
• At the start, the broken symmetry in the initial conditions is already visible by the imbalance of the forces in the two other struts.
• At no time two forces are zero
• There is never compression in two struts at the same time. The existence of compression forces renders any attempt to replace the struts by cables useless
• Plotted together in 3D the Lagrange multipliers describe a seemingly perfect circle.

The last observation in particular shows that both the Lagrange multipliers and the IAT still hold some secrets that need to be clarified:

• Is it an exact circle? How to prove that?
• Does a circle appear for all initial conditions and geometries (obtuse isosceles triangles) when the intermediate axis theorem manifests?
• What does the circle represent? Is it a kind of an invariant between the Lagrange multipliers that allows the calculation of one force when the two others are known?
• Is there an analytical representation of the circle as a function of the geometry and the initial conditions?
• What determines the center, the radius and the orientation of the circle?

Conclusion

Overall, the approach of adding non-physical terms that are zero to a physical quantity (the difference between kinetic and potential energy) to derive something meaningful is not obvious at all and underlines the genius of Lagrange. For a system of three bound masses it could be used to calculate internal forces as opposed to the more common use of calculating external constraint forces. Beyond the lack of fully satisfying intuitive explanations, the IAT still offers unanswered scientific questions.

PS.: 

• The exercise was a nice cross-check of MapleSim and Maple.
• dsolve and odeplot are awsome

IAT_without_Euler_equations.mw

L. B. Johnson once said: “I may not know much, but I know chicken sh#t from chicken salad.” And the same goes for mathematical software,  Maple is a good chicken salad.

These two numbers can be used to factor two previously factored RSA Challenge numbers:

4492372899485266683229032112393311539091890452003150017722229708882931615085372733373343061967162688807713966063216561545461119244883848142568154156987418243095913219694108294875951005535802313105656690937568115044857082104972025

252470349467980886727391223577367145704558455488893488785280129051457755334632136343591527439288590916228345021218177497619016135424030834870037054353008183582467637830682000623550252325843511739294850378626625818394419012275747807

I'm curious to see if anyone can identify the numbers and do the factorization. If no one has been able to solve this, I will post the solution context at a future date. There exists some very interesting mathematics behind this question that goes beyond a simple recreational diversion.
 

As a university-level math student, I am constantly working through practice problems. An issue I constantly face is that when I get a problem wrong, it can be challenging to find out which line I did wrong. Even if I use Maple Calculator or Maple Learn to get the full steps for a solution, it can be tedious to compare my answer to the steps to see where I went wrong.

This is why Check My Work is one of the most popular features in Maple Learn. Check My Work will check all the lines in your solution and give you feedback showing you exactly where you went wrong. I honestly didn’t know that something like this existed until I started here at Maplesoft, and it is now easy to see why this has been one of our most successful features in Maple Learn.

Students have been loving it, but the only real complaint is that it’s only available in Maple Learn. So, if you were working on paper, you'd either have to retype your work into Maple Learn or take a picture of your steps using Maple Calculator and then access it in Maple Learn. Something I immediately thought was, if I’m already on my phone to take a picture, I’d much rather be able to stay on my phone.

And now you can! Check My Work is now fully available within Maple Calculator!

To use Check My Work, all you need to do is take a picture of your solution to a math problem.

Check My Work will recognize poor handwriting, so there is no need to worry about getting it perfect. After taking the picture, select the Check My Work dropdown in the results screen to see if your solution is correct or where you made a mistake.

Check My Work will go through your solution line-by-line giving you valuable feedback along the way! Additionally, if you make a mistake, Maple Calculator will point out the line with the error and then proceed with checking the remainder of the solution given this context.  

For students, Check My Work is the perfect tool to help you understand and master concepts from class. As a student myself, I’ll for sure be using this feature in my future courses to double-check my work.

What makes Check My Work great for learning a technique is that it doesn’t tell you what mistake you made, but rather where the mistake has been made. This is helpful since as a student you don’t have to worry about the time-consuming task of finding the step with an error, but rather you can focus on the learning aspect of actually figuring out what you did wrong.

Once you have made corrections to your work on paper, take a new picture and repeat the process. You can also make changes to your solution in-app by clicking the “Check my work in editor” button in the bottom right, which runs Check My Work in the editor where you can modify your solution.

No other math tool has a Check My Work feature, and we are very proud to bring this very useful tool to students. By bringing it fully into Maple Calculator, we continue working towards our goal of helping students learn and understand math.

View the GIF below for a brief demonstration of how to use Check My Work!

We hope you enjoy Check My Work in Maple Calculator and let us know what you think!

I teach math at the high school level.

I am worried that Maple 2025 appears to be slower than Maple 2024 - in particular for students with older, less strong laptops.

Maple 2025 takes 50% longer to start than Maple 2024 (or Maple 2025 Screen Reader which I expect to be using).

So, on more sluggist student laptops I fear the slowness overall will be an issue - in particular as Maple regularly has to be shutdown and restarted for some of those students.

Further, I really miss the "recompute section !" and the "magniffy" icons on the quest access bar. Having "recompute entire worksheet !!!" seems unwise though. I wish you could costumize the quest access bar.

Overall, from a teaching point of view, I am not at all impressed, sadly.

The Maplesoft Physics Updates, introduced over a decade ago, brought with them an innovative concept: to deliver fixes and new developments continuously, as soon as they enter the development version of the Maple library for the next release. A key aspect of this initiative was prioritizing the resolution of issues reported on MaplePrimes, ensuring that fixes became available to everyone within 24 to 48 hours. Initially focused solely on the Physics package, the scope of the updates quickly expanded to include other parts of the Maple library and the Typesetting system.

This initiative, which I developed outside regular work hours, aimed to enhance the Maple experience—where issues encountered in daily use could be resolved almost immediately, minimizing disruptions and benefiting the entire user community through shared updates.

As of January 1st, I have stepped away from my role at Maplesoft and have been increasingly involved in activities unrelated to Maple. This raises the question of what will happen with the Physics Updates for Maple 2025 and after.

The Physics project remains a unique and personally meaningful endeavor for me. So, for now, I will continue to dedicate some time to these Updates—but only for the Physics package, not for other parts of the library. As before, these fixes and developments will be included in the Physics Updates only after they have been integrated into the development version of Maple’s official library for the next release. In that sense, they will continue to be Maplesoft updates.

On that note, the first release of the Physics Updates for Maple 2025—focused solely on the Physics package—went out today as version 1854. To install it, the first time open Maple 2025 and use the Maplecloud toolbar -> Packages, or else input PackageTools:-Install(5137472255164416). Any next time, just enter Physics:-Version(latest)

As for fixes beyond the Physics package, I understand that Maplesoft is exploring the possibility of offering something similar to what was previously delivered through the Maplesoft Physics Updates.

All the best

PS: to install the last version of the Maplesoft Physics Updates for Maple 2024, open Maple and input Physics:-Version(1852), not 1853.
 
Edgardo S. Cheb-Terrab
Physics, Differential Equations, and Mathematical Functions
Maplesoft Emmeritus
Research and Education—passionate about all that.

Hello everyone,

I have created a Maple worksheet titled "ΕΜΒΑΔΟΝ ΕΠΙΠΕΔΟΥ ΧΩΡΙΟΥ", designed to help my students prepare for their final exams as they qualify for university. This worksheet focuses on area calculations in plane geometry, using Maple to visualize and solve problems efficiently.

This worksheet is aimed at high school students preparing for university entrance exams, as well as teachers who want to integrate Maple into their teaching.

I would love to hear your thoughts and feedback!

Have you used Maple for similar exam preparation?
εμβαδόν_χωρίου.mw

After a long chat with ChatGPT I finally received a fully working code for a proc for a generalized Woodbury Identity for the inversion of the sum of two or more positive definite matrices.
I was inspired by a family member who is a trained professional programmer, who told me that in his professional work he uses ChatGTP for an initial draft of his program.  
I did find out that ChatGTP makes errors: from simple ones like writing 'Simplify' instead of 'simplify' to serious conceptual errors, for example in recursive loops. However, ChatGTP seems to 'understand' the error after given specific feedback. Although, this does not mean that the next proposal does not contain the same logical error. But after a long chat I received a nice proc that seems to work. 
My second surprise was that Gemini suggested a formula for the generalized Woodbury lemma that was unknown to me, and I was unable to find on Scholar Google or https://math.stackexchange.com. Based on a special case of that formula, I was able to write the second proc myself. 
In conclusion, to start working it can be helpful to collaborate with AI friend, a little patience may help, AI may not be astute as someone on Mapleprimes wrote, but neither am I. I am now retired, and it is fun to play with Maple and AI. 
By the way, the search term Woodbury did not give a single hit on Mapleprimes.With_a_little_help_from_my_friends.mw
kind regards,Harry 

 

Maple Transactions Volume 4 Issue 4 has now been published.

This issue has two Featured Contributions by people who have been plenary speakers at Maple Conferences in the past, namely Veselin Jungić and Juana Sendra. We hope you enjoy both articles.  There is an accompanying video by Professor Sendra, which we will add a link to when it becomes ready.

As usual, there is an article in the Editor's Corner, but this one is a bit different.  In this one, Michelle Hatzell (the new copyeditor for Maple Transactions, who is also a Masters' student working with me at Western) and I have written about a fun use of Maple's colour contour plots to make an image that might be used as the cover of an upcoming book, namely Perturbation Methods using backward error, which I'm just finishing now with Nic Fillion and which SIAM will publish next year.  So, while there's some math in that paper, it's more about Maple's utilities for colour plotting; so you might find it useful.  We also hope you like at least some of the images.  Some are more attractive than others!

We have several Refereed Contributions, not all of which are ready at this time of publication but which will be added as they are revised and sent in.  We have a nice paper on using continued fractions in a high school context, another on code generation, and another on using Digital Signal Processing in Engineering courses.

Finally we have a first publication in French, by Jalale Soussi.  Actually we have the paper also in English: we chose to publish both, in our Communications section, each with links to the other.  It is possible to publish in Maple Transactions solely in French, of course, but the author provided both, so why not?

Happy reading, and best wishes for 2025. 

Download dynamics_of_novel_disease_outbreak.mw

I am very happy to announce the first public release of a project which I have been working on for the last couple of years.

NODEMaple consists of a set of Maple workbooks and a library for structural design based on the Eurocode.

Currently the main development of the workbooks is focused on "Eurocode 5: Design of timber structures" with the Norwegian Annex.

This software has been made public in the hope of that it might be useful for other structural designers, professionals as well as students. Everyone interested is very Welcome to contribute to this project. The code is published under the GPLv3 license.

For more information see https://github.com/Anthrazit68/NODEMaple.

I didn't put it in the title, but of course this is a post about Advent of Code, in particular Days 16 and 18 which feature a perenial favorite type of problem: finding shortest paths in mazes.

Your input for these is always a maze given as an ascii map.  Like so:

###############
#.......#....E#
#.#.###.#.###.#
#.....#.#...#.#
#.###.#####.#.#
#.#....#....#.#
#.#.#####.###.#
#...........#.#
###.#.#####.#.#
#...#.....#.#.#
#.#.#.###.#.#.#
#.....#...#.#.#
#.###.#.#.#.#.#
#S......#.#...#
###############

There's lots of ways to import one of these into Maple and then solve the maze, but I am to highlight how to do it with GraphTheory.  I am going to start with a GridGraph and then remove the walls in order to leave a just the vertices that represent the paths:

with(StringTools): with(GraphTheory):
maze:=
"###############
#.......#....E#
#.#.###.#.###.#
#.....#.#...#.#
#.###.#####.#.#
#.#....#....#.#
#.#.#####.###.#
#...........#.#
###.#.#####.#.#
#...#.....#.#.#
#.#.#.###.#.#.#
#.....#...#.#.#
#.###.#.#.#.#.#
#S......#.#...#
###############
":
mazelines := (Split(Trim(maze), "\n")):
sgrid := ListTools:-Reverse((map(Explode, mazelines)) ):
m,n := nops(sgrid), nops(sgrid[1]);
tgrid := table([seq(seq([i,j]=sgrid[i,j],i=1..m),j=1..n)]):
start := lhs(select(e->rhs(e)="S", [entries(tgrid,'pairs')])[]);
finish := lhs(select(e->rhs(e)="E", [entries(tgrid,'pairs')])[]);

Now the maze is stored in the table tgrid, and it is easy to find the walls and paths.  In a GridGraph the vertices are labeled with their coordinates as "x,y" and so we rewrite our list of paths in that form, so we can create the induced subgraph of the Grid that includes only those vertices.

(walls,paths) := selectremove(e->rhs(e)="#", [entries(tgrid, 'pairs')]):
paths := map(s->sprintf("%d,%d",lhs(s)[]), paths):
H := SpecialGraphs:-GridGraph(m,n);
G := InducedSubgraph(H, paths);

We can use StyleVertex to highlight the start and finish.

StyleVertex(G, sprintf("%d,%d",start[]), color="LimeGreen");
StyleVertex(G, sprintf("%d,%d",finish[]), color="Red");

plots:-display(<
DrawGraph(H, stylesheet=[vertexshape="square", vertexborder=false, vertexcolor="Black"], showlabels=false) | 
DrawGraph(G, stylesheet=[vertexshape="square", vertexborder=false, vertexcolor="Black"], showlabels=false)>);

(I omitted a step where I set the vertex locations of the maze grid, you can see that in the attached worksheet)

Now finding a path through the maze is as easy as calling GraphTheory:-ShortestPath

sp := ShortestPath(G, sprintf("%d,%d",start[]), sprintf("%d,%d",finish[]) ):

StyleVertex(G, sp[2..-2], color="Orange");
StyleEdge(G, [seq({sp[i],sp[i+1]}, i=1..nops(sp)-1)], color="Orange");
DrawGraph(G, stylesheet=[vertexshape="square", vertexpadding=10, vertexborder=false,
             vertexcolor="Black"],  showlabels=false, size=[800,800]);

Now, Advent of Code seldom gives you a completely simple maze like this, often these is a twist like having to calculate the costs of turns seperately from the cost of steps, or each direction or position has a seperate cost associated with it.

For example, Day 16 has us starting facing east, and then turns cost 1000, while moving forward costs 1. That sort of problem is no longer exactly a maze, instead of the vertices being representing an "x,y" position, instead you increase the number of vertices by a factor of 4, so that you have a vertex for every position and orientation "x,y,o" with edges of weight 1 between adjacent vertices with the same orientation and edges of wieght 1000 to connect "x,y,N" to "x,y,E" and "x,y,W" e.g.  In that sort of weighted graph, we can use GraphTheory:-DijkstrasAlgorithm to find the shortest path and it's weighted cost.

In this code, we expand our list of maze locations with directions, and the use the grid table to generate a list of weighted edges:

dtable := table([0=[0,1], 1=[1,0], 2=[0,-1], 3=[-1,0]]):
dname := table([0="N",1="E",2="S",3="W"]):
dpaths := map(s->local d;seq(cat(s,",",d), d in ["N","E","S","W"]), paths):

edges := NULL:
for i from 1 to m do for j from 1 to n do
    if tgrid[[i,j]] = "#" then next; end if;
    for d from 0 to 3 do
        dir := dtable[d];
        if tgrid[[i,j]+dir] <> "#" then
            edges := edges, [{cat("",i,",",j,",",dname[d]), cat("",i+dir[1],",",j+dir[2],",",dname[d])},1];
        end if;
        edges := edges, [{cat("",i,",",j,",",dname[d]), cat("",i,",",j,",",dname[d+1 mod 4])}, 1000],
                 [{cat("",i,",",j,",",dname[d]), cat("",i,",",j,",",dname[d-1 mod 4])}, 1000];
    end do;
end do; end do:

Gd := Graph(dpaths,weighted,{edges});

Once that is done, it's a simple matter of calling Dijkstra's Algorithm on the graph, but notice that we can reach the finsh while traveling north or east, so we need to find the sortest path to both (you can pass a list of vertices to Dijkstra, and it will efficiently calculate paths to all of them), and select the smaller of the two:

spds := DijkstrasAlgorithm(Gd, cat("",start[1],",",start[2],",E"), 
    [cat("",finish[1],",",finish[2],",N"), cat("",finish[1],",",finish[2],",E")] , 
    distance):
i := min[index](map2(op,2,spds)):
spd := spds[i];

spd := [["2,2,E", "3,2,E", "4,2,E", "4,2,N", "4,3,N", "4,4,N", "4,5,N", "4,6,N", "4,6,E", "5,6,E",
 "6,6,E", "7,6,E", "8,6,E", "8,6,N", "8,7,N", "8,8,N", "8,9,N", "8,10,N", "8,11,N", "8,12,N", 
"8,12,W", "7,12,W", "6,12,W", "5,12,W", "4,12,W", "3,12,W", "2,12,W", "2,12,N", "2,13,N", 
"2,14,N", "2,14,E", "3,14,E", "4,14,E", "5,14,E", "6,14,E", "7,14,E", "8,14,E", "9,14,E", 
"10,14,E", "11,14,E", "12,14,E", "13,14,E", "14,14,E"], 6036]

We can then plot to compare this to the unweighted shortest path:

dsp := ListTools:-MakeUnique( map(s->s[1..-3], spd[1]) );
StyleVertex(G, dsp[2..-2], color="DarkBlue");
StyleEdge(G, [seq({dsp[i],dsp[i+1]}, i=1..nops(dsp)-1)], color="DarkBlue");

DrawGraph(G, stylesheet=[vertexshape="square", vertexpadding=10,
             vertexborder=false, vertexcolor="Black"],  showlabels=false,
          size=[800,800]);

And you can see it's a path that requires more steps, but definitely uses fewer turns if we start facing east/right (6 vs. 9):

I hope this has given you a little bit of a flavor of how to use GraphTheory commands to solve path finding problems.  Like with the second part here, usually the biggest challenge is figuring out how to encode and construct a graph that represents your problem.  Then the actual commands to solve it, are easy. You can see all the code, and a couple steps I left out from above in this worksheet: Mazeblog.mw

And just for fun, here's a Maple workbook that imports a maze from an image and solves it: MazeFromImage.maple

About once a year Advent of Code give you a problem that is a gift if you are using a computer algebra system. This year that day was Day 13. The day 13 problem was one of crazy claw machines.  Each machine has two buttons that can be pressed to move the claw a given number of X and Y positions and a prize at a given position. A buttons cost 3 tokens to press, and B buttons cost 1 token to press, and we are asked to find the minimum number of tokens needed, IF it is possible to reach the prize. The data presented like so:

Button A: X+94, Y+34
Button B: X+22, Y+67
Prize: X=8400, Y=5400

Button A: X+26, Y+66
Button B: X+67, Y+21
Prize: X=12748, Y=12176

...

Some times the input is harder to parse than the problem is so solve, and this might be one of those cases.  I tend to reach for StringTools to take the input apart, but today the right tool is the old school C-style sscanf (after using StringSplit to split at every double linebreak).

machinesL := StringTools:-StringSplit(Trim(input), "\n\n");
machines := map(m->sscanf(m,"Button A: X+%d, Y+%d\nButton B: X+%d, Y+%d\nPrize: X=%d, Y=%d"), machinesL):

Now we have a list of claw machine parameters in the form [A_x, A_y, B_x, B_y, P_x, P_y] and we need to turn those into equations that we can solve. We want the number of A presses a, and B presses b to get the claw to the P_x, P_y position of the claw, it is simple to just write them down:

for m in machines do
   eqn := ({m[1]*a+m[3]*b=m[5], m[2]*a+m[4]*b=m[6]});
end do;

Now because of the discrete nature of this problem, we need our variables a and b to be non-negative integers.  When solving this, I first reached for isolve like this:

tokens := 0;
for m in machines do
   eqn := ({m[1]*a+m[3]*b=m[5], m[2]*a+m[4]*b=m[6]});
   sol := isolve(eqn);
   if sol <> NULL then
      tokens := tokens + eval(3*a+b, sol);
   end if;
end do;

Now, sometimes Advent of Code inputs contain a lot of hidden structure.  I wrote the code above, it worked on the sample input, so I tried it immediately on my real input (about 300 claw machines like the above) and IT WORKED.  But, you might notice that this code does not deal with a couple cases that could have appeared.  In particular, it doesn't check that the solutions are positive.  It also doesn't handle cases where there is more than one possible solution.  The former is easy to check

if sol <> NULL and eval(a,sol) >= 0 and eval(b,sol) >= 0 then

Unfortunately isolve does not handle inequalities, but you could try with solve, but it doesn't save us any checking, because we'd still have to check if the solutions are integers, so we might as well have just solved the equation and then checked if it were a nonnegative integer.

tokens := 0;
for m in machines do
   eqn := {m[1]*a+m[3]*b=m[5], m[2]*a+m[4]*b=m[6], a>=0, b>=0};
   sol := solve(eqn);
   if type(eval(a,sol), integer) and type(eval(b,sol),integer) then
      tokens := tokens + eval(3*a+b, sol);
   end if;
end do;
ans1 = tokens;

In the multiple solution case we get something like {a = 3 - 2*b, 0 <= b, b <= 3/2} which has some great information in it but might be hard to handle programmatically, so let's see what isolve does with those cases to see if it's easier to deal with

> eqn := { 17*a + 84*b = 7870, 34*a + 168*b = 15740 }:
> constr := { a >= 0, b>= 0 }:
> sol := isolve(eqn);
               sol := {a = 458 - 84 _Z1, b = 1 + 17 _Z1}

> constr := eval({ a >= 0, b>= 0 }, sol):
            const := {0 <= 1 + 17 _Z1, 0 <= 458 - 84 _Z1}

> obj := eval(3*a+b, sol);
                         obj := 1375 - 235 _Z1

You can see it's easy to tell if these show up in your input, since your "token" total will have the _Zn variables in it.  Now, since everything is simple and linear here, it seems like you could use solve to find the rational value of _Z1 that makes obj=0 and then take the closest integer but it's not so simple, we actually have to deal with the contraints that a and b be positive too. So, it really just makes sense to bring out the big hammer of Optimization:-Minimize which allows us to directly optimize over just the integers.  So a full solution looks like this:

tokens := 0:
for m in machines do
   eqn := ({m[1]*a+m[3]*b=m[5], m[2]*a+m[4]*b=m[6]});
   sol := isolve(eqn);
   if sol = NULL then
      next;
   end if;
   constr := eval({ a >= 0, b>= 0 }, sol);
   obj := eval(3*a+b, sol);
   if not type(obj, constant) then
      tokens := tokens + Optimization:-Minimize( obj, constr, assume=integer )[1];
   elif andmap(evalb, constr) then
      tokens := tokens + obj; 
   end if;
end do;

But since we're bringing out the big hammer, why not just use Optimization in the first place.  The main reason is that Minimize doesn't simply return NULL when it doesn't work, instead it throws an exception, so we need to find all the exceptions that can occur and handle then with a try-catch, thus:

tokens := 0;
for m in machines do
   eqn := ({m[1]*a+m[3]*b=m[5], m[2]*a+m[4]*b=m[6]});
   try 
       sol := Optimization:-Minimize(3*a+b, eqn, 'assume'='nonnegint')[1];
       tokens := tokens + sol;
   catch "no feasible":
   end try; 
end do;
tokens;

(you can in fact omit the string in the catch: statement, but I can tell you from long experience that that is an excellent way to make your code much much harder to debug)

Alright, so how did people not using Maple solve this problem?  The easiest way to solve it, and the one used by all the cheaters scraping the website and using LLM-based code generators that auto-submit solutions to get into the Top 100, was to just check all possible a, b values in 0..100 and take the values than minimize 3*a+b when reaching the prize coordinates.  That's only feasible because the problem states the 100 is an upperbound for a and b, but it's also very fast (about 1/10 second in Maple):

tokens := 0:
for m in machines do;
sol := infinity;
for i from 0 to 100 do for j from 0 to 100 do
    if i*m[1]+j*m[3]=m[5] and i*m[2]+j*m[4]=m[6] and 3*i+j < sol then
        sol := 3*i+j;
    end if;
end do; end do;
tokens := tokens + ifelse(sol=infinity,0,sol);
end do;

It does not scale at all to part 2 (which modified everything to be bigger by about 10 trillion), and it seems that foiled all the LLM solvers. So, what solutions scaled in languages without integer equation solvers?  Well, the easiest solution is just to solve the general equation using paper and pencil

And you can just hard code that formula in, check that it gives integer values and compute the tokens. As long as you get unique solutions, that looks something like this

solveit := proc(m)
local asol := m[4]*m[5] - m[3]*m[6];
local bsol := m[1]*m[6] - m[2]*m[5];
local deno := m[1]*m[4] - m[2]*m[3];
if deno = 0 then return -2^63; end if; # multiple solution case - not handled
if asol mod deno = 0 and bsol mod deno = 0
   and (   ( deno>=0 and asol>=0 and bsol>=0 ) 
        or ( deno<=0 and asol<=0 and bsol<=0 ) )
then

    return 3*asol/deno+bsol/deno;
else
    return 0;
end if;
end proc:

Which if you have this in Maple, you can impress your friends by auto generating solutions in other languages. Here, for your FORTRAN friends

> CodeGeneration:-Fortran(solveit);

Warning, the following variable name replacements were made: solveit -> cg
       integer function cg (m)
        doubleprecision m(*)
        integer asol
        integer bsol
        integer deno
        asol = int(-m(3) * m(6) + m(4) * m(5))
        bsol = int(m(1) * m(6) - m(2) * m(5))
        deno = int(m(1) * m(4) - m(2) * m(3))
        if (deno .eq. 0) then
          cg = -9223372036854775808
          return
        end if
        if (mod(asol, deno) .eq. 0 .and. mod(bsol, deno) .eq. 0 .and. (0
     # .le. deno .and. 0 .le. asol .and. 0 .le. bsol .or. deno .le. 0 .a
     #nd. asol .le. 0 .and. bsol .le. 0)) then
          cg = 3 * asol / deno + bsol / deno
          return
        else
          cg = 0
          return
        end if
      end

Another way that you might solve this without solve is to use a linear algebra library to solve the linear system.  It works even if you only have a numeric solver, but you have to be careful about checking for integers:

tokens := 0:
for m in machines do
    sol := LinearAlgebra:-LinearSolve(
               Matrix(1..2,1..2,[m[[1,3]],m[[2,4]]], datatype=float), 
               Vector(m[5..6], datatype=float));
    if abs(sol[1]-round(sol[1])) < 10^(-8) and abs(sol[2]-round(sol[2])) < 10^(-8)
       and sol[1] >= 0 and sol[2] >= 0
    then
       tokens := tokens + 3*sol[1]+sol[2];
    end if;
end do;

Finally, a lot of people solved this sort of thing with the Z3 Theorem prover from Microsoft research which is also way more than you need, but it mostly just uses SMTLIB, which we also have in a library for in Maple, and it can just be used in place of solve

tokens := 0;
for m in machines do
   eqn := {m[1]*a+m[3]*b=m[5], m[2]*a+m[4]*b=m[6], a>=0, b>=0};
   sol := SMTLIB:-Satisfy(eqn) assuming a::nonnegint, b::nonnegint;
   if sol <> NULL and type(eval(a,sol), integer) and type(eval(b,sol),integer) then
      tokens := tokens + eval(3*a+b, sol);
   end if;
end do;

Notice that Satisfy handled the multiple solution case just by choosing one of the many solutions. It is possible to get SMTLib to optimize but it is slightly more involved, and this post is already too long. This time, I've put all this work in worksheet: Day13-Primes.mw