I was just playing around with the function format to see if I could create a readable, compact form that displays the values of variables in an expression. To do this, I wanted to use the Unicode character point 10 or 13 to generate a newline. This worked in Prime 10, and I'd previously used it to create string justification functions, such as:
Mathcad Prime 11 has broken this behaviour. I now get:
Why did PTC do this? Is it a bug that got introduced, or was it deliberate? If the latter, what benefits accrue to the user that outweigh the loss of functionality?
I've been requesting more sophisticated strings since before Mathcad Prime was developed and throughout its entire existence—for example, HTML or RTF. Taking even such a limited capability away is irritating in extremis.
Stuart
For the record, here's an example of the use of CR and/or LF that I posted almost 4 years ago (Prime 7, I think), so it's been in use for several versions of Prime and documented as having been used:
Here's a herd of Prime Milchkühe in 10.0.1.0 ...
And here's the same herd after being hit Cowvid Prime 11:
Prime 7..10
Prime 11:
I feel somewhat like Emperor Joseph II in Amadeus when watching ballet without music.
Let's give Dr Buttercup Banner the last word ..,
Stuart
Somewhere in PTC Central, the minion in charge of Excluding Bruff's Beneficial Features is being summoned as we speak. After a formal shaming, they will be ceremoniously dragged by wild tortoises to a place of execution, where they will commit ritual seppuku with a blunt parenthesis. Their crime? They let a Useful Feature slip through the net!
Stuart
Works like a charm, also in previous Prime versions.
However, Mathcad will allow only codes up to 255, and produces an ellipsis "..." at the lower of the three:
Luc
You never give up, do you? 😄
I was wondering if there were any differences between NEL (where I live, 133 is the police emergency number), LS, and PS, so I experimented a little.
It looks like all three are unsuitable if you want to write data to a file—at least with WRITEPRN (I haven't tried any others).
It's also confusing that strings containing NEL cannot be copied; attempting to do so only creates an empty region.
Here's what I did:
Prime 11 file attached
And another instance (worked in Prime 7, IIRC😞
Mathcad Prime 10:
Mathcad Prime 11:
Stuart
(Also) for the record: This is what Mathcad 11 gives:
We've been requesting since Prime1 that the functionality of (real) Mathcad would be supported by Prime.
Guess this is what you get...
Luc
Inderdaad, Luc.
I feel like I am the first half of St John's statement in John 1:23, "De stem van een die roept in de woestijn"
I understand that different people will have different ideas about what Mathcad is and should be, but I'm not convinced that breaking existing capability to meet a/several user needs is the best way to go. I really don't understand why the CR/LF string line breaking was removed and what benefits we accrue from its removal.
And further for the record:
vs (your)
Stuart
It appears that I reported the existence of this Prime feature back in 2015.
Well, I had expressed the hope that it was a feature, not a bug, to be removed. It only took 10 years, but I guess I have my answer. 😢
Stuart
I remember that years back I tried to use these characters in real Mathcad and it failed.
I seem to have missed your post 10 years ago and also the fact that some of them worked in Prime up to version 10.
Just gave it a try and noticed that BS(8) and BEL(7) don't work in Prime10 either, here vec2str already throws an error as of invalid character.
So Luc is correct when he notes that the behaviour in Prime 11 is identical to the behaviour in old Mathcad when it comes to displaying strings.
I could understand that Prime 10 removed the option of converting a range into a vector through simple inline evaluation, since evaluation should not cause any changes to the variables, especially not their data type.
But I can't think of a reasonable reason for removing the option to display CR, LF when evaluating strings. Its sure not something I would use every day but something which could be handy occasionally. I don't see any added value in disabling this 'feature'.
It's only about the display during evaluation—the special characters are still present in the string, as an evaluation of str2vec shows.
TAB seems still be allowed to display
I imagine one of two scenarios existed:
1. Somebody saw I was using the feature and invoked the Bruff Exclusion Rule, whereby anything I find useful or want is excluded at the earliest opportunity.
2. Somebody, a user, got confused. So the feature was removed rather than, say, suggesting that they apply a filter to their string to remove any characters they didn't like. (The latter would have been the better option, as people who do use the feature cannot apply a filter to restore the capability (but see Scenario 1)).
This has been the default go-to scenario since Mathsoft ran the show. Tom Gutman introduced me to the term "Nannyware" to describe such an approach. There was one particular Mathsoft change that had me gibbering and hooting like a demented chimp on a flinging spree - I wish I could remember what it was (well, OK, there have been multiple changes that have induced that behaviour in me, the current subject being another one).
The fact that Tab (09) functionality still exists suggests that a third scenario, fixed in a general clean-up, probably didn't happen.
For control codes that don't have a reasonable interpretation under a virtual document rendition, there are always the Unicode symbols:
A far more sensible approach, IMO, but what would I know?
Stuart
... Ah, yes. A user complained that Mathcad crashed when running a recursive function that had no termination condition. So, instead of fixing the problem, Mathsoft added a recursion depth limit of around 4000, on the basis that who would ever want a recursion depth of more than that? I mean, that would be silly. Naturally, as one who regularly exceeded that depth, I whined like a whiny thing that had a special reason to whine (and I did have one). The response? Apparently, I could play with the Registry and set my own limit.
Again, I howled, pleaded, and wheedled to get a proper fix, using the pathetic excuse that setting Registry values wasn't exactly portable and many organisations forbade users (or anyone!) from playing with the Registry upon pain of termination; for monsters could be summoned if the mages cast an improper spell upon the Registry. Would it not be better, I urged, to fix the problem by at least keeping an eye on the stack, and educating users on the need to write correct recursive programs?
Last I looked, the recursion depth limit was still there. Yep, still there at 4766. A very annoying limit (especially for those who use Express, which isn't exactly a selling point).
Heck, we haven't even got mutual recursion as a consolation prize.
Still, somebody must have noticed that I did actually use the Registry fix for recursion depth - see Scenario 1; if it's still in the Registry, I can't find it.
@Werner_E wrote:
According registry hacks I never was aware of them - at least not for MC14/15.
I know that there is a registry hack to enable MC11 display larger symbolic results which does not work in MC15, let alone Prime.
I am not aware of any registry fix concerning recursion depth - actually I wasn't even aware of the silly limit.
I have long since forgotten which version of Mathcad introduced the Registry fix for the recursion depth. And all the correspondence would likely have been on the old Collaboratory, which is now consigned to the dustbin of history.
However, if you hang on for a few minutes ...
Right. I had a few email exchanges with Mathsoft back in 2006 re recursion. Of particular note are:
An official Bug Rep:
Subject: RE: - Recursion depth too limited
Problem Description:
Recursion depth is limited to 1000. This is too small for several classes of problems involving recursion (ie, in number theory)
Subject: RE: - Recursion depth too limited
Hi Stuart,Sorry to be so long getting back to this. It’s been a zoo lately.
If you want to increase the maximum stack depth, change this registry entry:
CURREINT_USER\\SOFTWARE\\Mathsoft\\Mathcad 12\\AppSettings\\MaxStackDepth.
There were good reasons to limit it, having to do with crashes and .NET, but you’re welcome to up it for your own use.
Institutional knowledge of the recursion depth limit Bug seems to have gone astray during the Mathsoft/PTC transition, so I was asked to recap (2010):
1. Recursion. M11 doesn't have a fixed recursion depth, so recursion was effectively resource limited. I gather it was changed in M12 because some users had complained that their recursive procedures were getting into infinite loops or states that could only be halted by re-booting their PCs (or using Task Manager to halt the Mathcad process); reading between the lines, it was pretty clear that most of the problems arose from poor programming practices or lack of understanding of recursion.
The M12 solution was to limit the recursion depth. Unfortunately, whilst bringing smiles and joy to the life of those who were recursively-challenged, it had a negative impact on those who did use recursion and simply took the occasional hits as punishment for our not thinking things through properly. Depth limiting caused a number of my worksheets to fail, and the only fix was to amend a value in the Registry, which doesn't make it portable and I never got to work anyway. The attached worksheet gives an example of this limit in action; try running it in M11 and M14 to see the difference. See the Note below for more general comments.
I also had a problem with the symbolic engine(s) not playing nicely with local recursive functions (and a few other features).
Converted .mcd worksheet without recalculation:
Converted .mcd worksheet after recalculation:
At least the numeric and symbolic engines are in agreement.
Stuart
It appears that the recursion limit has moved.
In Prime 4 i get:
still ok, but
In Prime 11 the limit is 1 higher.
In many cases (and this is one of them) recursion can be avoided by using a FOR loop:
which nicely gives
Luc
Indeed. Fold is most useful.. However, I do worry about its future.
So, that recursion limit is sitting there like the Sword of Damocles, dangling over our heads.
Scenario 1 is at play as far as recursion goes. Local recursive functions ...
(I added a fold variant of fact to my old demonstration worksheet)
Stuart
According to help:
vec2str(v)—Converts a vector of UNICODE codes in v to a string. This function also works with zero-length strings, such as vec2str(0) = "".
v is a vector of integers representing UNICODE code points for any valid string character. Acceptable values are integers in the range 9, 10, 13, or 32 - 255.
Indeed:
Note that the argument to vec2str is NOT a vector of real numbers here.
And it seems to require that, except when the 'vector' is 0, instead of [0].:
(Value must be a vector of real numbers.)
ok:
but:
(String cannot be computed because it contains an invalid character.)
In mathcad:
I'd say, Prime is on its way to meet Mathcad, but it's not there yet.
Luc
