Consider this:
The examples show that Mathcad 15 may be a dangerous tool when used for solving systems of linear equations. If we set up a system of linear equations and the equations by mistake becomes singular, we may not discover our mistake, since Mathcad returns a unique solution anyway.
Maple, Wolfram Alpha (Mathematica) and the TI-89 calculator return results that indicate if there are no, one unique og infinitely solutions. For the examples above Maple gives the follwing answer:
Is it possible to make Mathcad give more informative results in case of singular systems of equations?
/Henning
Henning Søgaard schrieb:
The examples show that
It seems that you intended to include a worksheet or at least screenshots but failed to do so.
If you solve your system numerically, the solution depends strongly upon the guess values provided and you get only one solution (at best). Thats OK, regarding that we have to do with a numerical approximation.
Solving symbolically either via solve from the symbolic palette or by evaluating a solve block symbolically without guess values, I agree, that Mathcad should at least warn if the solution calculated is not unique. If there is no solution you get a "no solution found" error anyway.
In case of an infinite number of solutions, by default you are presented with a single solution only unless you use the modifier "fully". See screenshots:
Well, I copied the Mathcad-examples into the original post but for some reason it has disappeared. I cannot figure out how to attach a worksheet to this reply. I try to insert an image - here it is:
According your first example see my remarks to "fully"
Your second example is bad - it should yield the "no solution found" error. Assume the reason being numerical inaccuracy even whilst using the symbolic evaluation. After all, using a solve block means using an iteration and approximation.
The symbolic solve does the job correctly
It is not using the numeric processor. The symbolic processor can do arbitrary precision arithmetic, which is what it is doing in this case. It's not solving it iteratively though, and therefore does not need guess values. When there are no floating point numbers in the expressions it's supposed to do exact, integer, arithmetic though, unless you specify otherwise using the float keyword.
You get the same result using the float keyword with the default value of 20. I would call this a bug.
What version of 15 are people using, M010? I do not have access to MC at the moment, but there was a recent update to MC 15 that may have added or solved this issue. Just trying to help pinpoint if its an existing "bug" or a new one 
ELSID schrieb:
What version of 15 are people using, M010? I do not have access to MC at the moment, but there was a recent update to MC 15 that may have added or solved this issue. Just trying to help pinpoint if its an existing "bug" or a new one
I'm using MC15 M020 dating from 2012-11-27 which AFAIK is the latest release. As Richard and me both have that issue, it looks like they did neither have added nor solved that issue.
Wow, thats strange. Multiplying the first equation by 3 or dividing the second by by 3 yields the (correct) "no solution found" error. Whats going on here??
Even the order of the two equation matters
So clearly - if you want to be on the safe side, use symbolic solve and/or check your matrix for singularity yourself.
Richard Jackson schrieb:
Richard called it a bug.
Either that. or a very undesirable "feature"
I agree, fully 
But if you then think that Mathcad's solve should default to "fully", look at the next screenshot and reconsider your opinion 😉
It makes sense that it is up to the user to use "fully" or not. On the other hand, if the user does not apply "fully" when solving a system of equations with infinitely solutions it would be nice with a warning, just as you pointed out earlier.
In one of the examples where you applied "fully" I noticed that solve introduced a complex parameter (_z) in the answer. I tried to restrict the answer to the real domain by applying the condition y = real as follows but it didn't have any effect.
Why is that?
Since Mathcad switched from Maple to muPad as the numeric processor with version 14, all calculations default to domain complex (in older Mathcads you had to use the modifier complex to get into that mode). Unfortunately restricting solutions to domain real never worked reliable as it should - i would call it a bug. Often calculations are not simplified the way we would do it by hand, simply because Mathcad is not willing to accept an "assume, ALL=real" condition. Those arbitrary values _z, _z1, etc., Mathcad throws in in under-determined situations, seem to default to domain complex all the time.
A similar bug^, which was discussed here not long ago, is, when you try to force a variable x ,you solve for, to be integer, by applying the condition trunc(x)=x. It simply doesn't work. Either MC finds no solution or the condition is ignored.
I just played around with assume (as I thought that it would not make sense to apply assume,y=real after solve, as then no y ist present anymore). But I found another buggy behaviour. Look at the effect which "assume,y=real" has on the name of the arbitrary variable compared to "assume,ALL=real".
Since Mathcad switched from Maple to muPad as the numeric processor with version 14,
Symbolic processor 
Unfortunately restricting solutions to domain real never worked reliable as it should - i would call it a bug.
It's not a bug. It just doesn't work very well. With the Maple symbolic engine it was not possible to force the domain of the solution at all. At least, not in one step. Even now, I tihnk the best approach is to get the full result first, then mess around with that to restrict the domain.
A similar bug^, which was discussed here not long ago, is, when you try to force a variable x ,you solve for, to be integer, by applying the condition trunc(x)=x. It simply doesn't work. Either MC finds no solution or the condition is ignored.
Do you mean with the numeric processor? That's not a bug. It's just a limitation of the solver. It can't handle flat regions in the objective function, because when it iterates nothing changes. There used to be a solving extension pack that had functions that could obtain integer solutions, but it dosen't work with any version after MC11 
Symbolic processor
Yes, of course.
It's not a bug. It just doesn't work very well. With the Maple symbolic engine it was not possible
You're right. Just a fine difference.
Do you mean with the numeric processor? That's not a bug. It's just a limitation of the solver. It can't handle flat regions in the objective function, because when it iterates nothing changes. There used to be a solving extension pack that had functions that could obtain integer solutions, but it dosen't work with any version after MC11
Yes, you are right. I was thinking on an exemple from http://communities.ptc.com/message/193351#193351
In that solve block I had to disable at least one (any one) of the three trunc-conditions to get the numeric solver to find a solution. Strange enough with all three enabled the erreor message was not "no solution found" but "this variable is undefined" (tracing guided me to the denominator of the RHS fraction and the expected "no solution was found").
Symbolic evaluation results in a "no solution found" even if only one trunc-condition is enabled.
