Re: Mathcad Prime 3.1 symbolic challenge
Re: Mathcad Prime 3.1 symbolic challenge
Re: Mathcad Prime 3.1 symbolic challenge
Yes, showing P1 and P2 also is my goal. (the actual equations are far more complicated and I desire to have this visual check included for every equation.) But with some tinkering I think I've found my solution that is more compact version of what you came up with. (but essentially the same thing)
It seems odd (almost wrong) to be redefining P1 but it seems to work and is quite compact. I can live with this, so I think it's solved. Thanks. Now if they'd only let me control the number of decimal places in the symbolics....
Re: Expression is to large to be calculated
Find attached a .pdf of the worksheet and a native .mcdx for prime 3.1.
Re: Mathcad Prime 3.1 symbolic challenge
> It seems odd (almost wrong) to be redefining P1 but it seems to work
Its not the redefinitions which does the trick, its the numeric evaluation at the end which assign this numeric value to the variable at the left hand side and therefore the symbolics has no way to determine how this value was created.
> Now if they'd only let me control the number of decimal places in the symbolics....
There is the keyword "float" which controls the number of significant digits in symbolic calculations (not the number of decimals). The big drawback is, that "float" does not only affect the display of the results but it affects the whole calculation. So normally the advice is to avoid the use of "float". But in your case it might be useful and do no harm, if you simply show a result using explicit. This means you would have to avoid your nice P1:=P1 --explicit,ALL, float,6--> ... and must use the two expressions
P1:=P1 and then P1 --explicit,ALL, float,6--> ...
Its a pity we cannot hide the keywords and let the arrow look like a normal equal sign, as we can do in Mathcad (15 and below). It would look much nicer that way.
WE
All Evaluations Result in Either...
I am having slight difficulty graphing this Mathcad problem. When I try, it sends me an error along the lines of "all evaluations either resulted in a complex number or error." The problem is trying to plot the concentration versus position of diffusion/flux through a thin layer membrane. I have to turn it in by tonight, so I would love any help!!
Thank you!
Re: All Evaluations Result in Either...
You have two more undefined functions CB1(x), and CBL.(x)
And you're trying to solve for CB(x).
Need to define the functions you're not solving for.
Re: All Evaluations Result in Either...
Thank you for your response! I am not sure how to define them because they are my boundary conditions?
Re: All Evaluations Result in Either...
One problem is that odesolve returns a function name, so on the LHS you need CB, not CB(x). CB is the function you then plot. Also, however, you have two undefined functions: CB1(x) and CBL(x). what are they supposed to be?
Re: All Evaluations Result in Either...
Ok, now I understand the LHS part. The two functions are the boundary conditions of the system. The surface concentration is denoted by CB1 while CBL is supposed to the concentration at a point (L distance) away from the starting point (CB1). I am not sure how to define these two functions. If you are willing, I would really appreciate help through a Mathcad file... even if it is not how my problem is set up, I think it would be helpful for me to see something similar.
Re: All Evaluations Result in Either...
Re: All Evaluations Result in Either...
Re: All Evaluations Result in Either...
Thank you all for your help! Got it figured out!!
Re: All Evaluations Result in Either...
Re: All Evaluations Result in Either...
Vectorize rows and cols; a bug?
Re: Vectorize rows and cols; a bug?
Honestly what you show is exactly what I would have expected. And I would have expected that vectorising last(V) throws an error as last(2)= would do.
Vectorising looks at all vectors in the expression and feeds the vector elements in the calculation. The results are collected in a new result vector.
So vectorising rows(V) first takes the 1 and feeds in the calculation -> rows(1) gives 0 as result and this result is the first element of the result vector. Same for 2 and 3 which gives us exactly the result vector we see.
On may argue that rows(3) or cols(2) should throw an error (like last(2) does) because the arguments are scalars and not vectors. But we used this behavior of Mathcad to see a scalar as a 0 x 0 matrix often to our advantage, when we used something like V[rows(V) <-- .... in our programs.
Re: Vectorize rows and cols; a bug?
I disagree,
Its vectorizing rows and cols that give what you'd expect.
V has 3 rows, 1 column. But when vectorizing the 'rows(V)' statement you're actually asking: apply the rows() function to each of the elements of its argument, so to the scalars 1, 2 and 3 in turn. That gives the vector that says: 1 has 0 rows, 2 has 0 rows and 3 too.
Perfectly logical.
At first vectorizing last(V) surprised me, until I saw that vectorizing a scalar results in that scalar.
The error message for both array multiplications is "The number of rows and/or columns in these arrays do not match", which is understandable.
Luc
Re: Vectorize rows and cols; a bug?
I guess you are both right. It p****d me off, because I had a rows(V) buried in a vectorized expression, which failed to work correctly because it didn't return a scalar with the number of rows in the vector. It took me a while to figure out what the problem was, and then I couldn't find a workaround that I really liked (in the end, I turned it into a two line program). So it sure felt like a bug at the time, even if it wasn't one