This is a question about maple producing undefined errors.
The code below should give the result 0 but instead maple chooses to label it "undefined".
(nj*(nj-1))*(int(N^(ni+nj-2),N=-1..1));
ni:=0; nj:=0;
Since nj=0 you can see quite clearly that even before the integral, the answer is 0 x integral.
The integral is possible to do and doing it by hand it gives you (-1/N) evaluated between 1 and -1
so substituting in (-1/1)-(-1/-1) which is -1-1 = -2).
The overall answer is given by 0x-2 which is 0.
Maple returns undefined.
However if you take a subsection of that code (just the integral)
(int(N^(ni+nj-2),N=-1..1)) or even (int(N^(-2),N=-1..1))
then maple returns infinity.
Neither of these are correct.
Can anyone explain to me why this happens?
I think others are likely to come across a similar issue because it is such a simple maple procedure. Yet it gives a confusing result.
As was already shared in the comments, 0 times infinity is undefined, see e.g. Why is infinity multiplied by zero not an easy zero answer
To still keep your Maple sheet as intact as possible, you can always include if-statements in the code, which is really easy
if nj = 0 then
#do something
end if;
However, you should always check if you are doing the right thing mathematically, as Maple does output Undefined for a reason!
Related
I've been able to use the polyRoots function since day one, but all of a sudden it stopped working and it keeps returning an empty result,does someone know what is happening? Thank you in advance! This is the return I get, I´ve put a very simple one so that I know it's not an input problem
The function polyRoots only returns the real-valued zeros of a polynomial. Instead, you can use cPolyRoots to include complex-valued zeros, which will -- in your case -- look something like this:
cPolyRoots(3*x^2+4*x+5,x)
{-2/3-sqrt(11)/3*i,-2/3+sqrt(11)/3*i}
In case you're not familiar with complex numbers, here's a Wikipedia article regarding them. Basically, i=sqrt(-1), which is a number that isn't present anywhere on the real number line; the real number line only includes negative infinity through positive infinity.
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 keep getting this error. I received this error after I corrected for logical integer error. The only way I could think of programming this was defining the initial value and then start euler's method at the next t value since it uses the previous solution to find the next one. But by doing this I am getting this error? I'm unsure how to fix it. I tried to end one step from my final value but that didn't work either. Thanks for the help. For the problem we had to create the function and call it. I was initially using n=8.
function [exeuler] = pb3(n)
%using explicit euler to solve ODE with input n and outputting exeuler as
%the answer
%n=steps t,y are initial conditions
h=3/n;
t=logical((1+h):h:4);
back=logical(t-h);
exeuler(1)=2; %defines the initial value
exeuler(t)=exeuler(back)+h*(t.^2-(2*exeuler(back)/t));
end
Well, I am sorry, but you haven't showed much of effort. For the future, please provide the complete code (i.e. with example function and so on). This is very unclear.
I think your problem is in these lines:
t=logical((1+h):h:4);
exeuler(t)=exeuler(back)+h*(t.^2-(2*exeuler(back)/t));
cause t is a vector. You are calling vector with non-integer values as index. Then, I guess, you get the wrong amount of exeuler(t)'s which leads to the error.
And for-loop is missing, isn't it? Because you don't use the Euler method stepwise andd therefore f(t+1) doesn't really depend on f(t).
So, my advice in general would be not to correct this error, but to rethink your algorithm.
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}))
I spent a couple of hours debugging a problem that I would have thought would have been a syntax error.
a = zeros(3);
for i=1:1size(a,2) % note the missing colon between 1 and size(a,2)
i
end
The following only displays
ans = 3
1
Essentially, it seems Matlab/Octave parses the above as:
for i=1:1
size(a,2)
i
end
Note however that
i=1:1size(a,2)
produces a syntax error. Is there a good reason that Matlab/Octave has this for loop syntax? Is there something that it's supposed to make easier? Just curious if anyone else has any thoughts about it. Thanks.
It is indeed a bit of a surprise that Matlab's syntax allows this. I don't know why this is allowed. One reason might be to allow for-loops on one line:
>> for i=1:3 disp(i);end
1
2
3
But interestingly, removing the space is not allowed:
>> for i=1:3disp(i);end
for i=1:3disp(i);end
|
Error: Unexpected MATLAB operator.
This reason for this is probably that a number followed by d is another way of writing a floating point number (3d10 == 3e10), so the parser/tokenizer initially thinks you define a number, but then gets confused when it sees the i. Daniel's example with fprintf does work, since a number followed by an f is not a valid number, so the tokenizer understands that you started a new token.
I guess that many years ago (>30?), when they defined matlab's syntax, they did not foresee that this could introduce this kind of hard-to-spot problems. I guess matlab was originally written by engineers for engineers, and not by someone who knows how to design a general purpose programming language. Other languages like C or Python use punctuation to separate loop conditions from loop body, so there is no ambiguity. I don't know if it is still possible to correct Matlab's syntax, since it might break old code that relies on the current behavior.
At least, if you use a recent version of Matlab, the editor warns for various problems in your code. Paying attention to the small red dashes in the right hand border could have saved you a few hours of debugging time (but maybe you were using octave). I try to make it a habit to fix all the warnings it indicates. For your code, it shows the following:
Your code is equivalent to
a = zeros(3);
for i=1:1
size(a,2)
i
end
There are some places where everyone would use newline or white space, but the parser itself does not require.
A minimal loop:
for i=1:3fprintf('%d',i),end
but I recommend to use at least a comma seperated version, everything else is horrible to read:
for i=1:3,fprintf('%d',i),end