It is a well-known phenomenon that the usual closed-forms for roots of polynomials, even when the roots are exactly real, give complex parts which exactly cancel. But this cancellation is numerically very unstable, so pure numerical evaluation give (usually small) imaginary parts. There are known formulas that do not have this problem, but they don't agree with what is "in the standard textbooks", so users complain about that too [this was tried, and reverted].

evalhf has special evaluation rules, so that it could choose to not evaluate symbolically at all (which is what it is designed to do) and jump right to numerics. Which it could do, but has not been wired like that (yet?).

evalhf has special evaluation rules, so that it could choose to not evaluate symbolically at all (which is what it is designed to do) and jump right to numerics. Which it could do, but has not been wired like that (yet?).

The answer is simple: assume and solve are not integrated, ie not built to work with each other. Granted, it is not necessarily a good answer. But that is what one gets from very large software that has continually evolved for 27 years.

The answer is simple: assume and solve are not integrated, ie not built to work with each other. Granted, it is not necessarily a good answer. But that is what one gets from very large software that has continually evolved for 27 years.

I completely agree with your view of mathematical language. However, I think the point of the article is to say that interactivity is not as good an interaction mechanism as is naively thought. In other words, requiring a lot of clicking to get anything done is inferior to a similar interface that is information-rich. The context-sensitivity under discussion involves presenting the user with meaningful choices rather than simply requiring a large number of 'obvious' choices.

If you know what you are doing (ie know Maple syntax), then worksheet mode is much more efficient (for both the user and the system - there have been posts about this recently). It also has the additional advantage that the GUI does not try to 'guess' what you mean by what you have entered [which was a real problem in Maple 10, but seems to be largely under control in Maple 11]. Personally, I find the font(s) used in Document mode absolutely hideous, at least compared to the ones for Worksheet mode.

If you know what you are doing (ie know Maple syntax), then worksheet mode is much more efficient (for both the user and the system - there have been posts about this recently). It also has the additional advantage that the GUI does not try to 'guess' what you mean by what you have entered [which was a real problem in Maple 10, but seems to be largely under control in Maple 11]. Personally, I find the font(s) used in Document mode absolutely hideous, at least compared to the ones for Worksheet mode.

You're not alone - the Maple documentation does a poor job of explaining this, as do most tutorials. Even though there is a really easy way to think of it: int is a verb. Int is a noun. [And options can be thought of as adjectives, like CauchyPrincipalValue, and 'assuming' is of course an adverb!]

You're not alone - the Maple documentation does a poor job of explaining this, as do most tutorials. Even though there is a really easy way to think of it: int is a verb. Int is a noun. [And options can be thought of as adjectives, like CauchyPrincipalValue, and 'assuming' is of course an adverb!]

Full-text-search in Classic definitely uses an approximate algorithm (i.e. with stemming and all sorts of other goodies) to provide as good as search as possible. And I believe it can handle quoted strings (at least the internals can, don't know about the UI). A Maple Thesaurus should be rather easy -- especially since automatically deriving such a Thesaurus involves computing eigenvalues and eigenvectors of (large) sparse integer matrices. Maple should excel at that! That someone at Maplesoft did not just add those additional links that you proposed is very surprising indeed. Hopefully they'll track down the problem with their process, to understand this failure. [I am guessing process issue, because I know many of the people there would have "just fixed it" if this problem had actually reached their desk, because they do care].

Yes, I had to resort to 'view source' to get at the polynomial - I would never have attempted to type that in! Firefox is what I use too, and it displays ok (even on this computer, which is now my laptop with a much smaller screen).

If you take a look at the condition number of the companion matrix associated to that polynomial, it has ConditionNumber of the order of 10^27. So you need at least 28 digits to get 1 digit of accuracy in your final result. evalf[35](eval(p,y=RootOf(p,y))) is 0 to 16 Digits of accuracy, which is roughly what one expects. This isn't Maple, this is how floating-point ``works''. PS: Unlike Georgios, I don't have any problems seeing this post, but that might be because I am using a large screen at a high resolution.

Now we just have to work on passing Tom 4. Will got very many points for being the one to populate the original site, so he's got an unfair advantage! I have also noticed that the maple ranking page that the "bottom" of the first page been slowly moving up (34 was sufficient to be on that page a month ago, now it's 38). That shows that we're not the only ones who hang around here all the time!

Now we just have to work on passing Tom 4. Will got very many points for being the one to populate the original site, so he's got an unfair advantage! I have also noticed that the maple ranking page that the "bottom" of the first page been slowly moving up (34 was sufficient to be on that page a month ago, now it's 38). That shows that we're not the only ones who hang around here all the time!