JacquesC

Prof. Jacques Carette

2396 Reputation

17 Badges

19 years, 248 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 answers submitted by JacquesC

Le tout debut c'est d'avoir un modele mathematique precis - sans ca, Maple ne peut pas vraiment aider.
You don't need all the calls to assume to generate the same ''problem''. The issue here is that the powering operator (^) is a data-structure constructor which does not automatically "do" anything. Your various calls return a call to that constructor. sqrt on the other hand is a Maple function, which does do computations - and knows that sqrt(4) = 2. The fact that Maple displays them the same is certainly a huge source of confusion for many users, including advanced users. simplify just happens to know that the data-structure constructor (^) corresponds to 'powering', and so can apply various rules of powering. But that is really a sledge-hammer.
has is a purely syntactic check. Its only advantage is that it is very fast. depends is a partially semantic check, in that it rules out "dummy variables". Many things in Maple act like binders. The obvious ones and sum, Sum, int, Int, but so do the 2-argument versions of eval (and its inert cousin, the rarely used Eval), the integral transforms, ztrans, and so on. Probably some stuff in the new packages are binding operations too, yet depends does not seem to know about all of these (yet). Of course depends is not fully semantic, since in general 'dependence' is undecidable (it can be reduced to zero equivalence). So depends chooses a useful middle ground.
Have you looked at GF[ConvertIn] ?
First, I would 'float out' the Heaviside/min/max functions out, to completely separate out the geometry and the algebra. Then, one can apply techniques from computational commutative algebra for the intersection of algebraic surfaces, and various other techniques to deal with the geometry. As others have asked, an actual example would help a lot.
See this blog post" for a link to how older software often seems to perform better than newer. Clearly a lot of effort has been put on new innovative features in Maple 11 -- but less on ensuring that the old features work at least as well, if not better, than they used to.
If lb was a local in the computation that generated this result, then it will not be equal to the global 'lb'. Also, if the original lb contained assumptions (but was global), it can be tricky to save it, re-read it in, and then use subs on it. You might be better off using unapply and saving a procedure rather than an expression.
This case had no nesting, so a pure select with type as Shivnorr points out [and is rightly indignant at seeing 'hastype' recommended]. More generally, this can be done with indets(k,'sqrt') which will "pick out" the sqrt function(s). Try it on sqrt(1+sqrt(x)) + sin(sqrt(y))-exp(x^2+y^2) to see what I mean.
Appears to be in `int/cook/IIntd1`, which is a pattern-matching routine. Doing infolevel[int] := 10 clearly shows that this routine notices that there is something fishy going on, but apparently the 'fix' is incomplete. This code appears to be trying too hard to give (finite) answers, and does not detect that this particular integral is definitely divergent. A quick indefinite integral + limits shows that the ``answer'' is really infinity - a^2, which for all finite a is just infinity.
Try using 'worksheet mode' instead of 'document mode' in the GUI [or use Classic] and &^ will work fine. This is a bug in the GUI, where &^ is not recognized as a token by the equation editor. Or you can enter it awkwardly as ##### &\^ #### mod ###
Since so many people had such fun with functional solutions to this problems, I figured I would give an imperative version, but based on generators. The version below is nice because it is conceptually easy to understand.
tt := proc(LL) local T, Q, i; 
    T := combinat[cartprod](LL);
    Q := table();
    for i from 0 while not T[finished] do Q[i] := `+`(op(T[nextvalue]())) od;
    convert(Q,'list');
end proc;
Challenge: can a version using foldl but not seq be done?
The problem seems related to declaring b and v to be global, and then also assuming and unassigning them, all in the same procedure. Now, I tried to make your procedure more Maple-like, but eventually gave up since I did not really know exactly what you were trying to achieve. Which brings me to the real question: what are you really trying to do here?
You probably are in the case where a,b and c are positive - so tell Maple! You will find that assume(a>0, b>0, c>0); simplify(ln(a*b^c)); works like a charm. It just happens to be that that ``simplification'' is false in general, so Maple quite rightfully refuses to do it.
Another thing to look into is applying codegen[prep2trans] (ie 'prepare to translate') first. This routine takes care of dealing with many issues that foil codegen (and CodeGeneration).
Robert is correct that this conversion is (still) done by the automatic simplifier, so that it is pretty much impossible to stop that from happening. There are hacks one can use to be able to display such a thing, but these are not really viable since the resulting expression no longer 'composes' with anything else. In this case, combine encounters the same problem. I would not be surprised if some of the combine code actually did try to perform what you want, only to be foiled by the automatic simplifier. The reasons for this lie in the very distant past, and the reasons had something to do with efficiency (on a Honeywell machine that would probably make your cell phone look like a supercomputer). Some of these issues have been fixed in Maple (Maple V Release 2 and Maple 6 coming to mind), with a few more smaller issues stealthily fixed in Maple 8 (?), but as you can tell, some remain.
First 6 7 8 9 10 11 12 Last Page 8 of 23