cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Need help navigating or using the PTC Community? Contact the community team. X

Assignment breaks solve (Mathcad 15.0)

MichalPribil
4-Participant

Assignment breaks solve (Mathcad 15.0)

I repeatedly encounter the following problem: When I use 'solve' to solve an equation or a system of equations, it works fine as long as I don't try to assign the result (see minimal example below and in the attachment), which is quite essential. It just starts to complain with 'This variable is undefined' but does not even mark any single variable.

 

- swapping the working and not working solve around does not change anything

- giving the output variables different names does not help

 

MichalPribil_0-1596629238783.png

 

P.S.: This must have been answered somewhere. I did find some similar posts but none helped me.

1 ACCEPTED SOLUTION

Accepted Solutions

This is a fairly known effect and the symbolic still works OK. [EDIT: No, it doesn't. Look at the auxiliary variables X58 and E1491 which show up and cause the numeric error message]

Its simply the numeric engine throwing the error because of the assignment to variables.

The variables get a [EDIT: unusable] symbolic result anyway and you may display and use them after the calculation as desired.

Werner_E_2-1596633370069.png

 

 

A strange side effect is that if you move the region with your mouse (left mouse button pressed down) the symbolic result is shown (but only until you recalculate the sheet).

Werner_E_0-1596633077595.png

 

P.S.: When showing picture belonging to a question about symbolic evaluation its better not to show the evaluation as equal sign as it might be confused with numeric evaluation.

 

BTW, you wrote "it works fine as long as I don't try to assign the result". Did you really expected variables X1, E13 or X58 and E1491 in the result? 🙂

Mathcads symbolic engine unfortunately does not know anything about units and so A and V are treated as unknown variables (which may be negative or even not real). So given those unknowns, the expression seems to hard for muPad to solve and it shows some auxiliary variables in the result. I don't know what exactly is happening here but it seems to be caused by the conflict between forced to float mode (because of the float numbers provided) and the aim to solve as exact as possible using the ln. As Alan shows muPad sure is capable to solve the equation with variables only (no numeric values provided) and you showed in your second post that muPad is able to solve the equation if only numeric values are provided (even the Euler number).

 

As you are just looking for a numeric result, why not just use a numeric method like a solve block?

Werner_E_0-1596634229685.png

 

 

 

View solution in original post

10 REPLIES 10

Ok, more weird stuff is coming:

when I replace 'e' with the value of e, suddenly the solve with assignment works (and also the other result provides a human-readable form, but that's probably just a side effect). 

I placed a print for 'e' in there as a proof that it is defined correctly.

MichalPribil_0-1596631321097.png

 


@MichalPribil wrote:

Ok, more weird stuff is coming:

when I replace 'e' with the value of e, suddenly the solve with assignment works (and also the other result provides a human-readable form, but that's probably just a side effect). 

I placed a print for 'e' in there as a proof that it is defined correctly.

MichalPribil_0-1596631321097.png

 


Thats indeed strange. Obviously muPad tries to solve exact (and fails) using ln if you use the built in constant e but switches to float mode from start when a numeric approximation of e is used.

Nonetheless I'd vote for using a solve block as shown in my first answer (which is shown below(!)).

MichalPribil
4-Participant
(To:Werner_E)

I'm getting this problem inconsistently also with the solve block.

 

However, I can use e when I redefine it, it's probably not what should be done, but it is a solution for me:

MichalPribil_0-1596639600052.png

 

This is a fairly known effect and the symbolic still works OK. [EDIT: No, it doesn't. Look at the auxiliary variables X58 and E1491 which show up and cause the numeric error message]

Its simply the numeric engine throwing the error because of the assignment to variables.

The variables get a [EDIT: unusable] symbolic result anyway and you may display and use them after the calculation as desired.

Werner_E_2-1596633370069.png

 

 

A strange side effect is that if you move the region with your mouse (left mouse button pressed down) the symbolic result is shown (but only until you recalculate the sheet).

Werner_E_0-1596633077595.png

 

P.S.: When showing picture belonging to a question about symbolic evaluation its better not to show the evaluation as equal sign as it might be confused with numeric evaluation.

 

BTW, you wrote "it works fine as long as I don't try to assign the result". Did you really expected variables X1, E13 or X58 and E1491 in the result? 🙂

Mathcads symbolic engine unfortunately does not know anything about units and so A and V are treated as unknown variables (which may be negative or even not real). So given those unknowns, the expression seems to hard for muPad to solve and it shows some auxiliary variables in the result. I don't know what exactly is happening here but it seems to be caused by the conflict between forced to float mode (because of the float numbers provided) and the aim to solve as exact as possible using the ln. As Alan shows muPad sure is capable to solve the equation with variables only (no numeric values provided) and you showed in your second post that muPad is able to solve the equation if only numeric values are provided (even the Euler number).

 

As you are just looking for a numeric result, why not just use a numeric method like a solve block?

Werner_E_0-1596634229685.png

 

 

 

MichalPribil
4-Participant
(To:Werner_E)

"Did you really expected variables X1, E13 or X58 and E1491 in the result?"

I naively thought that if I manage to get it assigned to a variable and print the variable out, those variables would just magically get some desirable value.

 

I agree that solve block is probably the best way for me to do my calculations. I learned about it just recently and I would have been using if I knew it existed.

 

Thank you very much once again for your fast response!


@MichalPribil wrote:

"Did you really expected variables X1, E13 or X58 and E1491 in the result?"

I naively thought that if I manage to get it assigned to a variable and print the variable out, those variables would just magically get some desirable value.

 

I agree that solve block is probably the best way for me to do my calculations. I learned about it just recently and I would have been using if I knew it existed.

 

Thank you very much once again for your fast response!


At first glance I didn't notice those silly auxiliary variables which were thrown out by the symbolics (so I edited my first answer slightly to draw attention to it). Its really very strange that the mixture of float variables and "exact" Euler number messes up the symbolic calculation so much.

 

Looks better to me if you do it this way:

g0.jpg

Alan

Or like this if you want to keep the Ks as functions:

g1.jpg

 

Alan

I would do so:

answer to MichalPribil.jpg

Werner_E
24-Ruby V
(To:-MFra-)

Thats similiar to Alan's approach (he turned the calc into a function for later use).

Its interesting that the symbolic is able to solve with all variables and also with all numeric values (even Euler number). But it does not work OK with numeric values for most variables but the "exact" Euler number.

 

Its interesting that is suffices to make any one of the two voltages variable for the symbolics to get a reasonable result:

Werner_E_0-1596639932569.png

As soon as we delete the assignment V.2 := V.2 the symbolic solve comes up with its auxiliary variables X... and E... which the numerics don't known and therefore throws the error. Its somewhat strange.

 

 

Top Tags