JacquesC

Prof. Jacques Carette

2386 Reputation

17 Badges

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

Certainly some of it was to provide myself some entertainment.  But a fair amount of that was obtained through actually answering questions, concentrating on the ones where I had special knowledge that few others have. 

Take a look at Sage's syntax and its leveraging of Python -- that is very Maple-like.  The fundamentals of the language (Python + Sage extensions) are quite close to Maple's, as is the paradigm of using an interpreted language to 'script' a set of fast base functions.  While the Sage developers may now be influenced by other systems, their basic system is essentially a copy (at the design level) of Maple, whether they like it or not.  Personally, I find this very disappointing, since we've learned a lot about how to build CA software in the last 25 years!

Current research in parts of Physics does strike me very much as weakly typed.  This certainly allows you to experiment a lot more, since you don't need to be concerned with small stuff like "making sense"... 

Over the years, I have seen the benefits of both certainty (through solid foundations) and free-for-all experiments.  I am interested in building something which allows both.  And, by the way, the only 'solid foundations' systems (as far as I am concerned) that are 'real' are Coq and Isabelle; there are a number of smaller systems with solid foundations, but their libraries are too small to be interesting.  Of course, both those systems are notoriously hard to use as well as being quite slow for doing computations.

The degree of typing picture you refer to is quite good.  To be more precise, at 'static' typing, which means typing at 'compile time'.  The languages I like these days (Haskell and O'Caml) would fit best in the extreme upper right corner (although, to be fair, Agda 2 would be even further out).  Maple would fit right in between Tcl/Perl and VB, fairly high up [not always a good thing].  That Mupad is more typed than Maple and Axiom further still is indeed true.  Mathematica is essentially the same as Maple, as is Macsyma on the 'types' scale.  The Wikipedia article is very misleading because it does not differentiate between static and dynamic typing!  On the dynamic typing scale, Maple is extremely strongly typed -- its type system is Turing-complete!

As far as denotational semantics is concerned, you are correct, it does seem backwards!  But that is the fundamental issue with symbolic computation -- it is all about intensional statements being interpreted as if they were actually extensional.  People use Maple as if it were about actual mathematical objects, while what Maple really does is 'symbol shuffling'.  You need strong reflection theorems to show that these coincide.  And we know that these indeed coincide for first-order logic and algebra, and these theorems are 'unknown' for analysis and geometry (even though lots of counter-examples are well-known to naive reflection theorems).

I'm not sure how much I can/should say, but the contract is explicitly structured in that direction (i.e. keep the original management team in place and no abrupt changes in direction).  I don't really want to say more than that (even though it would be comforting to current Maple customers!) because it might also give too much information to the competition, which would not be good for the company either.

I'm not sure how much I can/should say, but the contract is explicitly structured in that direction (i.e. keep the original management team in place and no abrupt changes in direction).  I don't really want to say more than that (even though it would be comforting to current Maple customers!) because it might also give too much information to the competition, which would not be good for the company either.

I looked at your equation.  There does not seem to be any symmetries (at least using the form you have given), so that the roots would correspond to the general form of the quartic -- completely useless as was previously posted.  Using the implicit form (RootOf) is most definitely the best thing to do.

Can you tell us what you're really trying to do with the roots of this equation?

I looked at your equation.  There does not seem to be any symmetries (at least using the form you have given), so that the roots would correspond to the general form of the quartic -- completely useless as was previously posted.  Using the implicit form (RootOf) is most definitely the best thing to do.

Can you tell us what you're really trying to do with the roots of this equation?

The <maple> tag should be extremely useful -- but as people have noticed (and made many comments about), it really isn't.  It's completely hit-and-miss whether the output will show up, if it will be truncated, etc.  And it is uniformly of low quality (fuzzy fonts, low-res parentheses, etc, etc) when it does work.  The quality of typesetting in Classic, WebEQ or built-in to Mozilla (for MathML) is better. Dare I say it, the competition's typesetting is nothing to rave about, but it's better than what we have Primes. The nLab seems to have achieved good typesetting on the web (see example1 and example2).

So, instead of taunting us with mention of numbers and stats, what about posting some (Maple-generated, naturally) graphs of some Primes-related stats?

Yes, those are definitely the communication channels I was speaking about.  I have seen some documentation on (some) streams for example in the help page for streamCallBack.

But yes, you're right, most of the INTERFACE_ streams seem to be undocumented.  Using a few tricks (with march and ToInert), it should be possible to at least see all the ones that the (current) library uses.

That would be kind of fun to work on -- assuming infinite time, naturally.  Using WxHaskell , and OpenMaple should make this quite feasible (as well as borrowing from wxMaxima).  It would be an interesting project for a Master's student, to create an alternate GUI with "core features" needed for accessing the Maple language in a pleasant environment, without all the extra features of Standard.

I tried to send you a message through this site, and apparently you don't exist!  Have you ever received private messages on mapleprimes?

Those are really good questions.  I can definitely answer the first one but the answer is quite complex, so I'll have to delay that until I have a decent block of time.  But the good news is that I have bits and pieces of code here and there which provide a decent approximation to the problem.  On the second one, I've answered as best I could.

The picture you paint above (i.e. the updated view with various changes) is what I know too.  The one thing I can add is to look into the details of the API for OpenMaple and ExternalCalling.  These give you details of the "communications channels" that exist in/out of the kernel.  These are (essentially) the channels that the GUI uses to communicate with the kernel.  The other thing to do is to take a look in the bin (or bin.win) directory and look at the libraries there (.so or .dll depending on your platform).  It is fairly easy to guess what most of these do.  You can use various free tools to peek into these and get a listing of the functions provided.

However, this might be a good post for the community to gather information on what each of these external libraries do.

The question mark in my original title was most deliberate.  The pros and cons of each method needed to be made explicit.  And now they are.

Sometimes (but most definitely not always!) the newer method really is better.  But to fully understand that, one must be able to see what was wrong with the previous method.

The question mark in my original title was most deliberate.  The pros and cons of each method needed to be made explicit.  And now they are.

Sometimes (but most definitely not always!) the newer method really is better.  But to fully understand that, one must be able to see what was wrong with the previous method.

5 6 7 8 9 10 11 Last Page 7 of 119