JacquesC

Prof. Jacques Carette

2401 Reputation

17 Badges

20 years, 89 days
McMaster University
Professor or university staff
Hamilton, Ontario, Canada

Social Networks and Content at Maplesoft.com

From a Maple perspective: I first started using it in 1985 (it was Maple 4.0, but I still have a Maple 3.3 manual!). Worked as a Maple tutor in 1987. Joined the company in 1991 as the sole GUI developer and wrote the first Windows version of Maple (for Windows 3.0). Founded the Math group in 1992. Worked remotely from France (still in Math, hosted by the ALGO project) from fall 1993 to summer 1996 where I did my PhD in complex dynamics in Orsay. Soon after I returned to Ontario, I became the Manager of the Math Group, which I grew from 2 people to 12 in 2.5 years. Got "promoted" into project management (for Maple 6, the last of the releases which allowed a lot of backward incompatibilities, aka the last time that design mistakes from the past were allowed to be fixed), and then moved on to an ill-fated web project (it was 1999 after all). After that, worked on coordinating the output from the (many!) research labs Maplesoft then worked with, as well as some Maple design and coding (inert form, the box model for Maplets, some aspects of MathML, context menus, a prototype compiler, and more), as well as some of the initial work on MapleNet. In 2002, an opportunity came up for a faculty position, which I took. After many years of being confronted with Maple weaknesses, I got a number of ideas of how I would go about 'doing better' -- but these ideas required a radical change of architecture, which I could not do within Maplesoft. I have been working on producing a 'better' system ever since.

MaplePrimes Activity


These are replies submitted by JacquesC

