729 Reputation

14 Badges

14 years, 161 days

MaplePrimes Activity

These are replies submitted by itsme

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.


thanks for your reply. I couldn't find one either. I usually have many worksheets in any relevant folder, so that wouldn't work.

Agree, that this can be very useful.

@Carl Love 

thanks for your input!... yes, that indeed is what i needed.

a minor modification (in case someone finds it useful) to pass on the extra args:

map_terms:= (f,e)-> `if`(e::`+`, map(f,e, _rest), f(e, _rest)):



thanks for the quick answer

@Carl Love 

yikes!.. i've of course tried that, but actually had coeffs (and not coeff) in that call as was playing with coeffs earlier, which failed. Didn't notice and just figured coeff doesn't know how to deal with negavitve powers. 



I wonder why the choice to use method(arg,object), and not method(object, arg), was made.

The latter seems much more natural to me, as the position of the 'object' is always the same, and does not depend on the signature of the method.


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