@nm 
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)):

@nm 

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. 

thanks!

@nm 

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.

@tomleslie 

right... for me, these days, i find it harder and harder to use the worksheet interface (no useful key bindings, no syntax highlighting), and use an outside editor even for smaller calculations if analytics are required. The pain of *constantly* reaching for a mouse, every few seconds, on every edit, is unbearable (i'm only exaggerating slightly ;) ) after many years of vim (or emacs i'd imagine). This is even more true with Mathematica due to its inherently functional programming style, which often involves writing code "outward" (i.e. new statements wrap older ones).

For those who may be interested, there is a beautiful plugin for jupyter-notebooks (jupyter-vim-binding) that allow one to use (basic) vim modes for editing - works with whatever kernels are supported... for me it's a game changer, and the editing experience in jupyter is magical... no mouse needed essentially.
Now if only maplesoft provided a kernel for juputer-servers... that would be something!

@Joe Riel thank you for sharing!...

would would the advantage be of doing things this way, vs just calling "raed package.mpl"? i guess i don't know what one gains by writing a "package", other than things get imported/loaded differently.

also.. so say you've made changes in your package, you hit a hotkey in emacs/vim, things get "complied" and the package gets updated in your packages directory that maple knows about. I assume you then have to manually reload it in maple? or is there a way to make this happen automatically?

thanks again.

@acer 

i also use vim for writing code, but then just make:

read "code1.mpl"

read "code2.mpl"

type statements in my worksheet.

if you have something you're willing to share (don't waste time with anything new - this is no big deal), could you give an example of a more complicated module you've written this way, and how it's being used/imported/read?

Also, is there a way to have maple automatically update/reread a file/module on change? so say i've reaad/imported one, then update it in a separate editor, and would like a running maple session to automatically reload it.

thanks

@nm 

you could try installing the physics package from within maple via:

PackageTools:-Install(5137472255164416,overwrite=true);

(maybe worth while removing whatever you've installed before though)

@acer 

thanks for the workarounds.

I was hoping Eigenvectors() would support "implicit=false", in the same way Eigenvalues() seems to. I guess this is a bug/limitation then.

@acer 

very helpful, thanks for posting.

@Kitonum  @vv

thanks for you suggestions. They do work indeed.

Was hoping there is flag to maple's simplify that i missed and that would help it do this... i have some number of similar expressions (within larger expresisons), and so this wil help.

I'm kind of impressed that mathematica does, what i would consider, the right thing in these cases.

@tomleslie 

the "spurious" sequence \[] is how you define special/greek characters in mathematica using standard ascii (this is what i meant by referring to lprint). Maple has some understanding of them. Try:

a1:=convert("\[Kappa] + \[Lambda]  + \[Gamma]", FromMma);

lprint(a1); #looks like the right thing.

It seems to get confused, however, once some implicit multiplication is involved (perhaps along with these "special" characters).

This seems like a bug to me. 

ee

@tomleslie 

the "spurious characters" are mathematica's lprint version of the greek letters in this case - note that they are actually correctly interpreted. This is just doing a standard copy/paste (i'm using Mma 12.0 at the moment). It seems that the parenthesis seem to confuse the translator.

Just wanted to double check if i'm not missing something obvious; but maybe not... i guess will submit a fault report.

EDIT: hmm.. maybe because the multiplication is not explicit, maple doesn't know if it should interpreted the parenthesis in the context of a function with its depenednt variables, or just grouping of terms... but in this case, it does seem obvious.

@nm 

no worries.

i was guessing that's actually what you were doing. I meant that you could still write your 'data' string to a temp file from within maple after you extracted it from a database - then "read()" that file. It's not pretty, but all the parsing is done automaticlly in that case (with hopefully no gotchas).