Prof. Jacques Carette

2381 Reputation

17 Badges

18 years, 210 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

So I uninstalled the 64bit version, installed the 32bit version.  Let it upgrade to 12.02 (when 12.00 seemed to work fine).  And now Classic won't start anymore!  [Well, it starts, but it hangs].

Anyone else encounter this problem before?  I searched primes and did not see anything relevant.

While I understand that Maplesoft cannot respond to every thread -- luckily there is no such need, as evidenced by the wonderful answers provided by the community for most questions -- this one strikes me as different.

This post by Doug however is different.  It is about a serious technological problem caused by a 'feature interaction' between a decision by Microsoft and another by Maplesoft.  Since this is likely to afflict a lot of users, I am surprised that there isn't a standard response to this; even if there isn't one (yet), this thread should have caused such a response to be created, posted (likely on Maplesoft's main site for support-related matters) and then cross-posted here.

It has been a week, with nary a peep.

If one generates the list of the first 20 coefficients of the series solution to the original deq, asking gfun[guessgf] returns that the answer is hypergeom([I,-I],[1],x) which does indeed agree.  So this solution is simpler than the ones shown above. 

Interestingly, by a little coaxing, dsolve can get that - dsolve(deq,y(x),[hypegeom1]) does it, for example.  dsolve(deq,y(x),[MeijerG]); gives yet another form, somewhere in-between in term of complexity.  The method [Heun] also works, but that is neither surprising nor helpful.

In the picture you posted, there were other issues:

- in the limit case, the (italics) f overlaps the a

- in the limit case again, the arrow is 'too high' compared to the x and a

- also in the limit case, the x and a stick too far out

- in the expression palette, in the piecewise case, the < is not baseline-aligned with the x and a

- same case as above - the < is from a different font/size than the <=

- the baseline alignments in f := a -> b are screwed up in many different ways

Someone should seriously translate (by hand!) all of these into (trivial!) LaTeX and look at the resulting output to see how is should actually look, and fix all of these bugs.  I am sure there are more, but the ones above are the really obvious ones.

About a year ago, a similar question arose on MaplePrimes (can't find the exact thread right now). I investigated solve, and it became very clear that solve was really not designed to deal with such problems.  It would be best if solve immediately issued an error message rather than fooling the user into thinking it was designed to deal with such problems.

There clearly seem to have been multiple important bugs identified in this thread -- have they been filed?

This is something which support@maplesoft.com would be in the best position to handle.

This is a case where clearly one wants a piecewise answer.  The computations aren't even difficult.  Does anyone know of a CAS who can do it though?

First, this error is actually a bug in codegeneration [it internally uses a list for something which clearly should not].  You should report it.

Second, for the worksheet you posted, I believe that you could benefit a lot by:

  1. declaring (via assume()) that your variables are real
  2. using piecewise instead of signum(1,Q)
  3. using ^(3/2) instead of ^(1.5)  [these are quite different in Maple]
  4. normalize some of the intermediate results

First, Maple has this nifty 'slide mode' for doing presentations.  Isn't that good enough?

Otherwise, if you are trying to record a presentation and put on the web, there are all sorts of software to do that as well.

The new embedded components are completely GUI entities, and there is no Maple DOM, so I don't think you can "programmatically" do this.  Maplets are definitely superior that way.

Consider this closely related ODE

de3 := 20*a^2*diff(w(a),a)^2-8*a^2*diff(diff(w(a),a),a)*w(a)+w(a)^6*(a-1)*(a+1)

dsolve can't get anywhere with it. Can't get a series solution (at 0) either, only through a change of variables as above. Interestingly, using (1-u)^q works for even symbolic q, not just 1/2. Much more bizarre is the following:

dsolve(eval(de3, w(a) = ww(a)/(1-ln(a))));
                            7             3        3
  ww(a) = exp(RootOf(exp(_Z)  - 84 exp(_Z)  + 336 a

                     2      3            2      4         3      2
         - 1344 _C2 a  ln(a)  + 336 _C2 a  ln(a)  + 2016 a  ln(a)

                3      4         3      3         3
         + 336 a  ln(a)  - 1344 a  ln(a)  - 1344 a  ln(a)

                     2      2             2
         + 2016 _C2 a  ln(a)  - 1344 _C2 a  ln(a)

                         2      2                     2
         + 2016 exp(_Z) a  ln(a)  _C1 - 1344 exp(_Z) a  ln(a) _C1

                        2                     2      3
         + 336 exp(_Z) a  _C1 - 3360 exp(_Z) a  ln(a)

                       2        2              2        3
         + 1512 exp(_Z)  a ln(a)  - 504 exp(_Z)  a ln(a)

                        2      4               2
         + 840 exp(_Z) a  ln(a)  - 1512 exp(_Z)  a ln(a)

                         2                       2      2
         - 3360 exp(_Z) a  ln(a) + 5040 exp(_Z) a  ln(a)

                        2          7  2                 2      3
         + 840 exp(_Z) a  - exp(_Z)  a  - 1344 exp(_Z) a  ln(a)  _C1

                        2      4                  3
         + 336 exp(_Z) a  ln(a)  _C1 + 224 exp(_Z)  ln(a)

                      2               3      3              3      2
         + 504 exp(_Z)  a + 56 exp(_Z)  ln(a)  - 196 exp(_Z)  ln(a)

                    2                   2      4
         + 336 _C2 a  - 840 _Z exp(_Z) a  ln(a)

                            2      3                    2      2
         + 3360 _Z exp(_Z) a  ln(a)  - 5040 _Z exp(_Z) a  ln(a)

                            2                         2
         + 3360 _Z exp(_Z) a  ln(a) - 840 _Z exp(_Z) a ))

I cannot get anywhere with that answer. In particular, odetest does not wish to verify that this is an answer.

The correct answer to your question is inevitably a piecewise-defined function, as in most cases that limit crosses EllipticF's branch cuts. Maple does not seem to know these explicitly, but it at least knows the branch points:

FunctionAdvisor(branch_points, EllipticF);
  [EllipticF(z, k), z  in  [-1, 1, - 1/k, 1/k, infinity + infinity I]]

So the answer is going to vary depending on where exactly a and r are in the complex plane. I am not even sure that the limit will exist for all complex a and r.

This isn't that hard a modeling problem.  You just have to be careful to set up all of the equations for all the parts.  Obtaining a solution is potentially quite a bit harder.  You should at least set up the equations yourself -- then we might be able to pitch in and help.

AFAIK, there is no pre-packaged finite-difference method in Maple, or at least nothing that advertizes itself as such.  But why do you insist on that particular method?

If you were to post your exact problem (the equations that define the problem), people here might be able to help.  As it stands, you are asking for too much.

1 2 3 4 5 6 7 Last Page 2 of 23