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
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.
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 😉
