@Markiyan Hirnyk I understand your solution mathematically, but what is the physical significance of any value of n other than 2 or possibly 3? And wouldn't the value of n be determined completely by the dimensions of k? Each ODE has dimensions of acceleration, L/T^2 (probably specifically meter/second^2 since g is given as 10).

@Markiyan Hirnyk I understand your solution mathematically, but what is the physical significance of any value of n other than 2 or possibly 3? And wouldn't the value of n be determined completely by the dimensions of k? Each ODE has dimensions of acceleration, L/T^2 (probably specifically meter/second^2 since g is given as 10).

To compute an answer, we need a numeric value for jj (or n). That value is going to depend on the units of k, which I suspect are 1/meter, in which case jj must be 2. But it seems strange that an exponent was specified as a variable. Also, wouldn't you rather have g be a more precise value than "10", like perhaps 9.8?

You'll need to end your commands with semicolons.

Please post your exact code in a plaintext format. In your transcribed code, you are missing some multiplication operators, and you have unbalanced quote marks and parentheses. Immediate problems that I see are that your definition of G does not use an earlier value of G (so G is not recursive), and that you attempt to define a recursive f with a simple assignment statement rather than defining f as a procedure (f:= h-> ...).

Could you give more details on the polynomials? They have 7 variables and integer coefficients. Roughly, how many terms? Roughly, what degree? Roughly, what is the magnitude of the coefficients?

Suppose there were a command to do what you want. What would you like that command to do with a*b + b*c + c*d?

In addition to lacking Maple relevance, this recent material from alex_01 is unoriginal, somewhat plagiarized.

Okay, I got it now. It's not your fault. The MaplePrimes editor often drops all the characters after `<` on a line.

Okay, I got it now. It's not your fault. The MaplePrimes editor often drops all the characters after `<` on a line.

That's essentially what you had before. It's still missing something; it couldn't possibly execute in Maple like that. Yet your original question indicated that you had gotten further along. So the above cannot be an exact transcription of your actual piecewise command.

That's essentially what you had before. It's still missing something; it couldn't possibly execute in Maple like that. Yet your original question indicated that you had gotten further along. So the above cannot be an exact transcription of your actual piecewise command.

I think that you dropped some characters while transferring your code from Maple to your post. There's something missing in the piecewise command.

Acer said:
> I'm not sure that I understand why Digits=180 is necessary.

Perhaps when the Asker said that the solutions were arbitrarily close, s/he meant that they could not be distinguished at a lower value of Digits. Perhaps an approach is needed where Digits is gradually pushed up until they can be distinguished. And perhaps this theorem will be useful:

 r is a multiple root of f(r) iff D(f)(r) = 0.

So, if D(f)(r) is close to 0 (say, it fnormals to 0), then increase Digits, and redo the fsolve in a very narrow window, whlle avoiding r.

Acer said:
> I'm not sure that I understand why Digits=180 is necessary.

Perhaps when the Asker said that the solutions were arbitrarily close, s/he meant that they could not be distinguished at a lower value of Digits. Perhaps an approach is needed where Digits is gradually pushed up until they can be distinguished. And perhaps this theorem will be useful:

 r is a multiple root of f(r) iff D(f)(r) = 0.

So, if D(f)(r) is close to 0 (say, it fnormals to 0), then increase Digits, and redo the fsolve in a very narrow window, whlle avoiding r.

I need to see a worksheet or a more-detailed code snippet to tell you what's going wrong. In particular, I need to see where you assign the values of t2, q, and especially sol. Also, I'd like to explicitly see two executions of Az(r) that produce different results. What you describe is definitely not the intended behavior. Maple should be able to handle the large numbers.