Unfortunately, GraphTheory does not have an easy way to get all the shortest paths between two vertices, even though they DFS or Dijkstra algoritimn will actually find them (extra work is needed to actually record them along the way however).  I have to code my own graph search by hand to solve the second part of this Advent of Code problem: https://github.com/johnpmay/AdventOfCode2024/blob/main/Day16/Day16.mpl

@sursumCorda I meant to attach the worksheet.  You actually need an additional step to work around a bug in InducedGraph where it doesn't copy of the vertex positions properly:

for v in Vertices(G) do
    SetVertexAttribute(G, v,"draw-pos-fixed"=GetVertexAttribute(H,v,"draw-pos-fixed"));
end do;

Then there is a typo in my direction handling, 7036 6036 is correct if you start facing E and end facing E -- I will update the post.

Yeah, I think this is definitely the ideal way to solve things in Maple. I unnecessarily used isolve for my intial solve, but then for this post, I wanted to talk a little bit about the possible pathological cases that didn't show up in the actual problem, and then what techniques you might use in languages without ration numbers. Honestly, I probably should have talked a little more about the numerical difficulties in part 2 when you add an 11 digit integer into the mix.

@Carl Love As you might be able to tell, multiple places in this post, I desperately need an Editor to review my writing.  Of course this should be titled Advent of Code 2024 - but I have beening working on the problems in pre-beta builds of the upcoming Maple 2025, so that was in my brain.  Thanks for catching that, I have updated the title. 

Now is a good time for leaping into the challenge, the problems generally start to get interesting in the second half of the second week.

Another option here is to convert the expresion to exp form: convert(Eq,exp)

I have fixed this problem in the development version of Maple, and in future versions of Maple the explicit solutions will be found without any workarounds.

@WD0HHU Thanks!  It was really hard to make visualizations that looked this good in Maple 10 years ago, but over time there has been a lot of great work by many people on the team so we're now at the point that is pretty straight forward to put all the pieces together for something like this, as you can see in the worksheet.

@sursumCorda The Steam Desk does okay on this one, but since it churns through a lot of memory (20GB!) I find my Workstation with 32GB of RAM does a little better than the Deck that has only 14GB (2GB is used for  the gpu I believe).

Here's the Steam Deck running almost 7 minutes CPU time when my Xeon E5 does it in just less than 5 minutes, most of the difference being in GC time.

In most applications, it might be better to interactively format one graph at a time and then call DrawGraph with layout=user (or layout=default or no layout option at all) to use the saved positions (you can also grab them using GraphTheory:-GetVertexPositions to use with GraphTheory:-SetVertexPositions in a different session).

@acer said:

A technique used within some routines under int, is, etc, consists of storing (up front) a FAIL result for a call to a procedure that might eventually induce an identical call to itself. If this is performed prior to the first call, and if a suitable check for that value is made upon re-entry, then infinite recursion errors might be prevented.

acer puts their finger on what can cause the second call to int to succeed after the first one fails. There is a FAIL being stored in a remember table somewhere above where the infinite recursion exception occurs. So, the next time an identical calls is made a FAIL gets returned instead and then the computation takes a different path and doesn't trigger the exception.

So, one possible solution is to put the FAIL in a remember table even lower down the call stack so that the infinite recursion doesn't happen at all. But like wrapping code in blanket try-catch statements, that sort of thing should definitely only be used as a last resort. I avoid adding these sorts of remember table based recursive loop traps because in most cases they are not fixing problems but only wallpapering over them and end up creating new cases of unpredictable/non-reentrant/session-dependent behavior while potentially hiding other problems as well.

This particular example is pretty interesting and, I think, instructive: a couple calls after RationalFunction, the integrator is checking if F <> convert(F, parfrac, x) before recursing back to RationalFunction(F,x). The infinite recursion happens in the case that the parfrac conversion returns a rational function not indentical to F but still essentially the same (in this case F:=1/(-10*exp(2)*_z+25*_z^2+exp(4)-50*exp(2)+250*_z+625)). A lot of infinite recursion bugs end up looking a lot like this and the fix is to do a more careful check rather than just checking equality.

> F:=1/(-10*exp(2)*_z+25*_z^2+exp(4)-50*exp(2)+250*_z+625);
                                             1
            F := ----------------------------------------------------------
                                      2
                 -10 exp(2) _z + 25 _z  + exp(4) - 50 exp(2) + 250 _z + 625

> convert(F, parfrac, _z);
                                           1
               ---------------------------------------------------------
                    2
               25 _z  + (-10 exp(2) + 250) _z - 50 exp(2) + exp(4) + 625

# in this case, Maple knew F should have a better partial fraction decomposition
# but it needs special help to get it, since it involves transcendental constants
> frontend(convert, [eval(F,exp(4)=exp(2)^2)], [], parfrac, _z);
                                          1
                                ----------------------
                                                     2
                                (-exp(2) + 5 _z + 25)

# If parfrac had produced this, calling RationalFunction recursively would work

So in this case, you really want to check if the parfrac conversion factored the denominator (or, in general, created a sum) rather than simply checking equality.

@vv @LichengZhang that bug in DrawPlanar was actually fixed last year and so the next version of Maple will work better on this example.

@Scot Gould It's the San Gabriel mountains but west of Baldy.  The picture from is the top of the Brown Mountain fire "road" where it turns into the Ken Burton Trail https://www.mtbproject.com/trail/4902656

You couldn't come up with a better answer than Batman, John? smdh

@Jakey  Jake,

I am not sure whether I can disclose the exact details since that code isn't pubic (but, it is pretty easy to figure out by poking at gmp_isprime with some known Miller-Rabin psuedo-primes). I can say that isprime uses Miller-Rabin to get very fast composite number detection.  As you can see in the code, it only trusts a "true" from gmp_isprime result if N < 5*10⁹. For larger numbers, it throws out the Miller-Rabin answer and does a Lucas pseudoprime test which is implemented in pure Maple code.

I executed this in your worksheet and it seems to work fine:
DocumentTools:-SetProperty(Table1, fillcolor[1,1], [255, 99, 1]);

Nice work.

I was going to suggest adding colors to the numbers, but then I downloaded the worksheet and saw that you already had. :)

It's too bad that the cloud version doesn't seem to support that.  Did you try setting the table cell background color as well as the textArea?  That might partially work in the Cloud (and also look a little better in offline Maple).