itsme

569 Reputation

13 Badges

12 years, 155 days

MaplePrimes Activity


These are replies submitted by itsme

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

@Kitonum 

thanks. of course you're both correct!

...long day.

ok it looks like

simplify(cc,symbolic);

seems to work with a few simple examples i tried. I was going to delte this question, but i guess i will leave it in case it's useful for someone else.

 

@vv  @Rouben Rostamian

While we're at it... exporting plots via cmaple interface is also does not work. (cmple interface can be very useful if one, say, wants to run code in batch mode, produce plots and save them - for example on a cluster, remote headless machine, etc).

Regarding exporting to pdfs and bounding boxes. Some time ago, I had some luck manually editing the pdf post export to fix some issues with the bounding boxes. This can also be done programatically via a script, etc. But surely it's a last resort "solution"...

I agree, it would be nice to get export working reliably, and maybe more sophisticated plotting abilities (eg: color bar for contour-filled, density plots, etc)

Hi @Stephen Forrest 

my take on this would be that by default, a call to latex() should:

1) always use \frac{a}{b} only

2) add no extra (latex) white space characters.

I agree with @Leo Brewin  a/b can be useful in inline equations, however, this if often done for shorter expressions and those are easy to type anyway. The real power of a usable latex() command would be for the long expressions/matrices/etc that are really painful to type out.

Regarding (2), I do sometimes use white space characters, but this is often done when defining commands or special characters, and very rarely to "manually typeset" equations.

Having some of these things user-settable via an argument passed to latex could also be an option, as you suggest.

@acer 

the docs for "interface(prettyprint)" claim:

"....Note: Subexpression labeling is on, by default, for prettyprint=2, and off, by default, for prettyprint=3."

but when I set interface(prettyprint=2), I do not see the subexpression labels, only with prettyprint=1.

Am I missing something?... or is this outdated docs?

syntax highlighting in 1d input (i.e the red input text).

... the holy grail for me would be more configurable interface and much more sophisticated editing/navigating capabilities: something like emacs or vim keybindings that would not requre one to reach for the mouse or for the arrow keys constantly when editing a maple worksheet.  (something like jupyter notebooks for example, where a substantial enough subset of vim key bindings can be used).

.. but i realize this is unlikely to happen. Perhaps actually interfacing the maple kernel (even at cmaple level) with jupyter notebooks would be a reasonable first step here. Something i might play with if i ever get the time.

@acer 

nice touch on that last one in terms of Ks... not obvious at a quick glance form the one before it would have such an elegant form.

@Preben Alsholm 

thanks, but that's the point i was trying to make; this function seems out of date and not documented well (i.e. these days a "vector" has a meaning of a "Vector" type, and not "array", if someting returns a Matrix, then LinearAlgebra functions shoudl be able to operate on it, also different returned objects depending on 'method', at least to me, is not obvious,  etc)

it was a dummy example i showed.. in my case, A(t) is large, time dependent, and my DEs are heterogeneous, so doing a MatrixExponential as you've showed is not enough.

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