rahinui

110 Reputation

6 Badges

6 years, 355 days

MaplePrimes Activity


These are replies submitted by rahinui

Awesome, thanks for looking into this. That's a rather strange mitigation, but in this case it looks like a sufficient work around. I am curious though why calling it twice fixes this; that seems rather odd.

Thanks again!

Thanks for verifying that this is a bug: I appreciate your taking the time to double-check this for me!

Thanks for the response. I could be mistaken, but the arguments look fine to me. Given that I've expressed my functions (f and g) in operator notation, the argument names are just placeholder variables. So the way I interpreted this was that inhilbert is being applied to the second argument of f (which happens to have the placholder variable s), and then the result is evaluated with the first argument labelled t and the second labelled x.

Thanks for the suggestion, this also works wonderfully. I had known expand could be passed functions (eg expand(ee, sin(a+b)) to avoid expansion, but I didn't know it could be passed general expressions as well. That's really helpful to know!

Thanks for the suggestion. Since I need the final result in terms of the original varible (eg. 2*x), I suppose I would have to do a second substitution back to the original variables. For my particular problem, the freeze/thaw method is somewhat easier: I might have numerous monomials to replace in a given equation (2*x, 3*x, 4*x, etc). In order to properply re-substitute them back after the expansion, I would need to keep some sort of dictionary between the original expressions (eg. 2*x) and the substituted variable (eg. a). This is certainly feasible, but freeze does this for me automatically. Nevertheless, for simple cases, I agree that yours is shorter.

Thanks!

I'm writing a code that generates equations (basically, collecting terms in powers of a small parameter) and then solves them. One such equation would be like this

sin(x+phi)*A + sin(x)*B + sin(2*x)*M + cos(2*x + phi)*N = 0

Since this must hold for all x, we can use the fact that sin(x), cos(x), sin(2*x), cos(2*x),... are orthogonal to equate each of their coefficients equal to zero. But first, the sum rule has to be used to re-write this as

sin(x)*cos(phi)*A + cos(x)*sin(phi)*A + sin(x)*B + sin(2*x)*M + cos(2*x)*cos(phi)*N - sin(2*x)*sin(phi)*N = 0

Then, collecting the coefficients of sin(x), cos(x), sin(2*x), and cos(2*x) gives

cos(phi)*A + B = 0
sin(phi)*A = 0
M + cos(phi)*N = 0
-sin(phi)*N = 0

Then, this system could be passed to solve (assuming phi was known, for instance).

The step I was having trouble with was the first one: converting cos(2*x+phi) to cos(2*x)*cos(phi) - sin(2*x)*sin(phi). However, @Rouben Rostamian's reply below using freeze/thaw was exactly what I needed. Namely, I freeze factors of x first (specifically, I use subsindets to apply freeze to terms of the form n::integer * x). Then, expand works fine, and I can thaw afterwards.

Perhaps there's a better way of doing this, but I am trying to solve an equation like

sin(x)*(A + 1) + sin(2*x)*(B - 1) = 0

that contains terms of the form sin(x), sin(2x), etc. I'm converting this to a system of equations using the fact that sin(n*x) are orthogonal. So, for this example, I would find {A=-1, B=1}.

I was separating these terms using coeff, but if my system had terms like sin(x+c1), then coeff(%, sin(x)) wouldn't work until I expanded. However, if I used expand, then terms like sin(2*x) get converted to sin(x)^2, and these terms no longer from an orthogonal basis.

Thank you very much! This is exactly what I needed. I was trying to do this manually by replacing names with atomic variables, but it ended up being too convoluted. Freeze/thaw is perfect though.

Thanks a lot!

     Thanks again for all your help; you've been incredibly supportive with these errors, and I apprecaite your assistance.

     Wonderful, thank you very much for your help. I really appreciate your help in fixing this problem!

Thanks for the response. That's fair, I had forgotten to consider that there were an infinite series of solutions. And you're absolutely right: my "expected" solutions are special cases of

C1 = C1, G = A*sin(x)/cos(x+C1)

I'm just find it unfortunate that the special cases were also returned in one case (includeing x as a solving var) but not the other.

Likewise, you're absolutely right: my second example again has my "expected" solutions as special cases. I just found it even more strange that a simple change from sin(x) to cos(x) would change not only the form, but even number of solutions returned.

Regardless, thank you for the help, and I appreciate the general rule-of-thumb.

Thanks a lot!

Dr Cheb-Terrab,

     As always, you are extremely helpful; thank you very much for that workaround! That should do the trick for now.

Ah, I didn't think to try simplify after using eval/RootOf. Perfect, thank you so much; that does exactly what I was looking for!

Thanks for the reply! You're absolutely right: the value of a function doesn't uniquely determine it's derivative at that point(s). However, I was simply looking to simplify (probably should have worded my question differently) the original expression while leaving the derivative part unevaluated.

Your suggestion works, as well; I was hoping for a more general way to simplify a long, complicated expression automatically.

Thanks for the help!

By trying to produce a MWE to answer your question, I find a solution (or at least a work-around); I'll post it below for future reference.

To answer your question, my code solves a differential equation and produces an output equation (def, below); I was then trying to substitute this into another differential equation (eqns). Originally, I tried both of the following ways to substitute def into eqns:

def :=f(t1,t2) = cos(g(t1)):
eqns:= -eval(Diff(f(t1,z),z),{z = 0})=0:

# Naive attempt
eval(convert(eqns,Diff), {def});

# My previous attempt
fcn_form := {f = unapply(rhs(def),t1,t2)}:
eval(eqns, fcn_form);

Here, the naive attempt doesn't work, but my unapply-method works fine.

However, if I replaced eqns with the (presumably) equivalent definition

eqns:= -D[2](f)(t1,0)=0:

Now, the naive attempt would work fine, but my unapply-method throws the indexing-error I mentioned earlier.

It seems that I can make my unapply-method work in both cases by converting to Diff first:

fcn_form := {f = unapply(rhs(def),t1,t2)}:
eval(convert(eqns,Diff), fcn_form);

It's quite possible there's a better way to handle both forms of eqns, but this seems to work for now.

Thanks for all your help!

1 2 3 4 Page 3 of 4