Did we already discuss that kind of bug here?
And has anybody an idea what the reason for this strange errror (recursive definition) could be?
The error occurs when the frequency is negative and floating point,
Solved! Go to Solution.
Your memory is still OK. I guess this is where it was seen before:Recursive definition problem when extracting real part of equation.
Luc
This is Mathcad 11:
How does Prime deal with it?
Luc
Could have bet on that it would work OK with Maple.
Prime suffers from the same bug (at least version 3.0).
This is Mathcad 11:
How does Prime deal with it?
And this happens in MP4:
...the same problem...very strrrrrrange thing...
And the big choke is, that Mathcad 11 can evaluate it!
Volker
Check if there's a difference in solving sin(2 x), sin(-2 x), sin(2.0 x) and sin(-2.0 x), to see if Mathcad or Mupad handles those functions differently. Or do a series expansion.
Luc
Positive factors -> no problem. no matter how they are written
neagtive integers written without decimal point -> no problem
But when the factor is negative and is written with a decimal point, whatever I do symbolically with that expression, it will fail with that "recursive definition" error.
I'll try to get hold on a machine with an older release of MC15 or even MC14 to see, if the bug is already present there or was introduced later.
The 0 (zero) answer is too simple, what does 'solve fully' do? ( I don't have that in mathcad 11).
Luc
"full" works perfect for simple equations likes this, but again the same error when the argument is -2.0*x
Any difference when using 'solve fully' with positive 2 or 2.0...?
Luc
LucMeekes wrote:
Any difference when using 'solve fully' with positive 2 or 2.0...?
Luc
As already written, positive factor are no problem. Of course the symbolics is switched into numeric float mode because of the decimal point (a very annoying "feature" of the symbolics).
LucMeekes wrote:
Is this Symbolic Fourier Transform similar?
Don't think so. Guess it wasn't a bug there. The OP used a wrong syntax for the "fourier" command and was not aware of the annoying effect that the symbolics switch to its "numeric/float" mode whenever just one number is written with a decimal point.
This auto-float mode could be part of the reason for the bug as expressions are dealt with and are evaluated differently when in float mode. But I see no reason why a recursive definition should be diagnosed just because the symbolics work in float mode.
I vaguely remember a thread dealing with a bug/problem concerning symbolics and floating point numbers. Just can't remember, nor find the thread.
Some observations:
Viktor
Looks all OK and as expected to me (symbolic commands are executed in the order they are written) - no hint as to the recursive definition error when using sin(-2.0*x).
The -2=0 part looks silly but is simply the result of replacing "a" in the general solution (here dealing with the case a=0 makes sense) by -2. You can get rid of it by following the substitute command with "simplify".
I don't think it all looks OK.
Solutions for the equation sin(-2 * x)=0 are to be found.
These are:
(pi/2)*n with n is an element of Z (the simplest then is x=0 for n=0).
It is NOT that the solution is suddenly 'undefined' when n is not an element of Z !!
Luc
> I don't think it all looks OK.
You are right, but we got used to that way of Mathcad/muPad to tell us, that just multiples of pi/2 are solutions.
Your memory is still OK. I guess this is where it was seen before:Recursive definition problem when extracting real part of equation.
Luc
Wow, yes! Guess thats exactly what I had in a dusty corner of my mind. How did you manage to find it?
So the bug can be considered as well known (at least to some users) and still active.
Search term "resursive definition".
LucMeekes wrote:
Search term "resursive definition".
Shame on me
No, it just shows that you're human.