In the following code, I can evaluate S(32), but not S(31).
restart
sig:=167:
t:=i->exp(-(i^2)/(2*(sig^2)))
S:=l->sum(t(i),i=l..infinity)
evalf(S(32)) evaluates to 177.989, but evalf(S(31)) just spits back the symbolic formula for S (it should evaluate to ~178.972).
I've looked into using sum vs Sum with evalf, but nothing seems to change this behavior. I don't care to see the numerical value for S(31), but Maple can't seem to be able to use it to do anything useful, which is a problem. For example, plot(S(y),y=20..50) (when using sum) is incomplete.
What is so different between S(32) and S(31), and how can I get Maple to evaluate both?
Related
I have a lengthy symbolic expression that involves rational polynomials (basic arithmetic and integer powers). I'd like to simplify it into a single (simple) rational polynomial.
numden does it, but it seems to use some expensive optimization, which probably addresses a more general case. When tried on my example below, it crashed after a few hours--out of memory (32GB).
I believe something more efficient is possible even if I don't have a cpp access to matlab functionality (e.g. children).
Motivation: I have an objective function that involves polynomials. I manually derived it, and I'd like to verify and compare the derivatives: I subtract the two expressions, and the result should vanish.
Currently, my interest in this is academic since practically, I simply substitute some random expression, get zero, and it's enough for me.
I'll try to find the time to play with this as some point, and I'll update here about it, but I posted in case someone finds it interesting and would like to give it a try before that.
To run my function:
x = sym('x', [1 32], 'real')
e = func(x)
The function (and believe it or not, this is just the Jacobian, and I also have the Hessian) can't be pasted here since the text limit is 30K:
https://drive.google.com/open?id=1imOAa4VS87WDkOwAK0NoFCJPTK_2QIRj
I'm working with the following code and I've run into a strange issue. If I do the following:
syms x n chebyprime(n,x)
chebyprime(n,x)=diff(chebyshevT(n,x),x);
The function outputs the expected result. But if I tweak it like this:
chebyprimeplus(n,x)=diff(chebyshevT(n+1,x),x)
It breaks the whole thing. Instead of a numeric output (Which would be expected of a derivative of a polynomial evaluated at a specific point) I get output like this:
>> chebyprimeplus(3,.2)
ans =
D([2], chebyshevT)(4, 1/5)
This is baffling behavior to me. It looks like it's outputting in some sort of mupad syntax, and I can't find any way to convert this to a numeric value. I don't see any reason simply upping the order of the chebyshev should cause the integration to fail and when I input a higher order by increasing the value of n it works fine so it's not an issue with the diff operator's ability to differentiate the chebyshev polynomial. Can anyone help me sort this out?
Thanks.
I am trying to run code similar to the following, I replaced the function I had with one much smaller, to provide a minimum working example:
clear
syms k m
n=2;
symsum(symsum(k*m,m,0,min(k,n-k)),k,0,n)
I receive the following error message:
"Error using sym/min (line 86)
Input arguments must be convertible to floating-point numbers."
I think this means that the min function cannot be used with symbolic arguments. However, I was hoping that MATLAB would be substituting in actual numbers through its iterations of k=0:n.
Is there a way to get this to work? Any help much appreciated. So far I the most relevant page I found was here, but I am somewhat hesitant as I find it difficult to understand what this function does.
EDIT following #horchler, I messed around putting it in various places to try and make it work, and this one did:
clear
syms k m
n=2;
symsum(symsum(k*m,m,0,feval(symengine, 'min', k,n-k)),k,0,n)
Because I do not really understand this feval function, I was curious to whether there was a better, perhaps more commonly-used solution. Although it is a different function, there are many pieces online advising against the eval function, for example. I thought perhaps this one may also carry issues.
I agree that Matlab should be able to solve this as you expect, even though the documentation is clear that it won't.
Why the issue occurs
The problem is due the inner symbolic summation, and the min function itself, being evaluated first:
symsum(k*m,m,0,min(k,n-k))
In this case, the input arguments to sym/min are not "convertible to floating-point numbers" as k is a symbolic variable. It is only after you wrap the above in another symbolic summation that k becomes clearly defined and could conceivably be reduced to numbers, but the inner expression has already generated an error so it's too late.
I think that it's a poor choice for sym/min to return an error. Rather, it should just return itself. This is what the sym/int function does when it can't evaluate an integral symbolically or numerically. MuPAD (see below) and Mathematica 10 also do something like this as well for their min functions.
About the workaround
This directly calls a MuPAD's min function. Calling MuPAD functions from Matlab is discussed in more detail in this article from The MathWorks.
If you like, you can wrap it in a function or an anonymous function to make calling it cleaner, e.g.:
symmin = #(x,y)feval(symengine,'min',x,y);
Then, you code would simply be:
syms k m
n = 2;
symsum(symsum(k*m,m,0,symmin(k,n-k)),k,0,n)
If you look at the code for sym/min in the Symbolic Math toolbox (type edit sym/min in your Command Window), you'll see that it's based on a different function: symobj::maxmin. I don't know why it doesn't just call MuPAD's min, other than performance reasons perhaps. You might consider filing a service request with The MathWorks to ask about this issue.
I've just updated to Matlab 2014a finally. I have loads of scripts that use the Symbolic Math Toolbox that used to work fine, but now hit the following error:
Error using mupadmex
Error in MuPAD command: Division by zero. [_power]
Evaluating: symobj::trysubs
I can't post my actual code here, but here is a simplified example:
syms f x y
f = x/y
results = double(subs(f, {'x','y'}, {1:10,-4:5}))
In my actual script I'm passing two 23x23 grids of values to a complicated function and I don't know in advance which of these values will result in the divide by zero. Everything I can find on Google just tells me not to attempt an evaluation that will result in the divide by zero. Not helpful! I used to get 'inf' (or 'NaN' - I can't specifically remember) for those it could not evaluate that I could easily filter for when I do the next steps on this data.
Does anyone know how to force Matlab 2014a back to that behaviour rather than throwing the error? Or am I doomed to running an older version of Matlab forever or going through the significant pain of changing my approach to this to avoid the divide by zero?
You could define a division which has the behaviour you want, this division function returns inf for division by zero:
mydiv=#(x,y)x/(dirac(y)+y)+dirac(y)
f = mydiv(x,y)
results = double(subs(f, {'x','y'}, {1:10,-4:5}))
Using MuPAD, I want to find out if at least one solution exists for a set of of linear inequalities. For example, the following system of linear inequalities:
which I solve in MuPAD by:
solve({x+z>2*y,z>y,2*z>2*x,x>0,y>0,z>0},{x,y,z}
and MuPAD returns the set of solutions, in some type of notation:
However, I do not care about the exact form of the solution set, i.e., whether it is finite, or infinite, I just care if there is at least one viable solution.
I would like to call MuPAD from Matlab, ask if a solution set exists to the inequalities, and then get back a "yes" or "no" answer. I could test for the empty set being returned, but I do not know how to test if a symbolic variable represents the empty set.
Here's an example using MuPAD's solve and sym/isempty called from Matlab:
syms x y z;
~isempty(feval(symengine,'solve',[x+z>2*y,z>y,2*z>2*x,x>0,y>0,z>0],[x y z]))
~isempty(feval(symengine,'solve',[x+z>2*y,z>y,2*z>2*x,x>0,y>0,z<0],[x y z]))
The first case returns true, 1, indicating that there is at least one solution. The second returns false, 0, as there is no solution.
If you want to do this within MuPAD, you can use the is function:
not(is(solve([x+z>2*y,z>y,2*z>2*x,x>0,y>0,z>0],[x,y,z])={}))
not(is(solve([x+z>2*y,z>y,2*z>2*x,x>0,y>0,z<0],[x,y,z])={}))
However, the first case will return UNKNOWN, which is rather difficult to deal with. You may want to use something like the following instead:
is(length(solve([x+z>2*y,z>y,2*z>2*x,x>0,y>0,z>0],[x,y,z]))>1)
is(length(solve([x+z>2*y,z>y,2*z>2*x,x>0,y>0,z<0],[x,y,z]))>1)
which assumes that only an empty solution, Ø, will have a length of one. (The MuPAD code is two characters, {}, but it displays as one, Ø, has a length of one, and means empty/zero.) There are probably other ways.