The attached worksheet arose out of a need to generate a sequence of alphanumeric strings. There are 3 functions, Str, Concat and concatenate.
Str takes a single argument, which can be a string, scalar or (possibly nested) array, range definition or range variable, and converts all of its elements into a string or string array.
Concat takes a pair of inputs, which can be strings, scalars or (possibly nested) arrays, converts all elements into strings and concatenates them.
concatenate takes a single argument, a list (vector) of strings, scalars or vectors, converts all elements into strings and concatenates them.
In both cases, the arrays must be conformable (ie, have the same shape).
Note the conversion of the range variable in Concat, however!
Stuart
I think this is a good example of where it would be very useful to have a variable number of arguments in a user defined function. Yet another thing that has been on the wish list for a long time 
I hope the optional / arbitrary argument list finds its way off a wish list and onto Prime's development list.
Stuart
Be sure to keep bring the point up then 
I have regularly pushed my ideas and PTC have listened in the past and believe they are again with some features being implemented in Prime 3.0.
Mike
Mike Armstrong wrote:
I hope the optional / arbitrary argument list finds its way off a wish list and onto Prime's development list.
Stuart
Be sure to keep bring the point up then
I'm not a maintenance user so I have no effective input into the development process.
I have regularly pushed my ideas and PTC have listened in the past and believe they are again with some features being implemented in Prime 3.0.
That's good to hear. However, I have repeatedly brought up several ideas over the years and, AFAICT, none of them have had sufficient merit to be included in any development scheme. I'm cool with that, but occasionally a little surprised as I know one or two of the Major League Mathcadders are also in favour of them and have supported them or raised similar ideas ... and they seem to have some backing in rival products. The business of string handling goes back many years ... here's an example from 2007 in which the concept of concatenating strings and numbers is raised:
StuartBruff wrote:
On 9/25/2007 12:26:58 AM, jmG wrote:
== No, not in a table header from the kernel display, in a "dead table header" for publishing.
Here's an example, from real life, of how improved text handling could be of benefit.
I was going through my 6-year old daughter's math homework with her and saw that she was looking at sequences (part of learning her times table). The homework sheet asked the child to make up their own sequence, and, me being me, I introduced her to the Fibonacci sequence.
Naturally, I made her do it the old-fashioned pencil, paper, brain way first, but once she'd got the idea I put together a worksheet to allow her to check her numbers. I've attached the worksheet - as well as a simple sequence generator, I also include a couple examples of tables showing which numbers to add.
One thing that is plain is that the string quote marks are both superfluos and distracting, particularly in the second table.
The second thing, which has always irritated me, is that there is no way to construct a string that has line breaks.
Item three (which we've already gone over in the is thread) is the lack of string formatting. This would have made it easier to highlight numbers.
Following on from three, or part of it, is the inability to change font. It would be more than useful to be able to include greek characters or other mathematical symbols in a string.
Fourthly, Mathcad should be smart enough (as several programming languages are) to auto convert numbers to strings inside a concat function. This would make it simpler to write and easier to read. In fact, it would be worth considering just how smart Mathcad could be in this respect and whether it would make sense to treat 'addition' of strings and numbers to as an implicit string concatenation operation.
I know there was at least one subthread covering string formatting but I can't find it. However, it does get a mention in this one:
StuartBruff wrote:
On 6/7/2008 12:36:16 PM, jmG wrote:
>> On 6/7/2008 10:17:30 AM, stuartafbruff wrote:
>> In what ways is it simpler to address a pre-formatted array?
== It results from the simplest and logical way of doing, it is a question of purely addressing something somewhere. No Mathcad knowledge is needed, simpler.
Jean,
First of all, I think you'd better sit down, pour yourself a stiff drink and borrow some oxygen ...
I was thinking about this driving to ballet (my daughter, not me - even Quentin Tarantino would draw the line at portraying me doing ballet!) and I've changed my mind. Given that you've pre-calculated the data values, what you suggest is a perfectly reasonable way of doing things in a Mathcad environment.(I still think you need to have the transpose, as the normal way of handling lists in Mathcad is as vectors.)
I have three basic modes of thinking about how to use Mathcad. One is as a whiteboard, the other is a working tool at discipline level and the third is as a presentation tool (eg, papers for publication).
I started off with the whiteboard mode and a perhaps inexperienced but intelligent, user (eg, the Prof) drafting something up before a few people. So, they'd create the equations then, if it suited their purpose, draw up a table and (this is where I like to visualize an active whiteboard) drag the results into the table in the right spot.
The major difference between Mathcad and most (if not all) of its class of products is that the 'output' often serves as the 'input'. In this case, the displayed array is a case in point.
Stuart
It also gives a good example of why Steen and I (amongst others) would like to have improved string handling and the ability to hide the left hand argument in an evaluation.
The quotes get in the way of the display and it would be nice to be able to format the text
(back to the Prof at the whiteboard: "What do you mean, I've got to put the text in quotes? Why? Surely the software can work out what's what? Oh, and I can't underline the text either? Sheesh!" ... a few minutes later "Sorry, are you trying to tell me I can't write a Bessel function as Jν(x)? Why on earth not?")
I know you can hide symbolic arguments in M14, but invoking the symbolic processor slows things down and may give different results to the numeric processor. Furthermore, AFAICT, symbolic hiding doesn't compress the region leftwards, and this should be a key feature of the hide capability (eg, in text you would write "The number of frogs was |nfrogs=|.", where |..| indicates an embedded math region. What I would expect when I 'hid' the left hand side is that it would collapse the expression to give, say, "The number of frogs was 9." rather than "The number of frogs was |nfrogs=9|." (without the quotes of course!))
Stuart
