itsme

619 Reputation

13 Badges

13 years, 159 days

MaplePrimes Activity


These are replies submitted by itsme

@ecterrab 

great, thanks Edgardo - working ok now.

also good call with the naming in 2021 ;)

@nm 

>>So if these tweeks can be automated and fixed at the Latex generation source, all the better, as it will benefit everyone.

The gotcha is that some people may not want the tweaks/"fixes" - i usally prefer as clean/standard latex as possible... hence if something like this is implemented, IMHO would be great if it could be turned off for those who do not use it.

you mention \int, but do you really mean \sqrt? or did i miss something?

I personally feel like this kind of "automated prettyfing" is ok, as long as there is an option to turn it off (the holy grail would be something where the user could define how some things are rendered, i.e \sqrt should have \, at the end, or whatever)
It seems that sometimes it's easy to miss cases where these changes don't end up looking good, and moreover always lead to more convoluted latex output, which becomes extra tedious to fine-tune manually.

Often latex is excellent at doing the formatting/typesetting just right, although I agree that in some circumstances one might like to do some tweaking.

 

P.S. by the way, you seem to be doing amazing work pointing out all these various latex-related things, and with Edgardo fixing them as fast, the functionality and usefulness of Latex() is skyrocketing!... so, great job both of you!

@Valerie 

could you perhaps just post here what the steps are to minimize this issue? this is something that surely affects a lot of people, so it would save everyone time if this info was made available freely.

might be worthwhile submitting a bug report about this.

@Anthrazit 

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.

@acer 

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?

 

@mmcdara 

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

ALTERNATIVE TO MOST OF THESE:
- a *robust* maple kernel for jupyter notebooks (mathematica has now got one!)

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

@nm 

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.

@nm 

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.

@ecterrab 

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.

 

@ecterrab 

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?

 

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