Symbolic Issue?

[MoeSzyslak]

All --

Please see the attached worksheet. There is a problem with one of the symbolic calculations, but I don't use symbolics often, so it is very possible that I am the one making the mistake.

I see the problem in MC 14 M020, but I have saved down to MC 11 for all of the usual reasons -- an image of the problem is embedded in the file in case the problem is gone in MC 11.

Thanks.

Matt

[PhilipOakley]

It would appear to be the (internal) back tracing and substitution chain for M which gets upset at the geninv.

if you assign M:=M between the geninv and the symbolic, then the numerics continue to work and the solved formula now has M^2 in it.

I couldn't find a way (quick look 😉 to get the value of M show explicitly.

Sometimes one is fighting the numeric processor error messages, and sometimes the symbolic, and sometimes it is confusing (e.g. explicit!)

Philip Oakley

[MoeSzyslak]

On 11/19/2008 5:31:51 PM, philipoakley wrote:
>It would appear to be the
>(internal) back tracing and
>substitution chain for M which
>gets upset at the geninv.
>

Philip --

What is the purpose of this "internal back tracing"? Why does the symbolic processor care where the value of M comes from?

Matt

[PhilipOakley]

On 11/20/2008 9:00:58 AM, Moe_Szyslak wrote:
>On 11/19/2008 5:31:51 PM, philipoakley
>wrote:
>>It would appear to be the
>>(internal) back tracing and
>>substitution chain for M which
>>gets upset at the geninv.
>>
>
>Philip --
>
>What is the purpose of this "internal
>back tracing"? Why does the symbolic
>processor care where the value of M
>comes from?
>
>Matt

The symbolic pocessor 'back traces' to get back to the fundamental definitions, e.g.
l:=x
m:=x^2
y:=a*m+b*l+c
y -> solve, x ... ?
The final line can't be solved for x because y didn't involve x, unless it back tracked to get back to the normal quadratic root...

Thus, it was trying to back trace through the geninv, rather than just stopping at its numeric value.

It is one thing that is potentially missing for the engineering solution, that is to be able to 'fix' a variable at its current value, and stop the back tracking when the numeric calculation (approximation) doesn't have a good symbolic solution.

Philip Oakley

[TomGutman]

>>It is one thing that is potentially missing for the engineering solution, that is to be able to 'fix' a variable at its current value<<

It's not missing. It's just been done poorly and confounded with a completely different issue. The assign/display idiom (...:=...=...) will assign the results of the numeric calculation to the symbolic value. There is a bug in that it doesn't work properly with units, but that's a bit different from not having the facility.
__________________
� � � � Tom Gutman

[ptc-1368288]

There is no symbolic issue whatsoever !
Proceed technically:

1. Zap units
2. Generalize in literal form
3. Get a "function solution" if that's what you want
4. Get a "functional valued solution"
5. Assign/define/value the literal terms [not shown]
6. The vector of valued results will issue.
7. Check if units are usable and validate.
8. Install units
6. End: project done



jmG

[TomGutman]

It's not so much a matter of backtracking as a matter of definition. The symbolic processor and the numeric processor are completely different. In general, the symbolic processor does its own evaluations, using its own arithmetic and rules, and ignores the numeric processor completely. Thus the numeric and symbolic values for a variable are often different.

A simple example. x:=2/3. The numeric processor cannot represent 2/3 exactly and so will assign a value that is a close approximation to 2/3. The symbolic processor includes rational arithmetic and can represent 2/3 exactly, and so the symbolic value of x will be exactly 2/3. If you now take 2-3x the symbolic processor guarantees a true zero. The numeric processor only guarantees a very small number. With IEEE arithmetic (2/3)*3 will actually be 2, and so you get zero. But change the denominator to 49, let x=2/49 and you find that 2-49x is not zero but rather a very small number (one that with the default Mathcad settings displays as zero, but is not zero, as can be seen by changing the zero tolerance or by multiplying that number by 100 or so).
__________________
� � � � Tom Gutman

[TomGutman]

You have two problems (that I've found).

First, your matrix h does not have full rank, and so doesn not have a proper generalized inverse. If you try to solve the least squares problem that defines the generalized inverse, you get a singular matrix. The numeric processor either doesn't notice or doesn't care, the symbolic processor is a bit more finicky and tells you that the result is undefined.

Secondly, you are raising a vector to the second power. That is ambiguous as to meaning. It could mean the fot product of the vector with itself, or the matrix product of the transpose of the vector with itself, or an element by element squaring. The numeric processor (somewhat arbitrarily, and not really following normal usage), chooses the implicit vectorization option (element by element squaring). The symbolic processor takes it as a matrix product, and that fails for a non-square matrix. If you mean one of the former two meanings, write it that way. If you mean to vectorize, include explicit vectorization (works in MC14, not before).
__________________
� � � � Tom Gutman

[MoeSzyslak]

On 11/19/2008 6:42:30 PM, Tom_Gutman wrote:
>You have two problems (that
>I've found).
>
>First, your matrix h does not
>have full rank, and so doesn
>not have a proper generalized
>inverse.

Tom -- I agree that the matrix is not full rank and the Moore-Penrose pseudoinverse doesn't work, but geninv(h) seems to. The idea is to determine the best fit line that is forced through the origin. That said, since the numeric processor doesn't complain, it seems to me that M is subsequently equal to 1.5 and the symbolic processor should be able to use that value, regardless of its origin. What am I missing?

>
>Secondly, you are raising a
>vector to the second power.
>That is ambiguous as to
>meaning.

I thought that by using subscripts on either side of the definition that I was explicitly specifying element-by-element operations. The symbolic processor seems to understand this as it gives the correct answer when I replace M with its value (1.5). Again, what am I missing?

Thanks for the help.

Matt

[TomGutman]

For the first issue, see above post. The symbolic processor is quite distinct from the numeric processor. Indeed, when you fix the rank issue (by not adding the extraneous column) the numeric value of M is 1.5 but the symbolic value is 3/2. These are not quite the same thing.

For the second issue, you are right. I got confused by the strange display of the symbolic result and overlooked the array subscript of k. It does work properly.

Although I generally avoid such constructs, iterating the symbolic evaluation with range variables for different values. I would usually do a purely symbolic solution to define a function, and iterate that function through different data values. The symbolic processor is not all that good at numeric evaluations.
__________________
� � � � Tom Gutman

[MoeSzyslak]

Tom, Philip --

Thank you very much for the explanations -- it's much clearer now.

Tom --

Thanks for the worksheet -- much simpler (clearer) than what I was doing.

Matt

[ptc-1368288]

1. Work modular, respecting the Mathcad structure.
2. Avoid subscripts as they add confusion.
3. Collect/isolate ! continue from there.
4. Read the collab and download for learning.
5. Most generally the issue is the user.
6. Zap units first, introduce/define after.


jmG

[ptc-1368288]

Solving needs some equality bolean definition.

jmG