Yes thanks.  Does that work the same if we change b:=cos(x) ?

Yes thanks.  Does that work the same if we change b:=cos(x) ?

The reason for the original question was to find a simple command that returned all the roots (mainly real) and Student(Calculus1) seems to do that quite well. Using fsolve doesn't always seem to return all the roots and only then some extra work is needed to be done to find them (ie examining a graph and specifying limits around each axis crossing to get a root - not the most efficient way of course).

The reason for the original question was to find a simple command that returned all the roots (mainly real) and Student(Calculus1) seems to do that quite well. Using fsolve doesn't always seem to return all the roots and only then some extra work is needed to be done to find them (ie examining a graph and specifying limits around each axis crossing to get a root - not the most efficient way of course).

Thanks for the clear explanation.  I understand now why Maple returns only a single value.

Thanks for the clear explanation.  I understand now why Maple returns only a single value.

Thanks. 

Any reason why fsolve won't show the values if the range is specified?

Thanks. 

Any reason why fsolve won't show the values if the range is specified?

Whoa!  I totally missed noticing the imaginary i in there.  No problems then. 

Whoa!  I totally missed noticing the imaginary i in there.  No problems then. 

For some reason I thought the space needed to be included.  It works as expected now and thanks for the explanation using the space. 

I agree that evalf(10.5) should return the exact value you specified 10.5 however if you change the settings so additional decimal places are displayed then maple should react in such a way to produce the number of zeros to fill that specification.  If it was 10  then I expect evalf(10.5) to return 10.5000000000, 10 decimal places.  However evalf(10.5/1.0) returns 10.50000000 not exactly 10 decimal places but 10 digits. 

So, Interestingly, it seems when I check the round display precision to xx decimal places it reacts as if I was using the digits command set to xx decimal places.

The thing is, it works fine on one computer and differently on the other, not what one would expect which indicated a problem somewhere.  Maybe to many java versions? 

I'll look into loopback.  Could be of help if I figure out how to use it.  On that note I just had an idea about checking the windows event log, not sure if it will yield any helpful info though. 

I agree that evalf(10.5) should return the exact value you specified 10.5 however if you change the settings so additional decimal places are displayed then maple should react in such a way to produce the number of zeros to fill that specification.  If it was 10  then I expect evalf(10.5) to return 10.5000000000, 10 decimal places.  However evalf(10.5/1.0) returns 10.50000000 not exactly 10 decimal places but 10 digits. 

So, Interestingly, it seems when I check the round display precision to xx decimal places it reacts as if I was using the digits command set to xx decimal places.

The thing is, it works fine on one computer and differently on the other, not what one would expect which indicated a problem somewhere.  Maybe to many java versions? 

I'll look into loopback.  Could be of help if I figure out how to use it.  On that note I just had an idea about checking the windows event log, not sure if it will yield any helpful info though. 

Oddly enough numerical expressions multiplied by another numerical expression raised to a variable is displayed without brackets.

A:=1000*(50)^n; is displayed as 1000 50ⁿ     

Okay, I can see it's more of a user personal style preference, and I agree that there should be more customizable options to suite the user. 

Oh!  I now see why I complained about the brackets.  Taking my original conditions A returns 100(20/21)ⁿ Now if I wanted that evaluated to decimals I would use evalf, but it's returned without the same formatting (ie no brackets) that's why I was complaining about that.  Hopefully it's a little more clear as to why I'm calling it a bug.