Community Tip - When posting, your subject should be specific and summarize your question. Here are some additional tips on asking a great question. X
Hello,
I just started using MathCAD Prime 3.0 and stumbled upon a problem. I can't find a solution to that online.
I have a question about this screenshot:
Why appending a result to a variable makes the operation impossible (1st and 2nd columns)?
Why showing the value of a variable makes the next operation impossible (1st and 3rd columns)?
Thank you. (I hope this post is in compliance with the policy)
Have a look below at two alternatives.
The summation operator is implicitly looping through the columns of A. When the summation operator is assigned to a variable to have to explicitly tell Mathcad to loop through the columns.
Mike
Bilel,
In your second column, you need to add a matrix index "v" to your variable "V".
In your third column, I'm not sure what the problem is. Perhaps you have an incorrect label assigned to "w". Or perhaps there's something different between your version of Prime and mine (Prime 1.0 on this computer).
Bilel Meziane wrote:
Hello,
I just started using MathCAD Prime 3.0 and stumbled upon a problem. I can't find a solution to that online.
I have a question about this screenshot:
Why appending a result to a variable makes the operation impossible (1st and 2nd columns)?
Why showing the value of a variable makes the next operation impossible (1st and 3rd columns)?
Thank you. (I hope this post is in compliance with the policy)
I've attached a worksheet that hopefully should give you a little more insight into what's going on, but I'll highlight a bit of it here:
Critical point to note: Range Variables are not Vectors!
Ranges and vectors are different data types, as are strings, functions and arrays, and each has it own set of rules.
u and v are range variables; that is, they both hold a range data type that specifies a set of values that Mathcad should generate when it has to evaluate u and v. Think of a range variable as an implied for loop range rather than as a set of actual values. The actual values implied by a range variable don't exist until Mathcad evaluates the range variable and they only exist one at at time during the evaluation.
On the other hand, w (for reasons explained in the worksheet) is a vector. That is, each of its values exists in memory; there is nothing "implied" about the values!
In your first expression, Mathcad evaluates the sum by generating each value of u (0,1 & 2) in turn, evaluating the sum of the corresponding column and then creates a vector from the individual elements. It does not, as it might appear to do, evaluate the whole of the left hand side to create a vector and then display the vector result. You can see this more clearly if you make the sum the argument to the IsArray or IsScalar function.
The second expression raises an error because, if you're going to use a range variable to do assignment, it must occur on the left hand side (lhs) of the definition operator, otherwise Mathcad will not evaluate the range variable. As you don't have u on the lhs of the definition, Mathcad tries to get column u and fails because the column operator needs an integer argument and u's data type is a range not an integer. So you get an error. On the other hand, if you make u an index of V on the lhs, Mathcad will happily iterate over the range, producing 0, 1 and 2 in turn, all of which are valid arguments for the column operator.
The third expression doesn't work because w isn't, despite appearances, a range variable. It is a vector (or, rather, it holds a vector). The reason for this is subtle. It appears as though the evaluation operator (=) gets evaluated before the definition operator (:=). Consequently, Mathcad evaluates "0..2 =" to produce the vector [0 1 2] (see explanation for first expression). It then assigns this vector to w.
This means that the argument to the column operator is a vector,not an integer, so Mathcad raises an error.
Stuart
Nice work as usual Stuart.
StuartBruff wrote:
The third expression doesn't work because w isn't, despite appearances, a range variable. It is a vector (or, rather, it holds a vector). The reason for this is subtle. It appears as though the evaluation operator (=) gets evaluated before the definition operator (:=). Consequently, Mathcad evaluates "0..2 =" to produce the vector [0 1 2] (see explanation for first expression). It then assigns this vector to w.
This means that the argument to the column operator is a vector,not an integer, so Mathcad raises an error.
Stuart
I have regularly used this feature (being the lazy *** I am) to covert a range definitions into a vectors. Interesting to know that you think the un-documented feature works because the evaluation operator has higher precedence than the definition operator.
Mike
Mike Armstrong wrote:
Nice work as usual Stuart.
StuartBruff wrote:
The third expression doesn't work because w isn't, despite appearances, a range variable. It is a vector (or, rather, it holds a vector). The reason for this is subtle. It appears as though the evaluation operator (=) gets evaluated before the definition operator (:=). Consequently, Mathcad evaluates "0..2 =" to produce the vector [0 1 2] (see explanation for first expression). It then assigns this vector to w.
This means that the argument to the column operator is a vector,not an integer, so Mathcad raises an error.
Stuart
I have regularly used this feature (being the lazy *** I am) to covert a range definitions into a vectors. Interesting to know that you think the un-documented feature works because the evaluation operator has higher precedence than the definition operator.
Mike
Thanks, Mike. I first thought this when looking at what happens when you apply the symbolic processor to something that's had inline evaluation done.
I suspect that there is a downside to using inline evaluation, though (apart from having to resize the result table). I wondered if Mathcad would have two copies of the resulting vector, one in the variable and the other as the = result itself. I did a quick experiment in Prime, whilst looking at Task Manager.
I set n:=2, N:=2^n, k:0..N and then generated a vector x by x[k:=k. This gave me a baseline memory size of about 400 MiB. I then changed n to 8, which should have given something in the order of 0.8 GiB (~8 * 10^8 bytes for 64 bit scalars). I got 1200 MiB, which is about right. I then added the "=" evaluation operator and the memory jumped up to 1950 MiB, again about right. I changed n back to 2 and Prime then went beserk for about 5 minutes whilst it tried to do whatever it does under the hood - it looks like memory reclamation is very slow and resource intensive.
I changed tack and, with n still = 2, I defined x:=k. This time I had a baseline memory of about 350 MiB. I then changed n to 8 and, by the time Prime had finished calculating, the memory had jumped to 2780 MiB!
I then dropped my vec function and this jumped to over 2 GiB, then dropped back down to just 1 GiB when it had finished processing.
I repeated the inline evaluation and got inconsistent results. I saw the same leap to over 2 GiB, then Prime kept dropping to 1 GiB, then back up to 2 GiB, and never really seemed to stabilize - plenty of CPU activity shown. I stared at Task Manager for about 5 minutes, then helped my wife debug her bread-making machine, and then went for a 20 minute. Stared at Task Manager for a few minutes. Got bored with this and tried to stop the calculations. Prime wasn't having any of this and hung. I turned down Windows' kind offer to stop the process and decided to wait and see what Prime did. It is still chuntering along as I write ... rapidly climbing from 1200 MiB to 1900 GiB.
Stuart
Very interesting. When I say I regularly use this feature, I should have stated I would only use it when creating a small vectors.
That does not sound promising for Prime (again!!!)
StuartBruff wrote:
I repeated the inline evaluation and got inconsistent results. I saw the same leap to over 2 GiB, then Prime kept dropping to 1 GiB, then back up to 2 GiB, and never really seemed to stabilize - plenty of CPU activity shown. I stared at Task Manager for about 5 minutes, then helped my wife debug her bread-making machine, and then went for a 20 minute.
I hope you managed to fix it
Mike
Mike Armstrong wrote:
Very interesting. When I say I regularly use this feature, I should have stated I would only use it when creating a small vectors.
Hmm. Yes. I forgot to add a note saying that a gibibyte vector was probably a bit extreme by most users' standards. On the other hand, it's probably not too out of order for Big Data analyses and that's where a lot of scientific and engineering calculation is heading, and is definitely falling within the "normal" range for image processing.
That does not sound promising for Prime (again!!!)
StuartBruff wrote:
I repeated the inline evaluation and got inconsistent results. I saw the same leap to over 2 GiB, then Prime kept dropping to 1 GiB, then back up to 2 GiB, and never really seemed to stabilize - plenty of CPU activity shown. I stared at Task Manager for about 5 minutes, then helped my wife debug her bread-making machine, and then went for a 20 minute.
I hope you managed to fix it
Yes, it eventually sorted itself out, but I hope PTC dig into some of these issues, because applications hanging up for 20 mins or more and chewing up resources isn't something that the average user will take kindly to.
Stuart.
Sorry I meant the bread-making machine
Mike
Mike Armstrong wrote:
Sorry I meant the bread-making machine
Mike
Oh yes. Although I would never admit in public to doing this, I read the manual. And, hey presto, pressing the suggested combination of buttons made the problem go away. Unfortunately, my 10-year old son has picked up my bad habits and even reads the manual *before* starting to build something rather than as a last resort debugging tool. I despair for the youth of today ...
Stuart
StuartBruff wrote:
Mike Armstrong wrote:
Sorry I meant the bread-making machine
Mike
Oh yes. Although I would never admit in public to doing this, I read the manual. And, hey presto, pressing the suggested combination of buttons made the problem go away. Unfortunately, my 10-year old son has picked up my bad habits and even reads the manual *before* starting to build something rather than as a last resort debugging tool. I despair for the youth of today ...
Stuart
Ha ha ha - brilliant.
Thank you very much for this detailled answer. I will look at this tomorrow.
This is a very interesting choice as a developper to chose to change the nature of a variable depending on if there is an evaluation made. It is very counter-intuitive but now that I understand it at least I can go further.
Bilel Meziane wrote:
Thank you very much for this detailled answer. I will look at this tomorrow.
This is a very interesting choice as a developper to chose to change the nature of a variable depending on if there is an evaluation made. It is very counter-intuitive but now that I understand it at least I can go further.
I think it was deliberate and meant to get round the problem of transferring numeric results to the symbolic processor, when the generating functions weren't something the symbolic processor could handle. Think of it as a cast to reals (or complex, or strings, etc).
It's kind of the equivalent operation of the symbolic processor's float keyword, which evaluates an expression to give a numerical answer that the numeric processor couldn't evaluate by itself (eg, the Zeta function).
Stuart