A long time ago, there was a half-hearted attempt to ``rationalize'' the Maple naming scheme. One of the pre-conditions to being able to implement any naming-scheme was a way to be able to distinguish between various kinds of names (system, constants, inert, etc). It was agreed that % would serve as the prefix for inertizing, so that %int would replace Int, etc, leading to much less confusion as well as much more regularity; it would also help clean up the issue that some routines return inert versions, others return unevaluated, while others return new data-structures, all when denoting essentially the same idea. Some of the features needed for a better naming scheme were (partly) implemented (like %, and TypeTools). But at some point, this kind of radical infrastructure work became unfashionable, and was dropped. Of course, this only ever lasts so long, and Maple 11 has seen serious infrastructure work (for examples for Threads and making many more packages into modules) done behind the scenes. It is even possible that the %-prefix got documented somewhere, but I really can't recall where that would be.
As has been discussed before, a number of Maple computations are quite dependent on external factors, which means that answers can vary from session to session (but are, naturally, supposed to be mathematically equivalent). So I would try this integral over and over again (with restart in between) and I would guess that the answer will oscillate. As far as MeijerG identities, Maples actually knows a lot of them -- but they are all buried deep inside int subroutines. This is one of those deep Software Engineering issues. Maple's own FunctionAdvisor is completely independent of all other functionality (like int, simplify, discont, etc, etc), so that there is a lot of knowledge duplication going on there. As far as I am concerned, that last bit (the knowledge duplication) is one of the biggest open problems in how to ``engineer'' a system like Maple. All the systems which I know of have this same problem, where a huge amount of mathematical knowledge is (partially) duplicated in different components. But because this really only shows up after a system has been worked on for at least 15 years, and has reached a certain critical size, none of the ``research'' systems really had to face this issue, only the commercial systems. And, of course, this kind of issue is not ``commercially'' interesting to tackle, at least not until it actually makes a system hard to expand. Which it won't -- it will merely slow down development, more and more as years go by. From talking to some developers, this actually happened to Mathematica some years ago; I would love to talk to them again, since it seems like they might have gotten over that hurdle in the last couple of years, and I would really like to know if they really have, and if so, how.
Use showstat(plots[implicitplot3d]);, which leads you to showstat(`plots/iplot3d/implicit3d`);, which is the code that does the bulk of the work (and does what Robert describes). One of the fantastic advantages of Maple over all of its competitors is that the vast bulk of the Maple routines are user-readable like this. This advantage has been under-leveraged lately, but it remains a powerful lure for any serious user of powerful mathematical tools.
It worked quite nicely (in .m form, not text form, where it never worked satisfactorily) up to at least Maple V Release 5. Then with modules being introduced in Maple 6, this feature started to 'bit rot'. Apparently, it rotted to the point where this "global save" was completely removed. For modern Maple, this feature really does need to work with a .mla rather than a .m, but given that, it should be possible. A working "save current working state" is a very sensible feature for a product where some computations can take hours even days!!!
It worked quite nicely (in .m form, not text form, where it never worked satisfactorily) up to at least Maple V Release 5. Then with modules being introduced in Maple 6, this feature started to 'bit rot'. Apparently, it rotted to the point where this "global save" was completely removed. For modern Maple, this feature really does need to work with a .mla rather than a .m, but given that, it should be possible. A working "save current working state" is a very sensible feature for a product where some computations can take hours even days!!!
If you are creating Hermitian matrices, you should tell Maple, via the shape=hermitian option to the Matrix constructor. This should allow LinearAlgebra routines to choose even better, faster routines for the various tasks. The next thing would be to do an actual profiling of the code, to see where the time is spent - sometimes one gets nasty little surprises, where minor changes can have drastic effect.
If you are creating Hermitian matrices, you should tell Maple, via the shape=hermitian option to the Matrix constructor. This should allow LinearAlgebra routines to choose even better, faster routines for the various tasks. The next thing would be to do an actual profiling of the code, to see where the time is spent - sometimes one gets nasty little surprises, where minor changes can have drastic effect.
After the tremendous initial investment into mapleprimes (see the many many posts by Will and Tom 4), and a very pleasant amount of unofficial continual support (yourself, Scott03, Dave L, Allan Wittkopf, pchin, and many more), it is sad that there does not seem to be any more 'official' time being put into mapleprimes. It would only take a couple of hours a week for a knowledgeable Maplesoft staff member to 'catch up' to mapleprimes posts, identify threads that seem to be bugs, and file those officially (and say so on the site). Doing it once a week is probably the right frequency too. This is, IMHO, the biggest real 'missing piece' to this site.
After the tremendous initial investment into mapleprimes (see the many many posts by Will and Tom 4), and a very pleasant amount of unofficial continual support (yourself, Scott03, Dave L, Allan Wittkopf, pchin, and many more), it is sad that there does not seem to be any more 'official' time being put into mapleprimes. It would only take a couple of hours a week for a knowledgeable Maplesoft staff member to 'catch up' to mapleprimes posts, identify threads that seem to be bugs, and file those officially (and say so on the site). Doing it once a week is probably the right frequency too. This is, IMHO, the biggest real 'missing piece' to this site.
Can you tell us exactly what you are doing? I mean, how you start the application, and which keystrokes you are entering.
While there are indeed hidden 'true' in some structures, there are many many more hidden 1s in "expressions". subs(1=2,some_complex_expression) is frequently rather fun. Of course, subs(1=true,...) or even better, subs(1=NULL,...) can produce rather spectacular results!
There really ought to be some visual feedback that Maple is interpreting your expression in ways differently than what is being displayed! What surprises me most is not that this bug exists, but that you have not been contacted officially by Maplesoft for your original worksheet, so that they can reproduce and fix this bug. Without this, that bug will remain and not be fixed, waiting for the next unsuspecting user to hit it.
There really ought to be some visual feedback that Maple is interpreting your expression in ways differently than what is being displayed! What surprises me most is not that this bug exists, but that you have not been contacted officially by Maplesoft for your original worksheet, so that they can reproduce and fix this bug. Without this, that bug will remain and not be fixed, waiting for the next unsuspecting user to hit it.
Just do save "myfile.m": and that will save everything in current memory (including system routines though). At least, this used to work for a very long time! Perhaps this very useful feature has been disabled? That would be a real shame, a serious break in backwards compatibility. Robert Israel's suggestion is probably the better way to do this. What is more remarkable is that this is not a standard function in Maple already. But this goes along the lines of comments I have already made several times already: the designers of Maple 9, 9.5, 10 and 11 have been worried about the beginner user quite a lot, but it seems that little effort has been made to ensure that the "active" users of Maple as a powerful environment (instead of the uses of Maple as a glorified calculator for education or trivial engineering problems) is smooth. Which is somewhat disconnected from their marketing headlines, though not from the actual demos and other ancilliary material which is mostly glorified-calculator stuff. The heavier uses of Maple by people solving larger problems can still be found on the Application Center though.
Just do save "myfile.m": and that will save everything in current memory (including system routines though). At least, this used to work for a very long time! Perhaps this very useful feature has been disabled? That would be a real shame, a serious break in backwards compatibility. Robert Israel's suggestion is probably the better way to do this. What is more remarkable is that this is not a standard function in Maple already. But this goes along the lines of comments I have already made several times already: the designers of Maple 9, 9.5, 10 and 11 have been worried about the beginner user quite a lot, but it seems that little effort has been made to ensure that the "active" users of Maple as a powerful environment (instead of the uses of Maple as a glorified calculator for education or trivial engineering problems) is smooth. Which is somewhat disconnected from their marketing headlines, though not from the actual demos and other ancilliary material which is mostly glorified-calculator stuff. The heavier uses of Maple by people solving larger problems can still be found on the Application Center though.
First 64 65 66 67 68 69 70 Last Page 66 of 119