729 Reputation

14 Badges

14 years, 161 days

MaplePrimes Activity

These are replies submitted by itsme

@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.






this is great - thanks for typing that out.

Indeed was looking for something like


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.




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:
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).



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)

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.



great, thanks Edgardo - working ok now.

also good call with the naming in 2021 ;)


>>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!


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.

might be worthwhile submitting a bug report about this.


What happens when you try to open a file that has already been open is something that's typically handled at the OS level. For example windows does this very differently than linux.

I'm not quite sure what you were expecting (maybe a warning that a file is already open elsewhere?) but i think it's unlikely too see most *standalone desktop* software supporting some kind of simultaneous multiuser editing.


thanks for the info. This has also been my experience in the past (some years ago now), when I ran comparisons of a few (most important to me) linear algebra routines on both mathematica and maple... the performance was very close.

I will attribute this to dishonest marketing then...

@Carl Love 

Thanks for your points about "code edit region" (CER). I'm very familiar with it, and have both explored it in some detail when it was first released, but also play with it at every new release. It really does not solve "a lot of" what I'm talking about, as you say. From the items I mention (correct me if I'm wrong?) it provides some syntax highlighting and automated spacing. But even that comes at a great usability cost.

The core problem is that CERs are not properly integrated into the 1d worksheet at all:

- add a new "code edit region" (CER) via Alt-i, e, and start typing... you can't. You have to grab your mouse and click inside the code window... or move cursor with up then down arrow.  (I could imagine this point could be fixed?). Once you're within a code window, you can't easily delete it (the way you get rid of a standard 1d input cell with ctrl+delete), you have to do more gymnastics where you get your CER border "highlighted" first.

- CER are treated very differently from standard 1d input cells. You can't just 'enter' through them to run them... in fact they are skipped if you do that(!). You could use tab to get them selected, and then run/execute them with ctrl-e. This alone makes it *completely* impractical to use as replacement for standard 1d input (which I think you were implying). Imagine having all or most of your 1d cells replaced with CERs... now you can't easily re-run portions of your worksheet by pressing enter a few times, but carefully navigate around with tab/shift-tab/enter/ctrl-e combinations.

- Not sure if this is still true, but a coupe of versions ago, when you added many CERs, the worksheet would become very sluggish.

You may then say that you could use CER for larger code chunks, but that misses the argument I was trying to make in my original post - i.e I was proposing that *all* 1d input should have these nice features I outline. From my experience, much of maple interactive use cases consists of small code input cells that the user plays with.

So to reiterate my point related to input from the previous post: it would be great if standard 1d math input cells, had syntax highliting, could respect code strcture and space tings automatically (tab iniside if, etc).. and support keyboard navigation/editing (move curosor up/down/left/right, delete last word, go to start/end of line, etc). Ideally the keyboard navigation should be configurable, but even starting with (maybe optinal) emacs key bindings would be great, and should not be hard to implement for basic things. 

Also for these larger code chunks you actually might be better off using a real editor, which will be much more feature rich anyway, and just use "read blah.mpl" instead (of course there are some drawbacks associated with that too). This is what I resort to doing.

... of course maybe I missed what you meant? or am not familiar with some CER functionality that you have in mind?



I sure hope maplesoft does not borrow too many interface ideas from mathematica... and instead they think of jupyter notebooks/lab, where the flexibility and configurability are built in at the core. (Although mathematica's notebooks actually are somewhat programatically configurable).

The link in your post, however, is really interesting. I'm sure there is lots of marketing jargon there, but the numerical performance (Linear algebra related, for example) metrics are staggering, if true e.g.: finding eigenvectors, eigenvalues, etc. I'm very puzzled by this, as I thought internally it's all done by calls to MKL. Any ideas why maple performs so poorly?

1 2 3 4 5 6 7 Last Page 2 of 18