Printing 2D math programatically using typeset()
Using the typeset() plot option, I am interested in printing labels of vectors on Maple graphics. The vector labels must have arrows on top. I can do this already if I know the name of the vector in advance, e.g. "V", by invoking the command
plots[textplot]([x, y, typeset(`#mover(mi( "V" ),mo("→"))`)]);
But what I really want is to write a procedure that will take the name of the vector as an argument, so that other procedures I write can create and annotate vector diagrams. However, the backquote ` symbol used in the code above can only interpret literal strings, not variable strings. That is, the following *doesn't* work
printVectorLabel := proc (x, y, VECTORNAME)
plots[textplot]([x, y,
typeset(`#mover(mi( VECTORNAME ),mo("→"))`)]);
end proc:
Calling printVectorLabel(5, 10, "a") would ignore the argument "a" and just print the symbol "VECTORNAME" with an arrow on top.
Can you help me? Is there a way to "get around" the backquote literalism?
Thank you!
- Problem solved!
2 hours 55 min ago - Perhaps seq(coeff(Q, lambda, n), n = 1 .. 8) ?
3 hours 2 min ago - Some comments
8 hours 33 min ago - frontend
15 hours 53 min ago - Problem with declaration of Vector a functions of x,y,z
16 hours 16 min ago - MySpace
16 hours 26 min ago - and did that return anything
18 hours 28 min ago - coeff is univariate
18 hours 42 min ago - I did something:
polinom:=
18 hours 49 min ago - Integral of partial derivative problem
19 hours 31 min ago
Vector label
Try this:
printVectorLabel := proc (x, y, VECTORNAME) plots[textplot]([x, y, typeset(`#mover(mi(` || VECTORNAME|| `),mo("→"))`)]); end proc:Typesetting and string
Something unexpected: in Maple 11.02 (Standard GUI, on Windows XP) Jason's code
> plots[textplot]([x, y, typeset(`#mover(mi( "V" ),mo("→"))`)]);
(with numerical values for x and y) produces the desired effect, but in Maple 12.01 (Standard GUI, Windows Vista) it leaves double quotes around the V. Is this a
design change or a bug?
In a simplest form
This difference between Maple 11.02 and 12.01 occurs here:
PLOT(TEXT([1., 2.], `#mi("V")` ));Ie, in Maple 11.02 it is the same as with the non-quoted version:
but in Maple 12.01 double quotes are displayed.
another way
This seemed OK for me, in Maple 12.01 (on Linux). I didn't see quotes around the name, as with the typeset() solution.
Z:=(x,y,t)->plots[textplot]([x, y, Typesetting:-mover(Typesetting:-mi(convert(t,string)),Typesetting:-mo("→"))]): Z(1,1,P);The arrow symbol that you see there is actually "→" in case you wanted to type it in rather than cut 'n paste from here.
For some reason the above procedure (itself, its own body, not its output) would not print in the Standard GUI. That's a bug, but it shouldn't prevent one from actually using the procedure.
acer
subtlety?
I have realized that a detail was missing. There is an issue with spaces (ie parsing I think): a space at one side or at both sides of "V", as in this statement
seems needed to get the double quotes in Maple 12.01:
But without spaces:
PLOT(TEXT([1., 2.], `#mi("V")`));no double quotes are displayed. This effect seems unrelated to Maple 11 vs 12.
Plot labels and typesetting
As Alejandro pointed out, the problem is that `#mi( "V" )` (with extra spaces) gives a diferent result from `#mi("V")`. While this is unexpected, I hesitate to call it a bug, mainly because the use of the internal form is not a documented feature and we are not expecting a structure like `#mi( "V" )` to be generated by a user.
I wouldn't necessarily discourage you from using the internal form, as it does allow you to do some things which you wouldn't be able to do otherwise. However, it is definitely a "use at your own risk" feature because we are unable to document and maintain it at the moment. One reason for this is that the internal form may change from release to release.
Rather than build the atomic identifier on your own, I would suggest the following as a safer way to generate it. First, enter one of the entries from the "Accents" palette to get the symbol you want. Then, replace the placeholder with an arbitrary name that's not used elsewhere. Create an atomic identifier from the expression and lprint to get the internal form. (I'm pretty sure you must have already gone through these steps to get to the current point.) Now, use the command StringTools[Substitute] to replace the placeholder name with the name entered by the person using your routine and convert the result to a name. Then use this result in the plot command.
Paulina Chin
Maplesoft
Not that way
If of any interest, my approach to explore this internal form is direct. Very seldom I go to palettes, create atomic identifiers, lprint it, etc. For me this is too clumsy, and I find much more efficient to go look at the Mathml documentation and adapt it to this particular Maple version. Or browse through my personal documentation of these tricks.
I agree that the user should not deal with this internal format. Frankly, I dislike having to do so. But what is missing is a programatical user interface that translates LaTeX-like commands to this internal form (why not using TeX as internal form?). Palletes or menues may be an alternative for simple or special cases but never a replacement as it is an approach that does not scale well with complexity and is not suitable for reuse.
Programmatic way to typeset expressions
Alejandro is correct in saying that we don't currently have a programmatic way to convert LaTeX to our internal form. However, there is a way to programmatically typeset all Maple expressions, and that is the Typesetting[Typeset] command. It is mentioned on the Typesetting help page, but there is a warning to use it with care. It is generally safe to use the Typesetting[Typeset] command and pass the results to routines like plot() that know what to do with them, but it is not recommended that you alter the output (i.e. the internal form of the typeset expressions).
I agree that more and better tools for programmatically typesetting expressions would be helpful to users. These may appear in future releases, but we have to balance a number of user requests related to typesetting. If there is great demand for these tools, then certainly they will get a higher priority.
I also believe strongly in using all the tools available and doing what is easiest. Sometimes, you really need to do the typesetting through 1-d commands, as in the situation presented by the original poster in this thread. On the other hand, I frequently see users trying to jump through hoops to get a desired result through the command-line when it's not really necessary to do it that way. I'm not suggesting that palettes, context-menus and command-completion can replace 1-d usage but they do have their uses. I use both 1-d and 2-d together in the same worksheet all the time. I find writing procedures in 2-d painful, but I find creating typeset plot titles in 1-d equally painful.
Our marketing people claim that using 2-d math should be "natural". It probably is more natural than 1-d math to new users, but I suppose it can be unnatural to people used to command-line Maple. (My formative years were spent programming in Fortran and C, so my initial feelings about 2-d math were probably not so different from yours.) However, I think it's very worthwhile to take the time to become familiar with it, if only to figure out when it's most useful and when it's not useful at all.
Paulina
diversity
A product so general as Maple, intending to reach so diverse kind of users, cannot do it with a single approach. What is "natural" for a person or a group may be unnatural for other. And this is previous and independent to how long experience with Maple is.
On the one hand this is in part a personal issue, ie the way each mind works best. So, you have persons that are lost without a GUI and mousing around, while on the other extreme some others find comfortable only by typing commands on the OS console.
On the other hand there is an issue of group culture and investment. In the hard sciences (Mathematics, Physics, etc) it is a must and the standard to use TeX, and everybody has invested time learning it. So, within this group, it is natural, convenient and expected to use it to type and display math. In particular as it is so good in typesetting. But Maplesoft tries to reach other groups of users, may be Engineers or other, used to word processors, for which TeX may be unnatural.
Note that both points are not easily correlated: the preferences for producing TeX documents may range from using a simple editor, to WYSIWYG like interfaces.
I.e., the better and natural tool set for each group is unavoidably different. So the point seems to be about priorities of development, diversity of the demands and "market size" of each group.
I think that there have been many requests here at MaplePrimes by members the "TeX-command-group". I may track for them if needed. And a poll or survey could be made to estimate how large fraction of the Maple users base this group is nowadays, if doubts exist on this point.
Note that several other applications addressing this market niche use TeX commands for input (or use TeX for display). So it is nothing like an unusual request to have a LaTeX-like input alongside, and with the same functionality, as purely GUI input.
Listen
Listen to Jakubi. He is absolutely correct. It is hubris for Maple to think that quality typesetting can be attained by mouse clicking one's way through pallates.
When `#mi( "V" )` ( with extra spaces ) gives a diferent result from `#mi("V")`, you know you are in big trouble.
Earlier in the thread there is a reference to the "Typesetting [ Typeset ]" help page-note the redundant spaces.
I read it. Read it for yourself from a critical perspective. Does it really tell you anything useful at all? It includes one stupid example that deals with a subscript on a Bessel function. The help page has some links, but by the time you follow them you feel like the poor fish named Dory in the movie "Finding Nemo." And from this we are supposed to infer the power and insightfullness of the Maple typesetting package?
Give us LaTeX support, otherwise the product will wither away.
Typesetting package
Whoa, hold on a moment. :-) Please don't misinterpret my comments. Alex writes: "It is hubris for Maple to think that quality typesetting can be attained by mouse clicking one's way through pallates." I'm not necessarily making that claim. I'm just pointing out that the palette is just one of the many tools in Maple and it can be very useful in particular circumstances.
"And from this we are supposed to infer the power and insightfullness of the Maple typesetting package?" No. Indeed, from my point-of-view, I'd rather you not use Typesetting[Typeset] at all. People here claim there is a lack of tools for programmatically doing typesetting. I don't dispute that at all. I agree with you. I offer Typesetting[Typeset] as a less-than-ideal workaround for now until better tools are available and suggest that the GUI tools may be less clumsy and more useful than some might initially believe.
We're still developing Maple's typesetting and likely there will be better tools for programmatic access in future releases. My recommendation is that, if you want particular features, speak up and ask for them, and not necessarily in these threads that are usually devoted to answering specific technical questions and are read mostly by developers. Occasionally, other Maplesoft staff will set up polls or discussion questions elsewhere on MaplePrimes asking for input and those are good places to express your views. I should add, though, that we have many users who do not participate in MaplePrimes and we do get lots of typesetting requests from them too, often ones that are related to GUI and not programmatic access. So we have to balance and prioritize the requests. (BTW, I had been a long-time LaTeX user myself, so I know where you're coming from.)
I'm speaking as a developer here, not as a marketing or sales person. From my point-of-view, the typesetting project is a work in progress. It's incomplete but it also has huge potential. If we waited until it did everything that eveyone wanted, it wouldn't be released for another decade. However, I'm glad it's out there and in use now, despite the limitations, because what is there now is extremely useful to some people. We're still actively working on how to make it even more powerful, so please speak up for the features you want.
Paulina