Let me tell you a story. Once upon a time, perhaps even 10 minutes ago, when writing a new function (Bidiagonal) and testing it with strings, I replaced a direct function call argument with a predefined vector but forgot to remove the original function's argument. After a few seconds of gazing at the (correct) output from Bidiagonal, I realised that the notation V(3) for vector V should have raised an error, but it didn't.
After a bit of playing with a new, blank worksheet, I confirmed that to get an array's elements, one can use the standard subscripted index notation Mi,j or the standard programming language parenthesis notation M(i,j). And Little Red Riding Hood and Peter campaigned for a better public understanding of wolves, their role in ecology, and their treatment.
I have a vague, dusty, indistinct memory of coming across this notation before, perhaps even on this forum, but I'm not sure - it might be a case of déjà vu.
Stuart
ACCEPTED SOLUTION
Accepted Solutions
It is one of the two supported means to index an Array in Prime.
And it is confusing.
And it takes up more space.
And you cannot use this notation to access elements of nested arrays.
So I never use it
Luc
It is one of the two supported means to index an Array in Prime.
And it is confusing.
And it takes up more space.
And you cannot use this notation to access elements of nested arrays.
So I never use it
Luc
Yes, I agree, Luc.
I had a quick play with nested arrays but couldn't find a way of indexing them by extension of this notation. I was rather hoping I'd be able to do something useful, such as P(1,1,1,1) to get at an element - that would make using nested arrays more straightforward and be the basis for a proper multidimensional array (MDA) system ... I may have mentioned/requested MDAs on the odd occasion.
Do you know if this notation is documented as well as supported?
Stuart
Here is another difference - guess you did not try to change the value of ORIGIN.
The functional notation is ignoring the setting of ORIGIN - similar to the third argument (generating function) in the "matrix" function.
I can confirm that this 'feature' has existed since Prime's inception and I've railed against it a time or two here for a couple of reasons.
However, I haven't come across any official documentation on it, so I couldn't say that it's officially supported by PTC. It's also possible that it just happened unintentionally.
In my opinion, it would have made more sense to eliminate this 'feature'. Just as the undocumented ability to quickly and easily convert ranges to vectors was eliminated in Prime 10, but unfortunately without providing a (more logical and intuitive) alternative.
Your 
Whilst PTC are fixing this indexing feature, it would be nice if they'd give some consideration to fixing two particular bug bears I have with the normal indexing notation.
- Cannot use deep nested array indexing on left hand side of a definition, although it works in an assignment.
- Programmatically and visually, nested indexing, whilst unambiguous, isn't flexible enough to cater for irregularly shaped nested arrays. The ability to use a single level indexing would make it easier to see the indices and to handle deep arrays.
ISTR that you couldn't use nested indexing in an assignment, either. Did M15 or early versions of Prime allow it?
Stuart
@StuartBruff wrote:
Interesting.
What do you get if you use P0,0,1,1,1 inside your Q program? I presume it also ignores the extra indices,
Correct. MC15 ignores everything after the first two indices, not even checking if the variable used is defined or would be valid integer.
Prime telling you it won't have anything to do with more than two indices is better than quietly ignoring them.
Agreed on, yes.
And sometimes I even wished that Mathcad/Prime would throw an error instead of silently applying implicit vectorization.
This is especially true if I modify a function which formerly did not use any calculations valid for vectors in a way that the results now are different whether vectorization is explicitly applied or not and me not realizing that firsthand. That way I learned that its better to apply explicit vectorization every time you want it to be done and don't rely on implicit vectorization. That's also the reason I prefer to put the vectorization when I call a function and not in the function definition itself - just to remind myself whats going on and of course at the cost of uglier display and unnecessary increase in global warming.
@Werner_E wrote:
@StuartBruff wrote:
Interesting.
What do you get if you use P0,0,1,1,1 inside your Q program? I presume it also ignores the extra indices,
Correct. MC15 ignores everything after the first two indices, not even checking if the variable used is defined or would be valid integer.
A good guess on my part, then. Perhaps I should get a crystal ball and enter the world of sorcery and prognostication. Who knows, maybe become the new urYod. 😃.
I'm having difficulty focussing on reality at the moment as the wind has been gusting quite nicely ... It blew open a window that was latched very slightly open and the house has been shaking and making noises seldom heard outside of a large galleon about to break up in a rough sea. That means I'm paying more attention to the weather than the seven Mathcad worksheets I'm currently working on.
@Werner_E wrote:
And sometimes I even wished that Mathcad/Prime would throw an error instead of silently applying implicit vectorization.This is especially true if I modify a function which formerly did not use any calculations valid for vectors in a way that the results now are different whether vectorization is explicitly applied or not and me not realizing that firsthand. That way I learned that its better to apply explicit vectorization every time you want it to be done and don't rely on implicit vectorization. That's also the reason I prefer to put the vectorization when I call a function and not in the function definition itself - just to remind myself whats going on and of course at the cost of uglier display and unnecessary increase in global warming.
I'm afraid I find implicit vectorization to be more helpful. Explicit vectorization requires a bit of thought as there may well be array arguments that shouldn't be vectorized when calling them or are of different sizes to the main object of the vectorization. This requires me to think about and implement the same process each time I use explicit vectorization - but thinking makes my brain hurt, and thinking just the once is bad enough.
For example, I often use implicit vectorization to allow a notionally non-array argument to be overloaded with an array as well. By transferring the vectorization to a function, I have more and consistent control over what gets vectorized and how.
Great care with vectorization, one must take. Things nicely to do, always possible it is not. Which is why a map function, sometimes I use. Or even (gasp!) to ugly explicit iteration, resort I do.
@Werner_E wrote:and of course at the cost of uglier display and unnecessary increase in global warming.
Greenpeace has acquired your name, young Master Werner. Don't ask me how or who told them ... hordes of indefatigable volunteers are furiously painting banners as I type. 😈
Stuart
Mathcad 11:
Errors:
- The expression to the left cannot be defined.
- This array has too many subscripts.
- This array has too many subscripts.
Incidentally, it is possible in Prime to (re-)assign an element of a nested array:
You can even create new elements:
Mind that, like the 'function' notation of indexing, the update1 and update2 functions use ORIGIN=0 irrespective of the value of ORIGIN.
Success!
Luc
Ah yes, thank you, I had completely forgotten about these undocumented functions. So now it's up to us to decide which way of writing seems more appealing and intuitive and whether we are prepared to use undocumented functions ...
It seems only to be mandatory that in he program the global variable N is used on the right hand side of any assignment before we can use it in the desired way.
I dimly remember that we had something similar here some time ago, but I have no idea what it was all about. 😞
Here is a tense one-liner
and, no, I won't call it appealing and/or intuitive 😉
@Werner_E wrote:
Here is a tense one-liner
and, no, I won't call it appealing and/or intuitive 😉
That's so ... specific. 😱 Instinct forced me to generalize it as a function. But both you and Greenpeace will be delighted to see I didn't implicitly vectorize the function. 😊
Life would be so much easier with a decent Sequence data type.
Stuart
