@acer 

aghh.. good catch!... indeed changing the order works very nicely.

I would consier this a bug then (do you agree?). Will put in an SCR.

thanks.

Thanks for your post @TechnicalSupport
 

your work around is very helpful!...and it does work with increasing the font size!... that's great.

There is a problem, however, that now the top ribbon/bar takes up a fifth of the screen real estate (please see screenshot)... is there a way to decrease/set the icon size?

(EDIT: yes, there seems to be an option under Tools->Options->Interfrace that controls the size of icons, i had it set to large, which is now not needed!)

Either way, this is a really great development and a game changer for me.. i basically stopped using maple on my laptop unless necessary... (next to impossible to select files for example, without some extranal "zoom-in" software).

It would be great if one could provide some option to xmaple that would make this a simpler process.. i.e something like

xmaple --zoom 2.0

which would pick fonts close to 2.0x of the default defaults (or whatever equivalent, say xmaple --fontsize 36, etc... )...

(at the moment one can't set JVM_OPTIONS externally it seems, because the maple script doesn't check if those are already set and instead overwrites... so one really has to dig into modifying the maple script as you suggested.)

Anyway, thanks again for your update - very useful stuff.

Hi @ecterrab 

SortProducts seems broken in latest physics version (1011).

Please see the attached worksheet.

thanks

(btw, i get an error from mapleprimes when I try to insert the worksheet below)

physics_sorting_products.mw

just a comment: i find your questions and Edgardo's answers very useful. I've also been playing a with expression selection/simplification and building these conditionals that can fine tune selections seems very powerful. 

I've also had a hard time with this. 
Maple is truly in the middle ages when it comes to exporting plots. A few years back, I spent a cringe-inducing amount of time making vector-format plots "presentable"... in the case of 3d ones, by doing things like auto-conversions between formats and/or directly editing/string-substituting contents of pdf files (i.e to get boundaries of figures show up correctly) - not to mention jumping through hoops to get labels/text to display correctly. 

The best workflow I found in the end....  is to completely give up on maple in that regard, and if need be, to export data and plot elsewhere for anything that needs to be presentable. Alternatively for simple numerical-only work, to just use other tools altogether, to save on the exporting headache. 

As I'm recently working on something that does require analytical work and a lot of plots (not for publication, at the moment, just to put in docs to show to collaborators), A few weeks ago, was checking again if things have changed... but as far as I can tell, not much (maybe I missed something though?). There seems to be plottools:-exportplot() command, but it does not seem to be able to output to pdf or svg... unfortunately (i.e. can't just do something like plottools:-export(file_name.pdf, myplot) - maybe there is some other vector export format that maple does support, where the conversion to pdf would be easy/reliable? haven't checked)

I don't know how badly this breaks for 3d plots, but for simple 2d plots that I've had to quickly do in a last week or so, I ve been basically saving as png, but setting fonts/linewidths as well as figure sizes to be HUGE. Then when I actually include those plots in documents, they are scaled down, and don't look completely horrible (still not publication ready - really need non-rasterized format for that). I use something like:

save_plot:=proc(p, file_name)
    plotsetup("png", plotoutput=file_name, plotoptions=cat("quality=100,portrait"));
    print(plots[display](p));
    Threads[Sleep](2):
    fclose(file_name):
    plotsetup(default);
    ssystem(sprintf("convert %s %s.pdf", file_name, file_name[1..-5]));
    print(file_name);
end:

this is on linux, and requires "covert" installed to do the conversion to pdf (of course this is not required as the plot is still rasterized - just more consistent to have all pdf files for rest of my workflow). Clearly that doesn't help you if you really *need* vector graphics, but might be useful otherwise. 
Maybe there are better workflows that people have come across by now? 

As a side note, it would be great if plottools:-exportplot would be a nice robust command that works for all plots/scenarios, and most importantly could directly export to pdf/svg... maybe the whole ugly plotsetup() thing could then be "retired" as far as plot-exporting purposes go...  ;)  

@Preben Alsholm 

This is a great addition and I would argue it is "important" to have similar commands behave in a similar way. It makes the interface much more concise, and easier to use (i.e. one does not have to try to remember what works on what similar command). It's a usability thing, and my guess is that the updates to the other commands were simply overlooked. 

i can confirm this is also a problem on my linux machie.

In my case, I see other issues as well: from time to time menus and/or submenus will not properly show up or if they do, they may not be "clickable/selectable". This happens especially when maple is not in "full screen" mode (i.e., taking up the whole screen).

Maple is in general not a great linux citizen; it does not respect standard X11 guidelines. For example, WM_CLASS properties are not set properly;

>> xprop WM_CLASS  #for a xmaple window
WM_CLASS(STRING) = "java-lang-Thread", "java-lang-Thread"

These should say something like "maple" or "xmaple", or whatever, and not be generic "java" things. There are other related issues as well.

@ecterrab 

this is great - thanks for typing that out.

Indeed was looking for something like

lprint(Typesetting:-Typeset(Ket(A)));

