569 Reputation

13 Badges

12 years, 181 days

MaplePrimes Activity

These are replies submitted by itsme


good find!

might be worth while submitting a but report about this.


thanks for your answer Tom. In my case the display is 14 inch... so perhaps you can imagine how tiny everything gets. I have a feeling many more users will run into this, as the resolution on many laptops skyrockets.

@Carl Love 

thanks for your asnwer Carl.

Yes, I've been doing this kind of a thing. Note that just chaning the plot size, is really not good enough to work. One has to change all the fonts, label sizes, linewidth, etc as well. Othwise one has a big plot wher the "information" on it is barely visible.

As someone already also pointed out, when priting/exporting worksheets one has to "change back" to something more reasoanble. 

On top of this, plots are just one thing... for me the text in maple's menus are tiny - very hard to see.

It would be nice if maple had a more reasonable scaling implemented in its GUI.

I will second the other opinions - for me there is MUCH too much white space (and scrolling) and the default text is too small. 


that is excellent - thanks or that. It's really very useful when I stare at long expressions all day, and can with a quick glance know what my "variables of interest" are doing (see attached example screenshot).

In my (current) case, Q__T(t) vs Q__T(s) does not come up; everything is dependent on t only.  

Re: your "wishlist"... all good potential improvements if you ever have the time. A couple more I'd add to the list, would be:
(4) handling of "table" variables, as in Q[T](t)
(5) adding an option to show the variables in "bold" typeface - this would make the "special" variables even more distinguishable from rest.

... but like I said, for me this is already very useful. Thanks!

@Carl Love 


well in my case, even just coloring symbols would be better than nothing. 

The only worksheets i've seen that have this are ones that use the physics package - hence my question. 

Here is a dummy example (you can just run this in a maple worksheet):




a+b; #a is now a different color



yup you're right, just noticed that - thanks!


ok i think the problem may be that my 2016.0 version is not what you have:

Maple 2016.0, X86 64 LINUX, Dec 13 2015, Build ID 1096153

the build seems older than what you have (maybe this is the lats RC from the beta?). Either way i'll try to get my hand on the same one you have.


thanks again.


thanks for looking into this.

First i should note that I do run maple 2016.1 (not 'a' perhaps) on two different machines, but both are on ubuntu 14.04.  No problems on those computers.

This is a new machine with a fresh install of ubuntu 16.04.

These are the installation and upgrade files that I have been using, which (at least for the upgrade) seem consitent with what you have (i will look at the Build ID of a non-patched version later tonight):

md5sum ./
06455f61d8d822ad39d1242cfae85de2  ./

md5sum ./
7502caaa65cc623d5d2574823eee9343  ./

I guess i will contact support.




Thanks a lot for taking the time to answer this question Edgardo.

Looking at your modified worksheet however, I see that after the call to Library:-SortProducts, which results in Eq. 8, the products are not in fact written in the "correct" order. For example look at the 2nd and 4th terms in the second-last line. We still have terms like:

Dagger(a) a Dagger(a)

which clearly are not in normal order. There are other terms containing operators b which are also not in normal order (look at line 2 of Eq. 8).

The same follows after the simplification in Eq. 10 (see lines 4 or 5).

So my question still holds in a sense, if I'm just missing something, or at this stage it's not possible to write this expression in the normal order automatically (i.e using SortProducts or equivalent)?

... and thanks for all your work on the physics package!


i guess i understand "interface issue (2)" from above - maple gets "stuck" because after the execution block, i copy-pasted part of the equation into text, but that equation is considers 2d math input by maple...  and i guess it can't "jump over it". Fair enough.


thanks for posting this!... very nice, and could be very useful.


did you submit this? certainly seems like inconsistent behavior

@Carl Love 

Thanks Carl - somehow didn't come across this before... 



just a word of caution... in some cases one will get a wrong (unexpected?) result. For example, consider

Setup(operator = {A})


diff(f,t); #wrong answer in general - assumes [A(t), diff(A(t),t)]=0, but does not have to be true.

it's easy to see that this is also in general wrong:


Setup(operator = {A, B})

f:=exp(A(t) + B(t));

diff(f,t);  #wrong

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