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

Any 'proof' needs to somehow introduce ln(a) in a non-artificial way.  Using derivatives, as Alex points out, is not the way.

However, we know that a^h = exp(h*ln(a)).  If we expand that exp into a series to 2 terms, we get 1+h*ln(a)+O(h^2).  Now we're nearly there!  Plug that in to the limit expression and we get

(1+h*ln(a)+O(h^2)-1)/h = ln(a) + O(h), which is a valid computation as h>0.

FAIL is not wrong, although it is also not the best answer.  FAIL says that Maple can't do this (yet).

Those things made Maple geeky, not cool.

The basic issue is that those early adopters who were visionary enough to see Maple's potential in the 90s are not that big a market.  And so, to widen the market, a move away from geek-cool to mainstream terminology was a reasonable move.  The MathWorks did the same thing with Matlab.  And Mathematica was only geek-cool when it released on the NeXT.

I am pretty sure that most of the Maplesoft executives will see your claim that Maple stopped being cool in the 2000s as a sign of success!

On problems like this, which are essentially just manipulation of lots of terms with nice normalization properties, Maple used to really shine.  It was much faster than Mathematica, which translated to a lot of other parts of Maple that are manipulation-heavy also being faster.

Now, it could be that this one algorithm is badly written, so suffers from massive overhead.  Or it could be that the state-of-the-practice has moved, and Maple has not.  What about other systems? 

First, Mathematica's answer is not particularly useful.  The first one is 0 for w>0, which seems weird.  The second one has all 3 of its hypergeometric functions formally divergent -- which is not really surprising!

Why are you trying to find the Fourier transform of this function at all?  Especially since it is unlikely to be well-defined.

Your approach however, to splitting f(t) into pieces, seems like a good idea.

If you want to try a purely formal method, I would get MGfun (from algo.inria.fr), then follow Salvy's method.

Your MyProc will look like

proc(args1, args2, args3, h)
    local v1, v2; # and more as needed

    statements; # these set things up
    proc(x) ssss end proc; # ssss uses v1, v2 and also args1, args2, etc
end proc;

This is how dsolve/numeric works.

Try the 'size' option.  But don't expect miracles!

Instead of fooling around with op, why not use the solution directly?  For example

x1 := eval(x, e[1]);

will work just as well. It will work over expressions in x too, which is the whole point of having the output of solve being in that format, it can be fed as input to eval as is.

convert/base will give you, for a given integer, a list of the digits in any base.  Getting a polynomial from that is an easy Maple exercise.

Without an actual system for us to 'play' with, we are not likely to be able to help you.

I agree with what has been previously said on this topic.

Do notice that you are not the 'questioner' with the most points!  What this does show though is that you are quite serious about learning Maple.  I tend to go out of my way to give thorough answers (when I have them) to questions from 'serious learners'.

The short answer is no, it can't be done.

The long answer is that if you are willing to use functions other than the Maple built-ins (like * and +), or other similar work-arounds, it is possible [there are many posts on this site showing such hacks, search for them].  But the results are a lot less appealing.

Now, it is possible to do something that comes close, via using modules and overloading.  You'll find information about this in the Advanced Programming Guide.

I believe that OrProp(RealRange(2,5),RealRange(3,6)) is what you are after. This relates to a post of yesterday - RealRange is not a set, but a property.

In Maple, 2..5 is closer to being an interval (although for obscure historical reasons, the interval arithmetic function evalr uses INTERVAL(2..5)).

See my blog post about using dsolve on this problem.  While I do not show a complete solution, at least things get 'closer'.

The Maple Application Center is thought to be useful enough to people that they won't mind a bit of pain to get to it.  The pain is there because 'becoming a member' is a (small) barrier to entry that qualifies you as actually 'interested in Maple'.  That is extremely valuable marketing information for Maplesoft.  They use the list of members to populate various mailing lists for their marketing material.

If the barrier is higher than the reward of access, then it becomes self-defeating, and the usefulness of the Maple Application Center nose-dives. 

The membership-based idea was quite popular on the Internet a few years ago [and still is in some niches].  But in other circumstances, even such a low barrier has been found to be ``too high'' and removed.  It is probably time for Maplesoft to revisit that idea - is their need of email addresses for spam campaigns more important than having more Maple users find the information they need to properly use Maple to its fullest?

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