to tell me how this is already done for some known cases.

Will get the core physics/math stuff of the above calc going first, and then will play more with this.

@ecterrab 

Yea, sorry that it maybe came off this way - i didn't mean to imply for you to implement this right now, out of the blue - just meant that somewhere down the line, some functionality like this might be worthwhile adding to the Package as I'm sure it might be useful for many (after all, the Julia implementation warrants its own preprint). As I mention at the bottom of my previous post, I will definitely put together a crude version of this. 
There is no question that this is "possible" in maple - in fact the only thing that's left is writing f([A,B,C, ...]) that returns of a sum of product of averages (that approximates f([A, B, C, ...])), which is basically a look up table at low orders. Calculaing the rhs of an equation for a given operator, is just a matter of doing commutators, and sorting terms, which the Physics pacakge already does.
... then wrapping with the few lines you posted into a function. 

Anyway, will post that back here, maybe in a weekend or two.

Reading `print/f`, yes, I did look at that, but as you say there is limited documentation.
What I had in mind is basically printing something equivalent to how the Ket() does it. 
From quickly glancing at:
showstat(print/Ket)
and
showstat('Physics:-Ket')
it's not clear to me where the actual output form (i.e. |A>) is defined... but maybe i have to play with it more. (Either way, this is a very low priority, not in any way a requirement for any of above discussion).
 

@ecterrab 

thanks for your quick answer Edgardo!
As I figured, this is so much nicer (and shorter) than how i was thinking of doing it. Also very helpful.

Small caveat is that the differential operator works slightly differently than the ave function that i was imagining because:
"ave(beta^2)" does not give "beta^2"  (i.e last term), but it's trivial to just manually set it to 1 after the rest of the relevant ave(ABC) terms get transformed to the f-functions.

Also, thanks for sending the link to your worksheet... indeed that looks tangentially related.

This thing i'm doing, is essentially a mean-field expansion, which is then cut off at some nth order (i.e. meaning the nth order cumulant is approximated as zero). This is actually extremely widely used in various areas of physics, and comes up in many-many papers. One often wants to understand some dynamics of a large size system, for which solving the full Shrodinger (or more realistically Lindblad master) equation is not feasible.
Perhaps at some stage, when you're bored, you might consider adding this kind of functionality to the Physics package (probably an hour's work for you - the hardest parts, i.e handling, sorting, noncommuting operators - you've already done).

The idea is basically:
1) write down the eoms for a given system. For coherent system, that's just the standard Heisenberg eoms, and there is trivial correction if one has Lindblad (noise describing) terms.
2) average all the operators
Key point is that the eoms might not be closed (meaning a diff equation for, say, <AB> might depend on, say, <ABC>), hence:
3) do the n-th order cummulant approximation; i.e., write the all nth order averages in terms of terms only containing (n-1)-th order averages.  

There is currently a way to do this up to 4th order in mathematica, using the Quantum package (not updated since 2011, but works with recent versions).
There is also a recent paper about a Julia package that does it (with some limitations)
https://arxiv.org/abs/2105.01657

In the past, I'be been doing this mainly by hand in some simpler cases, but more recently have switched to using the mathematica package above to generate relevant equations of motion, then slightly rewriting them so that maple can easily import via FromMma()... but indeed would be nice to do it directly in maple (hence this post). So will try to get some crude version going based on your answer.

I have another couple of simple questions about functions of operators and commutation, as well as about defining a visual representations for objects (i.e. can i have, say, f([A,B,C]) get printed as "<ABC>"), but maybe will ask those in their own thread at some stage.

@Rouben Rostamian  

Thanks for reminidng me about '~'.

I still wonder, though, if ther is some more fundamental reason why some of the functions (such as int) don't do this by default.

@ecterrab 

great, thanks Edgardo - working ok now.

also good call with the naming in 2021 ;)

@nm 

>>So if these tweeks can be automated and fixed at the Latex generation source, all the better, as it will benefit everyone.

The gotcha is that some people may not want the tweaks/"fixes" - i usally prefer as clean/standard latex as possible... hence if something like this is implemented, IMHO would be great if it could be turned off for those who do not use it.

you mention \int, but do you really mean \sqrt? or did i miss something?

I personally feel like this kind of "automated prettyfing" is ok, as long as there is an option to turn it off (the holy grail would be something where the user could define how some things are rendered, i.e \sqrt should have \, at the end, or whatever)
It seems that sometimes it's easy to miss cases where these changes don't end up looking good, and moreover always lead to more convoluted latex output, which becomes extra tedious to fine-tune manually.

Often latex is excellent at doing the formatting/typesetting just right, although I agree that in some circumstances one might like to do some tweaking.

P.S. by the way, you seem to be doing amazing work pointing out all these various latex-related things, and with Edgardo fixing them as fast, the functionality and usefulness of Latex() is skyrocketing!... so, great job both of you!

@Valerie 

could you perhaps just post here what the steps are to minimize this issue? this is something that surely affects a lot of people, so it would save everyone time if this info was made available freely.