# What capability would you want to see added to the symbolic toolbox in the future?

1 view (last 30 days)
John D'Errico on 2 Jan 2020
Answered: tommsch on 30 Nov 2020
As someone who has written several tools to work with high precision numbers and large scale integers, I've also used the symbolic toolbox for many such computations. In fact, I've been pleased at times in how well they have improved those tools in recent years. For example, the speed of large integer computations in the symbolic toolbox is now at least pretty good. For example, a recent computation of mine to test if a number with roughly 86000 decimal digits is prime took only 20 minutes to return a negative result. (The number in question is one that I knew to have no small prime factors.) That is not too bad in context, though I'd love to see it improve.
However, there are a few new capabilities I'd love to see implemented. So what do you think is missing? (I'll add my own opinions as my own answer.)

John D'Errico on 2 Jan 2020
Edited: John D'Errico on 4 Jan 2020
My own wish list starts with the large integer capabilities...
1. A direct modular multiplicative inverse. Note that you can get exactly that from one of the returns of gca, however, a modular inverse makes a lot of sense, and is trivial to implement. (I've attached a simple modular inverse tool to this answer to show that it is indeed easy to compute, based purely on MATLAB's GCA utility.)
2. A modular square root. This is not quite so trivial, but there are several fast algorithms to be found to compute, perhaps starting with Shanks-Tonelli.
3. Modular n'th roots might be nice too, though it has been the sqrt that seems most valuable in my experience. I could survive without a modular n'th root.
4. The fibonacci function is nice, but for some computations all you really need is mod(F_n,p), where p is some large integer. That is, while a student might like to see a million digit numberreturned, much of the time, you don't really need that million digit number returned, but just the modulus, and it is MUCH faster to compute the mod.
5. Much like Fibonacci, the Lucas numbers can be valuable tools. They also should have the capability to be returned in a modular form.
6. A direct quadratic residue computation would be nice, without needing to venture into the realm of MuPad.
Numbers 1 and 2 above can most easily be implemented as options to powermod. Thus we could allow a negative power for powermod, or a power of 1/2. We would have the modular inverse of x wrt base p as
powermod(x,-1,p)
Likewise, the modular square root of x would simply arise from
powermod(x,1/2,p)
The beauty of such an extension to powermod is it would require no new functions, just additional functionality for a code where it currently produces an error. powermod should and could give us everything we want.
Yes, I will concede that you can get a modular square root from mupad. For example...
X = 12345;
p = nextprime(1e9)
p =
1000000007
Xroot = feval(symengine, 'numlib::sqrtmodp', X, p)
Xroot =
258519153
mod(Xroot.^2,p)
ans =
12345
But I'm afraid this seems a bit of a kludge, requiring the use of feval. Anyway, the above computation will fail some of the time, seemingly returning a result when no modular root exists. And, yes, I could have predicted exactly that failure in advance.
X = 12346;
Xroot = feval(symengine, 'numlib::sqrtmodp', X, p)
Xroot =
419311443
mod(Xroot.^2,p)
ans =
999987661
ans =
FALSE
with yet another call to the kludgistic feval.

Walter Roberson on 5 Jan 2020
The whole apparatus for breaking apart symbolic expressions and processing sub-parts feels like a bit of a crock, and is not well documented. Most people don't even know that it exists, and it always takes me a while to find in the documentation even though I know it exists. Cross-referencing between the functions is not good either; in particular it is always hard to find https://www.mathworks.com/help/symbolic/sym.mapsymtype.html mapSymType to process transformations.

Star Strider on 5 Jan 2020
That the Laplace transforms work with solve and other such functions, and are actually tractable!
See for example: this Comment.
This tends to be really frustrating. It would also help if the initial conditions could be specified similar to the way they are in dsolve.
Star Strider on 5 Jan 2020
@ Walter — Interesting. Thank you!
The inverse Laplace transform would likely require complex integration to be truly accurate. The problem is that the example I cited should be easily solvable using the algebraic methods that work with simple algebraic equations. It is virtually impossible to solve the Laplace complex ‘s’ domain for ‘X(s)’ in this instance, although that should be straightrforward.

Matt J on 5 Jan 2020
The ability to manipulate symbolic matrix variables (instead of just matrices of scalar symbolic variables).
Walter Roberson on 5 Jan 2020
Yes... Unfortunately this is baked in pretty far down in the symbolic engine :(
I have looked at the symbolic engine enough to know that it should be possible to create routines that work with symbolic variables that stand in for matrices, but it would not be a simple extension.

tommsch on 30 Nov 2020
Compatibility of the symbolic toolbox with the rest of matlab. In particular: Same interfaces of functions when taking symbolic or no symbolic input.