Community Tip - You can Bookmark boards, posts or articles that you'd like to access again easily! X
is there a way instead of writing all these qcza ( x ), I write just one variable that represents them all like qcza;in and still get the same plot
something like this
Solved! Go to Solution.
....Your each plot data
.....Stack all line data in same variable A
.....Plot all. But can't change each color of line.
....Your each plot data
.....Stack all line data in same variable A
.....Plot all. But can't change each color of line.
I thought that @YA_10963798 was more looking for something like this - but then I sure may be wrong about it...
@Werner_E wrote:
I thought that @YA_10963798 was more looking for something like this - but then I sure may be wrong about it...
<Werner Image>
Looking at the OP's diagram again, I think you're right. Although, as you say, the OP's intention isn't quite clear. If the purpose is to simplify drawing all of the depth plots, then yes, your method or a variant of mine does the job. I like your function, BTW. Neat.
However, if the intention is, in part, to make it more transparent what is happening at each depth, then there may be some alternatives. Provided one is aware that the pressure values are messed up, you can add a constant offset to each pressure curve so that they appear visually separated,
However, this hits one of the MP10 plot component's limitations. Trying to add a sixth plot makes most of them disappear (at least, on my PC). So, here's a crude variant of the stacker above that adds that offset.
Second axes would be handy.
Stuart
Oh yes!
I had not realized that each vector in Q.cza has its own corresponding depth vector in z because the OP use z[12 for all of them.
So your approach seems to be the better one as there is no guarantee that the (first) values in z[12 would be correct for all plots - they may differ in the various z vectors.
It took me some time fiddling around to find a short routine which would fill a vector too short with NaN's without using the most obvious way by using a loop 😉
I thought as its so easy to fill with zeros, the should be an easy way to fill with other values as well. Not really happy with the function I found but its the best I could come up with.
The display of the try and catch isn't really appealing in Prime.
Using an if-function would make for a more compact display
@Werner_E wrote:
Oh yes!
I had not realized that each vector in Q.cza has its own corresponding depth vector in z because the OP use z[12 for all of them.So your approach seems to be the better one as there is no guarantee that the (first) values in z[12 would be correct for all plots - they may differ in the various z vectors.
I looked into the z data in a bit more depth(!) when I wondered why there was that discontinuity in my original plot. I, like you, assumed that the OP had picked z12 because it was as good as any other z in terms of range. Ah, the things that catch one out by making assumptions. 🙂
@Werner_E wrote:\Oh yes!It took me some time fiddling around to find a short routine which would fill a vector too short with NaN's without using the most obvious way by using a loop 😉
I thought as its so easy to fill with zeros, the should be an easy way to fill with other values as well. Not really happy with the function I found but its the best I could come up with
It's still a neat solution, though.
@Werner_E wrote:The display of the try and catch isn't really appealing in Prime.
Using an if-function would make for a more compact display
No, Prime's layout of programs isn't as a appealing (to me!) as Original Mathcad's layout, either. I much prefer OM's more compact visual appearance. I quickly lose track of what's what in too much vertical space. The downside of the OM or the 'if' approach is that it can take up too much horizontal space, again losing some legibility.
In addition to the much asked for equation-breaking operators for +, -, · & /, I'd like to see comma- and definition-rhs-breaking operators. Certainly, the last one has also long been the subject of multiple feature requests. No point in breaking at the first addition operator if the argument list stretches off to infinity ... especially when you can't print Draft area pages. 🙄
Yes, I know they're not quite the same function definitions, but I lost the will to live while fiddling about in the (notice small errors, fix them) cycle.
Stuart
There sure would be a lot to do for R&D if they would be willing and able to ...
I'm just afraid that Prime Development is not very well funded internally at PTC.
If you poke around in the Mathcad folder in Program Files on your PC, you should find a folder called "mpl".
C:\Program Files\PTC\Mathcad Prime 10.0.0.0\Mathcad Converter\mpl
In there, you should find numerous .mpl files. Open one of them in a text editor, and you should see what I believe was supposed to be the Mathcad Programming Language, which looks very much like some form of functional programming language (possibly Haskell). Here's an excerpt from mcdefi.mpl ...
(For some reason, I can't any of the Haskell formatters to paste the highlighted code. The clipboard produces plain text (often unindented); even Notepad++ let me down. So, I had to resort to a screenshot of a reasonably comprehensive Haskell pretty printer. And you've got to admit it does look pretty!)
IIRC, Mathcad was supposed to compile a worksheet to MPL.
Stuart
The mpl directory you found is identical with the mpl directory in the Mathcad 15 installation directory. They had to integrate Mathcad 15 without the user interface in Prime to avoid having people install MC15 to be able to convert legacy sheet.
The "Mathcad Converter" directory contains most of the files and directories found in the installation directory of MC15.
And yes, the Haskel pretty printer did a very nice job, indeed .
I think I first found the mpl files in M12 or 13 when the MPL idea was being bandied around. The idea had promise, but for reasons that weren't explained, it was suddenly forgotten about. I suspect it wouldn't have fit in with some potential buyer's plans for Mathcad. I also suspected that the infamous static unit checking had something to do with both an external party's possible needs and the move to the more Haskell-like MPL - pure(ish) functional programming languages can get quite fussy about type mismatches.
Stuart
It would be easier if all vectors in q.cza would be of the same length as then you could augment them all and use a waterfall plot.
In your case it would be necessary to bring those vectors to the same length before, filling with NaN where necessary.
As ttokoro wrote it would not be possible to chose different colors - all lines would be of the same color.
If thats not a problem, come back here and say so. If you insist on different colors, I fear you would have to manually type in all abscissa vectors as you already did with five of them.
BTW, it is a bad idea to use variables with the same name as pre-defined built-in functions. I am talking about "rows" and "cols". Once you define those variables, its much more work to use the built.in functions.