In the TTY and Classic, having lone single and double quotes gives you quite clear error messages as to what's wrong. I would expect something similar for mis-using double-quotes in a 'differentiation' context in Standard too, not a really really weird message from deep inside dsolve! The error and its symptom are simply too far removed from each other, something which I personally consider to be VERY unfriendly (one of the many enemies of 'usability'). It is doubly ironic that it is a 'usability' feature which is at fault!
Note that the original question did NOT have M=A*B, but merely that det(M)=A*B and exists matrices U,V such that det(U)=A and det(V)=B, and no other relations. In other words, U.V does not have to satisfy any relation at all - unlike Robert's last post.
If you allow U and V to be of any dimension, then this is easy - take them both to be of dimension 1. The more interesting case is when dim(M) = n = degree(det(M)). Then we can find matrices U and V with dimension that of the factors A and B - basically these are just the companion matrices of A and B!
How on earth did you manage to debug this? I mean, from that error message, how could anyone else have figured this out?
How on earth did you manage to debug this? I mean, from that error message, how could anyone else have figured this out?
Where to start! First, for historical reasons of what was thought to be the most important operations in Maple (polynomial arithmetic of arbitrary expressions), and the most efficient way to store these (unordered sum-of-product representation), we see the representations of expressions as given by dismantle. dismantle gives a very precise rendition of exact memory layout.
subs, at least on old datastructures, walks the memory layout exactly and just applies itself in the most straightforward way possible -- which leads to many weirdnesses, as shown above. But since this is not so useful, for newer datastructures, subs has special code to do something more intelligent. This is great as it is usually more helpful, but unfortunately it is also inconsistent.
ToInert was designed to explicitly abstract away from some of the oddities of Maple's historical internal representation, while still remaining faithful to the actual object (ie so that FromInert could be a pseudo-inverse). So the inert form is designed to be easier to manipulate via programs, and has fewer weird artifacts (like phantom 1's).
2-argument eval is like subs, except that it knows about binding structures (ie that int(f(x),x=0..1) does not actually contain an 'x' because it is alpha-equivalent to int(f(y),y=0..1) anyways), which subs ignores.
Basically, you have exhibited proof that Maple is a 27 year old piece of software which has been developed by hundreds of people with no single underlying philosophy. One can exhibit similar proof using the interfaces too. You can generate similar reports if you dig into Microsoft software [Word, Excel, Windows itself, Visual Studio, etc]; they are quite full of inconsistencies and anachronisms too.
if there isn't an even faster formula that does not go through base 10 at all (which is hard to convert to binary) but rather going through base 16 via the
BBP formula.
student[leftbox] long pre-dates most of the niceties of Maple's plotting system!
And since the student package is supposed to be deprecated (even though it still contains routines whose functionality has not been reproduced as nicely elsewhere, yet), it is not too surprising that the code has not been maintained.
student[leftbox] long pre-dates most of the niceties of Maple's plotting system!
And since the student package is supposed to be deprecated (even though it still contains routines whose functionality has not been reproduced as nicely elsewhere, yet), it is not too surprising that the code has not been maintained.
As Roman says, sometimes there are no currently known approximate algorithms for a task, and so the code in Maple at times decides that it is better to try to do something rather than do nothing -- and so a conversion to 'exact' numbers (via convert/rational with option exact) is done, and the routine is called with the new arguments. Which routines do this, and under what circumstances, is completely undocumented. In some ways that is good, as that allows that behaviour to be changed in the future [as it should!].
In the meantime, the best advice is to try to keep floats and symbolic computations as separate as possible -- there are really very very few symbolic-numeric algorithms in existence, and even fewer of them are properly integrated into Maple. This is one of those areas where a standard university education fails most people, as that kind of issue is never brought up [mostly because most teachers are not even aware of it!]. Even though some of the textbook based on Maple do mention this, it is still a rather esoteric topic, even though in practice it affects a lot of users. It's one of those dirty little secrets about all computer algebra systems that vendors would much prefer to continue sweeping under the carpet.
Come now, Maplesoft's marketing is orders of magnitude better than what it used to be [I am talking over a 10 year time frame here]. It's not really their fault that Stephen Wolfram is an absolute genius at marketing (himself and his products)! The competition in that area is really very fierce.
My 'data' on this issue is much much too old to be of any real use. We can measure rough web presence (a proxy of popularity) via Google:
| Query | hits |
| "Maplesoft" | 231,000 |
| "Wolfram research" | 686,000 |
| maple +"computer algebra" | 89,900 |
| mathematica +"computer algebra" | 79,700 |
| +maple +software math | 96,500 |
| +mathematica +software math | 73,400 |
| (filetype:mw OR filetype:mws) maple | 25,600 |
| filetype:nb mathematica | 21,300 |
which basically says to me that indeed Wolfram Research is still better known as a corporation, but Maple's effective web presence seems to just edge out Mathematica's, numerically speaking. Quality, of course, is impossible to measure this way.
Come now, Maplesoft's marketing is orders of magnitude better than what it used to be [I am talking over a 10 year time frame here]. It's not really their fault that Stephen Wolfram is an absolute genius at marketing (himself and his products)! The competition in that area is really very fierce.
My 'data' on this issue is much much too old to be of any real use. We can measure rough web presence (a proxy of popularity) via Google:
| Query | hits |
| "Maplesoft" | 231,000 |
| "Wolfram research" | 686,000 |
| maple +"computer algebra" | 89,900 |
| mathematica +"computer algebra" | 79,700 |
| +maple +software math | 96,500 |
| +mathematica +software math | 73,400 |
| (filetype:mw OR filetype:mws) maple | 25,600 |
| filetype:nb mathematica | 21,300 |
which basically says to me that indeed Wolfram Research is still better known as a corporation, but Maple's effective web presence seems to just edge out Mathematica's, numerically speaking. Quality, of course, is impossible to measure this way.
But what I was asking is to make this 1. formal, and 2. easier, at least for some rather specialized routines (i.e. those where there is no real competitive advantage to having a good version, and a PR disadvantage to having a poor one -- like isolve). Right now, doing this is difficult (unless you have years of experience) and a real shot-in-the-dark as to whether your improvements will "make it".
But what I was asking is to make this 1. formal, and 2. easier, at least for some rather specialized routines (i.e. those where there is no real competitive advantage to having a good version, and a PR disadvantage to having a poor one -- like isolve). Right now, doing this is difficult (unless you have years of experience) and a real shot-in-the-dark as to whether your improvements will "make it".
AFAIK isolve was first coded in the mid 80s, and since then only bug fixes have been applied.
This is one part of the library where external developers would have a much higher chance of being able to make advances than what internal Maplesoft priorities would ever allow. In other words, there is room for some chunks of Maple's library to be made open source, which would result in increase competitiveness [unlike open sourcing other components, like say the GUI, which would be highly unlikely to be a positive business move].
AFAIK isolve was first coded in the mid 80s, and since then only bug fixes have been applied.
This is one part of the library where external developers would have a much higher chance of being able to make advances than what internal Maplesoft priorities would ever allow. In other words, there is room for some chunks of Maple's library to be made open source, which would result in increase competitiveness [unlike open sourcing other components, like say the GUI, which would be highly unlikely to be a positive business move].
