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.

Kitonum: You need to divide by n-1 for the sample variance as opposed to the population variance.

Kitonum: You need to divide by n-1 for the sample variance as opposed to the population variance.

Well, you've reached that 10-point threshold.