Yes, it is beneficial in some respects. It's certainly quicker than all the other range-to-vector conversion methods proposed over the years, and the optional arguments are useful too. I've also used the new vec function to speed up and simplify a few of my standard library sequence generation functions.
However, .... (there just had to be a 'however')
PTC published Mathcad Support Article CS416474 to address the change in Mathcad Prime 10 regarding how concurrent evaluation of range variable definitions was handled. In CS416474, PTC introduced the function Range2Vec as a suggested workaround for the change in Prime 10 behaviour.
This is where vec is potentially a bug as Range2Vec converts a flat matrix into a vector (in accordance with standard mathematical use). vec , however, only converts a range into a vector or acts as an identity for a vector. It does not convert even flat matrices into vectors, let alone nested ones. Again, whilst I see benefits to Prime's vec , I am disappointed that PTC took no apparent notice of the definitions of vec that have been in use for at least the last twenty years.
(In the screen shots below, M is a flat matrix and N is a nested array (one element is a matrix)).
Stuart
Sorry about that. I sometimes forget whether I'm supposed to be speaking maths, programming language, or Mathcad.
A matrix, mathematically, is an m x n array of numbers. In Mathcad, vectors and matrices are data structures that can contain numbers, expressions, strings, nested matrices, and units.
So when I said "flat matrix", I was thinking "Mathcad" and referring to an m x n array of non-array data types; that is, an unnested array. I suppose I should have said "flat array".
_________________
Even a quick hack should require a lot of procedure to get through (eg, specification writing, specification review, design, coding, testing, review, ...). PTC must have put some thought into it, because the optional arguments are quite a neat and very Mathcad idea.
Going the extra micromile to realise a fully flattening vec can't have demanded that much more effort; the plethora of vec implementations shows that it can't be that hard to implement. For want of a nail, and all that (Diz sagent uns die wîsen, ein nagel behalt ein îsen, ein îsen ein ros, ein ros ein man, ein man ein burc, der strîten kan - it's not often one gets to use Mittelhochdeutsch in a Mathcad Community post!).
,
A(nother) long-standing annoyance of mine is the poor support for strings, including the inability to specify character sequences as ranges, eg. "a".."e" or "0".."9". Over the millenia, I've implemented various ad hoc (wow, Latin now! Отличный!) functions to fulfil this need, some of which use a vec variant.
MP11's vec has a further limitation in that it vectorizing (in the Mathcad sense) over vec over a vector just returns the original vector, whereas most vec implementations return a vector whose elements are the elements of the original vector converted into 1-arrays. Again, Range2Vec supports this latter behaviour.
Here's a demonstration of what I mean ...
Such a shame, as it's good that vec is there, I like the optional argument form, and I'm very pleased to see IsRange.
Stuart
