Community Tip - You can change your system assigned username to something more personal in your community settings. X
PRIME 6
Weird bug. I want to create a new matrix where the new second column is a list of integers giving the row index,
If the original vector of values contains units then the second column is always set to 1.
if i non-dimensionalize i get the expected result but it is of no use as i have lost the units.
I can verify this indeed strange bug (also using Prime 6)
But why do you think that your "case 3" is incorrect?
I added a "case 4" which looks OK to me, too.
You can also see, that defining f as a function on worksheet level produces the same faulty result as the local definition.
agree case 3 is correct but i want CASE 1 to work.
@tslewis wrote:
agree case 3 is correct but i want CASE 1 to work.
Then you may use the workaround shown below by replacing "r" by "r*1".
AHha, weird, yes this seems to explcitly assign r as in integer. Any reason for this weird behavior? Thanks Werner
CASE 6 works
@tslewis wrote:
AHha, weird, yes this seems to explcitly assign r as in integer. Any reason for this weird behavior? Thanks Werner
No, I have no idea how this bug would occur.
Its definitely a bug introduced with Prime as real Mathcad would not allow for mixed dimensions in an array.
When the bug occurs r seems to be replaced by the last value in the loop (which internally is used). Using a math expression like "times 1" seems to force the program to use the current loop value as it should.
But why this happens only when the return value in the "yes" branch has a unit - no idea.
@StuartBruff wrote:
I can't remember the details, but I have a feeling that this is an old bug and may have been reported to PTC some time ago.
I can't remember but unfortunately that doesn't mean anything when said by me.
The only bug concerning the "matrix" function I can remember is, thats it not ORIGIN-aware. This was reported way back in the times of real Mathcad and also for Prime. The bug got never fixed:
@Werner_E wrote:
@StuartBruff wrote:
I can't remember the details, but I have a feeling that this is an old bug and may have been reported to PTC some time ago.I can't remember but unfortunately that doesn't mean anything when said by me.
The only bug concerning the "matrix" function I can remember is, thats it not ORIGIN-aware. This was reported way back in the times of real Mathcad and also for Prime. The bug got never fixed:
As I almost always use ORIGIN = 0, I don't recall noticing that one.
The thing that struck me as familiar about this thread's case is multiplying a variable by 1 seemed to cure the problem.
Stuart
I'll bet 10-1 that I'd win in a bad memory competition ... 😈
In Mathcad 11 that was not a bug, according to the online help:
Explicitly uses rows (i) and columns (j) starting at 0, irrespective of ORIGIN. It's necessary that way, otherwise users need to change their function (f) depending on ORIGIN. This way it forces the users to adjust their usage of the matrix() function explicitly. Note that you can set ORIGIN to -10 if you like.
Observe that string indexing also starts at 0, irrespective of ORIGIN.
Luc
In prime in the calculation options you can set the string index to start at same position as ORIGIN. I stay with default for string processing
@tslewis wrote:
In prime in the calculation options you can set the string index to start at same position as ORIGIN. I stay with default for string processing
The same is available in MC15 and below:
In Mathcad 15, maybe in 14, 13, and 12, but not in Mathcad 11.
But Mathcad 11 has other goodies.
Luc
@Werner_E wrote:
@tslewis wrote:
In prime in the calculation options you can set the string index to start at same position as ORIGIN. I stay with default for string processing
The same is available in MC15 and below:
OK, according to Lucs answer - not too much below.
And yes, I wish we could have the symbolic engine of MC11 (Maple) available in MC15.
Did some further investigations.
The problem is not the matrix A itself and the problem is not the function f itself.
The bug seems to be how the "matrix" command evaluates the function f internally.
There is a funny fix/workaround - simply turn the single "r" into a math expression. The pic shows two examples of how it can be done by adding a zero or multiplying by one. Obviously thats the reason why it also work when we apply a unit to "r".
Here is a last one
The bug also occurs when the "if"-function is used instead of the programming if instruction
I use the matric function a lot as it simplifies my programming constructs. I find it very powerful.
Here is one work around but im concerned now that my use of this matrix approach in my library of programs is going to fall apart in some instance. I often have matrices that have mixed units. I dont want to have to explicitly non dimensionalize and then re dimensionalize to get it to work - CASE 5
Werner seemed to solve it and i can keep my same clean approach Multiply the r value by 1 seems to force Mathcad to see this value as an integer, weird, still seems to be a BUG
Its sure a bug.
Other workaround are using the augment function (if possible in your real sheet)
or to use a custom written "matrix" function. Something along the lines of
Thanks but I use the in built matrix function a lot as it is convenient and not expensive at all when it comes to matrix processing speed
steve