A few months ago, I posted my path integral functions, which are included in the MATH214 package. Recently, I came across something I’d been looking for: a Maxima utility for visualizing vector fields. Its in the Maxima/Share directory under drawutils.
Written in 2010 by Donald J Bindner, the commands draw_vector_field and draw_vector_field3d do almost everything I was looking for. The drawback is that I wanted to plot the vector fields along with the integration path. I modified those two commands slightly into versions called make_vector_field and make_vector_field3d to produce the lists of vectors for plugging into draw2d and draw3d, so that I could include the vector fields in bigger graphics calls. My modifications are available here.
Here’s what the path integral command and the vector field generator look like on an example from chapter 13 of Stewart’s “Calculus Concepts and Contexts”
A few months ago, when I was very new to Maxima, I posted my solutions to several multivariable optimization problems, and included a standard constrained optimization example for which the built in command solve failed.
Here’s the problem:
In my multivariable calculus class, we’ve just encountered that problem again. What my students and I discovered was that the order of the variables as specified by the user in the argument list caused the command to either succeed or fail, as you can see from the first two lines below:
I wrote to the experts at firstname.lastname@example.org. They replied en masse very quickly and were very generous with their time and advice. They verified the problem, pointing out that solving systems of equations is really complicated, and that the solve program seeks to solve for the variables one at a time and things can go wrong if an inauspicious order of variables is followed.
The experts also tried our problem with the package to_poly_solve, and happily it succeeded without the hassle of needing to specify the variables in the right order. For solve users who reference the solutions it produces as elements of a list, direct use of to_poly_solve presents a challenge due to output in a format different from that of solve — t0_poly_solve returns solutions as a set with %union.
I’ve written a little wrapper Ksolve.mac that is called like solve as illustrated above.
In Ksolve if an initial call to solve fails, the process automatically upgrades to to_poly_solve in several variations, and (hopefully) returns solutions in the same format as solve.