My string library defines three different representations of a string, two of which should already be familar: the string and the vector of character codes. The third type is the vector of characters.
In the following, "str" indicates a string, "vec" indicates a vector of character codes, and "chr" represents a vector of characters. For example, chr2str indicates a conversion from a string to a vector of characters.
chr2str itself is relatively quick, even for long strings. chr2str0 has the limitation of hitting Mathcad's recursion depth limit. chr2str2's use of folding over concat, however, is proving somewhat slow once the string length increases to above about 20,000.
The challenge is to define a faster recursive variant of chr2str.
Where the dependencies are as shown below (except the timer functions, which are in an Area at the top of the attached Mathcad Express 11 worksheet).
Stuart
Why are you unhappy with your chr2str function? Its fast and does not suffer from the silly recursion limit.
You may speed up chr2str2 a little bit by replacing the call to chr2str2 by the fold command directly. But speed in no way comes near that of chr2str.
Furthermore chr2str0 and chr2str2 not only are slower, they suffer from another drawback as well:
@Werner_E wrote:
Why are you unhappy with your chr2str function? Its fast and does not suffer from the silly recursion limit.
You may speed up chr2str2 a little bit by replacing the call to chr2str2 by the fold command directly. But speed in no way comes near that of chr2str.
Furthermore chr2str0 and chr2str2 not only are slower, they suffer from another drawback as well:
I'm not unhappy with chr2str, it's the performance of chr2str2 that leaves me feeling unfulfilled.
And that slowness is why the specific challenge. Is there a way of improving the performance of the recursive algorithm? Might the underlying reason for any improvement be more generally applicable? Even a small improvement might take a function's performance from annoying to bearable.
It can also be surprising just what a difference an apparently small change can make to a function's performance. For example, the marked increase in speed by using update1 rather than stack in my vec function (as mentioned in another thread and as shown below).
Even some of the matrix summation functions surprised me with how quick they were - look at matsum.sigrow and matsum.onesmat below, especially the latter when compared to the other Sigma operator (S) variants.
Summation Function Timings:
Summation Function Definitions:
Auxiliary Function Definitions:
Stuart
Mathcad Prime (Express) 11 worksheet attached.
