opus64

110 Reputation

5 Badges

5 years, 284 days

MaplePrimes Activity


These are replies submitted by opus64

@Kitonum For what it is worth, I confirmed the Accent palette 'bar over' behaves this way in 2022, 2021 and 2020. i.e. it applies conjugate().

@acer That's it, I looked at the 1-D interpretation and it is indeed conjugate(a). I then used the 'Layout' palette and added a bar character 'Over' and that works. Thank you.

This seems rather unintuitive, I read 'accent' as a character/label operation.

@acer This is exactly what I was looking for. Thank you!

Thank you for the replies. It is unfortunate (and baffling) that Maple cannot handle such an trivial case. If I imagine the simplest of algebraic parsers, it would certainly find a term exactly as written and move the A to the other side.

Regarding the parenthesis, it fails in the same manner without it. I actually added it in an attempt to hand-feed it to Maple.

I did notice the examples in isolate, but inferrence is not really a great way to document things. It would be so helpful if Maplesoft would add more detail to the limitations around functions. It seems there are often multiple functions to do what amounts to the same logical operation in hand-calculations, but each one has different limitations (for example subs, algsubs, applyrule).

My original expression is much longer(which is partly why i'm using Maple), so it seems manually handing it information is the only way.

@acer As always, thank you for your awesome explanations.

To answer your last question, that is exactly what I would like to do. I would like to say something like isolate(eq, {c[n], f[n]}) such that maple tries to move the simplest expression containing those two variables to one side, without me needing to know a-priori what the expression is. It would return the result at the end of your worksheet, but I would not have to give it the expression.

In this sense, my example is probably not the best, because when we enter (eq), Maple happens to show the expression c[n]*(e+f[n]) in the numerator just by virtue of how it chose to re-express/simplify the equation we entered. It seems often the desired expression is not clearly visible like this. Maybe i'm missing some deeper understanding and i'm wrong.

Also, do you know why this isolate did not work?:

It seems like the expression is in the equation quoted by the error text, I find this somewhat unintuitive.

Thanks again.

@acer I think this captures an example. Suppose I have the below equation:

I would like to isolate c[n] and f[n] to one side of the equation, not knowing what the resulting expression is going to be(some variables might get dragged along with it). Obviously I can do this by hand but I was wondering if there is a way to do this automagically.

 

Incidentally, I tried doing the following just writing an expression and that also fails for some reason:

@acer Thanks for the detailed explanation, i'm going with (4). I'm glad I asked this question, there's a lot of nuance here that I wasn't aware of.

Thank you both for the replies.

@Carl Love Can you expand on what you mean by 'set the desired variable values in the same execution group as the Explore'? I have the variable values assigned in an execution group that is different from the Explore, but as far as I can tell the values transcend the execution group..maybe you mean there is a way to make them local to a execution group only?

@acer I have attached a worksheet below that mimics the general structure I use. I normally have a restart at the top and use CTRL+SHIFT+ENTER to execute the whole thing:

Explore_problem.mw

In the particular problem I am examining, I am looking at a rather complicated set of equations that are of interest in several configurations where the variables(really constants) have different values. Since there are multiple configurations, using a new variable name for each just to make Explore work would be undesirable.

@Carl Love Ok, I guess I came into Maple with a rather narrow view.  I have used Matlab for decades and always used pencil and paper(or more recently, stylus and tablet!) when doing derivations before putting them into matlab for computation.  This can be error prone, and requires redoing everyting for simple changes. Relatively recently(years) I noted that since Maple had the 2D math notation, I might be able to replace pen and paper with Maple. I personally find writing 'code' i.e. math in a single line with ASCII characters very confusing and clumsy for complex expressions, which is something I hated about using Matlab's symbolic toolbox.  So my perspective is that I specifically look at Maple as a 'notebook' and I expect the intuitive behavior to only involve entering math expressions.  If I have to dig into/understand the internal workings and enter code to make things work, then it breaks that paradigm and it might take me less time to do it with pencil and paper.

 

But the thing is, if I were trying to do something complex and I had to dig into the inner workings, I could understand that.  But this is not complex.  This is simply mantaining consistency of the simplest behavior(what happens when you press ENTER) across scalars and vectors/matrices.  Really seems like it should be consistent, but this is just my naive opinion as a late-comer!

@Carl Love

@acer

Thank you both for the explanation! They very clearly explain what is going on under the hood, and as I experiment with it now, the behavior certainly lines up with your explanations.

 

That said, isn't this a bug? The reason I say this is because if I just make a scalar equation, the behavior is that scalar variables are evaluated when I type them.  It is only logical to expect that behavior to be consistent when working with Vectors and Matrices.

 

I wouldn't mind it behaving one way or the other way, as long as it was consistent across scalars, vectors and general matrices.

 

Thanks again!

@acer Understood, it was just a large worksheet so it took me a bit to create one I can post:

PhiQuestion.mw

Experimenting with this worksheet, the issue appears to be caused by the assume.  I don't quite understand why it matters, but it does. I beleive I am assuming 0<phi<45. Not sure why that would interfere if I want to assign phi:=10 later.

Perhaps Maple internally thinks of phi with an assumption as something else (like the phi~ notation that seems to have gone away in Maple 2020) such that an assignment on phi is not the same thing?

@acer Apologies, I made a typo when I was typing a concise set of statements to post the image.  I happens if I use := also, please see below:

 

 

 

@acer Got it, thanks. Hopefully this will get officially addressed.  I tried adding a 1e-6 scale factor everywhere in my equations for the other parameter but I'm now getting 'too many levels of recursion' error when I add the scale factors.  Anyway, it is still a very useful workaround in the meantime, thanks again!

@acer Also, I did notice one limitation of this specific solution.  I just noticed that in one of the Explore plots I have multiple sliders, and while one slider benefits from the %0.2f format, another slider has a range in the 1e-6 order of magnitude, so the label just shows as zero.  I worked around it by redefining the 1e-6 variable in the equation so it works with the %0.2f format.

@acer This works beautifully when added to maple.ini, thank you!

An intuitive way to expand this could be for maple to watch for the number of digits that the user provides in the range.  For example, if the user says x=10.5..11.5 then show 1 decimal place in the resulting GUI controls, if 3 decimals are desired then the user can enter x=10.500..11.500.  However, this simple approach has a limitation in that it does not allow for displaying fewer decimal places than are provided in the range.  I think the TextArea improvement mentioned above or something along those lines would be a better approach.

Thanks.

1 2 Page 1 of 2