769 Reputation

14 Badges

16 years, 334 days

MaplePrimes Activity

These are replies submitted by itsme

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?

my core wishlist is largely the same for the last 12 years or so, mostly related to the interface:

- syntax highlighting in 1d math input mode
- configurable key bindings that allow for obvious things like go left, right, up, down, go word forward, backward, delete word, delete line, etc (something that would work in 1d math and text input in a worksheet).. ideally of course support for vim/emacs input paradigms would be amasing, but i realize that's not very realistic probably
- auto formatting help when writing multline code in 1d input... (i.e  new line in a proc or if statemnt should be auto tabbed, etc).
- various copy/paste issues fixed
- proper scaling on small screens with high resolutions

- a *robust* maple kernel for jupyter notebooks (mathematica has now got one!)

... and yes, I know I sound like a broken record ;)


sure... but the use case i had in mind is where you may have worksheets, where you've relied on the fact that "I" is the imaginary unit.. and now you want to print some of the equations from them... you might not want to make any interface changes or worse, rewrite parts of your old worksheets... but only change how the the latex sees things (of course you can wrap the command with interface calls, etc... but that's not as elegant).

Either way, from the other thread, it sounds like it will be possible to set the imaginary unit that latex prints... So that's great.


agreed. That would be good.... although i would presonally like to have an option of Physics:-Latex() be able to overwrite whatever other options are set... but that's a minor aside. Even as you suggest having a Latex-only option would be better than actually changing the interface options.

another idea might be to have that as a settable option/parameter that Physics:-Latex() could take in?

I would also vote for how the imaginary symbol should be rendered to be settable as an option to Physics:-Latex()  (per @nm 's other thread). Right now maple uses "I", but in a great majority of the cases, people who generate latex actually want "i" or "j". Changing the interface value is not great, because that chagnes the maple code....   but doing something like Physics:-Latex(exrp, imaginaryunit="i") would work nicely IMO.


thanks for your answer Edgardo. I understand.

My use case is, perhaps, different from what you envision. Most oftern I just convert not full documents, but essentially lists of equations into latex form. So far, when doing that, I've been able to just get around maple-specific styling with having a wrapper around the latex() or Physics:-Latex() commands that does string-replace...

The journals I that have to submit my work into, require the use of their specific styling, hence chagnes as severe as what maple styling seems to do, would likely not be allowed. Clearly, your goals are related to translating full maple document into latex documents... which is a differnt ball game from what I usually need to do.



Out of curiosity, is there a way to disable maple's style? and just use "standard" latex formatting (i realize that "standard" may mean different things to different people, but here I mean without having maple specific styling). I guess from looking at your example above, it looks like the maple style changes the rendering of the expression quite a bit... and i'm not sure if this would not lead to problems for many journals. I, personally, would actually much prefer having as few extras and fancy formatting as possible... just the bare (correct and robust) latex would be ideal.

Maybe there could be an option/argument that could be passed to the latex command that would choose one or the other?


i can confirm i've been seeing very weird behavior of Physics:-Latex() failing when dealing with lots of code and lots of stuff defined (before the call). Haven't had a chance, yet, to narrow it down to something smaller.


...sure, you "write your own CAS in python".  

More seriously though, while constructive criticism is great and often can be very useful, your approach to with statements like "Whoever made it has disgraced his own family" is over the top, and maybe unnecessary. But I suppose your post has gotten a lot of attention, which perhaps was your ultimate goal.

    Having said this, your core criticism is valid, I believe. 2D input has indeed been a major failure on many fronts. Since its introduction (15 years ago now!) it has been a constant source of frustration for many users. After all this time, it is still buggy. There are countless posts on mapleprimes related to problems with it, where the proposed solution is essentially to switch to 1D input. All the top commenters here seem to use 1D input as far as I can tell, and for many maple users the first thing to do after a new version installation is to make 1D input with the worksheet interface, the default. I've been in university courses where maple was used, and the instructors gave actual warnings to new users to *not* use the 2D input (that in itself is almost ironic given the very point of it in the first place was to make entering math simple for students).

1D input, will surely relieve at least some of your frustration. It is superb to use (as far as entering the math goes, and copy/pasting to outside editors for example - it's simple ascii after all!), and has some nice benefits over mathematica (for example: use of single underscores is allowed in variable names, double underscores are nicely parsed in output as subscripted variables, eg: alpha__a).

I actually also agree with you that the user interface design (or alternatively the flexibility to configure one the way one wishes) is really very important in the enjoyment one gets from using a particular tool. Here, even with 1D input, maple suffers a lot. Perhaps, due to the resources being consumed polishing the 2D input and the document interface, the 1D worksheet has not changed much (for "power users" anyway) during the years. Basic things like syntax highlighting, or keys configurability (i.e. basic key bindings to move forward/backward a word/character, etc) are still not there (!!). This is stuff that virtually any text editor has. When one compares this to modern interfaces like juputer notebooks (where one can for example use vim bindings!), or sage notebooks, it's difficult to argue that using maple is not a pain, even in 1d worksheet mode. These days, when possible, I also find myself choosing to do stuff in python, etc, simply because of its much better user interface (i.e i don't have to reach for the mouse ever 1.7 seconds).

This has somehow now also turned into a whining post I suppose... so to finish, let me change tones a little and point out that even with all these shortcomings mainly related to the poor interface, for many of my use cases (essentially manipulating/simplifying/approximating large sets of equations) maple is still absolutely untouchable. It's capabilities as CAS (in my use cases) are just not matched by much else out there... and I guess in the end that probably matters most.


thanks for your post. I'm on linux.

there are ususally multiple processes related to maple, so that won't work. I was thinking that if there is a way to save a given worksheet programatically, then it's very straightforward to grab the latest saved file name... but even that if not fool proof.

either way, i submitted a 'feature request' about this.


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