JacquesC

Prof. Jacques Carette

2386 Reputation

17 Badges

19 years, 72 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

Just put the constraint right in!

solve( { expand( (x-1)*(x-2)*(x+1)*x ), x>0 }, {x} );

will give you just the positive solutions.

The basic reason is that the arithmetic system of floating point numbers and integers (and thence rationals) are completely separate.  What makes sense in one case may not make sense in the other.  This is most apparent for the case of division by zero, where IEEE 754 dictates that one should have handlers, infinity, etc.  For rational arithmetic however, this is all classical mathematics, and there the "best" thing to do is to consider division by zero to be an error.

When all of this was first implemented, various schemes were tried.  All other approaches to  division by zero (other than the one you see above) was an unmitigated disaster.  The Maple library has various built-in assumptions about the "proper" behaviour of its number systems, and those assumptions most closely correspond to what I have described above.  [There were exceptions, and they had to be fixed, but generally the exceptions turned out to be mistakes anyways, so it was worthwhile doing.] 

In theory, Maple 11 is very backwards compatible all the way to Maple 6, as far as code is concerned.  In practice, some improvements may actually break older code which was written in sloppy ways.

In practice, if you are used to an older version of Maple, you may wish to use the Worksheet mode and 1D input.  This is because the GUI is extremely far from being backwards compatible.  In other words, whatever you have trained your fingers to type in older versions of Maple may not work in Document Mode and will need changing.  This rather restricted view of "backwards compatibility" has been found to be sub-optimal by many.

[sorry I don't have the time right now to develop this in full detail]

I would rewrite the sum as 3 nested loops, do common sub-expression lifting, then turn those powers into a linear recurrence at the appropriate stage.  This should greatly simplify the arithmetic complexity of the code, which should result in a tremendous speed up.  This is a bit difficult to do automatically (but look at my publications to see some examples of that too), but it makes a huge FLOPS difference.

I do not know of any automatic way of making this faster in Maple.  The best you can hope for is to use codegen[prep2trans] and CodeGeneration[C] to get things faster.

Your first example really ought to work -- otherwise Maple is very very broken.  I am guessing that you are using Standard in document mode.  Switch to worksheet mode and I believe things will get better.  Method #1 above is the 'right' way to do things. 

Note that this particular distribution can be done in closed form in Maple.

assume(m::posint, n::posint, x>0);
fdist := (x,m,n) -> GAMMA((m+n)/2)*(m/n)^(m/2)/GAMMA(m/2)/GAMMA(n/2)*x^(m/2-1)/(1+m*x/n)^((m+n)/2):
int(fdist(u,m,n), u=0..x);

m^(-1/2*m)*n^(1/2*m)*(m/n)^(1/2*m)*(GAMMA(1/2*m)*Pi*csc(1/2*Pi*n)/GAMMA(1-1/2*n)-2*n^(1/2*n-1)*x^(-1/2*n)*m^(-1/2*n)*hypergeom([1/2*n, 1/2*m+1/2*n],[1+1/2*n],-1/x/m*n)*GAMMA(1/2*m+1/2*n))/GAMMA(1/2*m)/GAMMA(1/2*n)

When you specialize it, it really simplifies a lot:

simplify(eval(%,{m=4,n=3}));

(9*(3+4*x)^(1/2)+24*(3+4*x)^(1/2)*x+16*(3+4*x)^(1/2)*x^2-9*3^(1/2)-30*3^(1/2)*x)/(3+4*x)^(5/2)

The closest you can do is with Eval, where you can do

Eval(f(x),x=5) - Eval(f(x),x=1)

which does not display very nicely, but I think that's as good as the current pretty-printer has been taught to do.

Some of the functionality is in OrthogonalSeries, while other bits are buried in `evalf/int` itself, some are in the numapprox package.

The documentation, as usual, is awful.  For OrthogonalSeries, you can blame me if you wish -- I am the one who rewrote most of the code to integrate this into Maple [it was originally written at one of the universities that does research-oriented development for Maplesoft; that code usually works, but even then written in an antique Maple style.  This is usually because this was written by students who learned their Maple style from the Maple books (which mostly are quaint in their obsolescence), from their supervisors (too many of whom stopped reading the "What's New" 10 years ago, or from their supervisor's code which tends to be very old.  In any case, I had time to modernize the code but did not have the time to do much with the documentation.  And then I moved on to the next project, and the next, and ... 

If you give Maple the definition of that function (either as a (truncated) series or via the system of ODEs/PDEs),  Maple should be able to evaluate the results.  That may not be the most efficient way to do it around the singularities, but it should still work.

  1.  Don't assign to input parameters!  The first 3 lines of your proc assign to OCs, Eqs and n.
  2. For what you are doing, use add (and drop the uneval quotes) instead of sum
  3. If I enter your procedure in Maple 11 (Classic), it seems just fine.  Are you programming in Standard using Document mode?  If so, like many others have said here: don't.  Use worksheet mode and 1D input for procedures.

A google search for "MapleTA" is very instructive.  It certainly points out quite a number of courses have used it.

The function plots[coordplot]'s job in life is to plot such "graph paper" in different coordinate systems.  If what it does is not as good as Robert's few lines of code, complain loudly...

I can't get a closed-form either, but if I convert to exponential form, then change z=exp(x)+1, this can be rewritten as int(4*exp(-a*ln(-1+z)^2)/z^2,z = 1 .. infinity).

Wikipedia's definition.  This is a nice exercise using the 'mod' operator, ie mod 400, mod 20 and mod 5 computations.  Actually, quo and rem would be better still.  I won't spoil the fun of doing this exercise beyond that hint...

You are most probably correct that the DXF feature is 'not really mature'.  There might not have been a lot of demand for it.  If you think it is an important and useful feature, you should make your voice heard by submitting many Software Change Requests.  The more focused you make these SCRs (ie one per problem, ie one for missing points, one for dotted lines, etc), the more chance you will have that some of them are fixed.

4 5 6 7 8 9 10 Last Page 6 of 23