Gaston Gonnet
1699As many here know, Gaston Gonnet is a co-founder of Maple. SIAM, in its History of Numerical Analysis and Scientific Computing project, has now published a very long interview with Gaston. For those who like a good yarn, as well as details of the history of Maple and Maplesoft, it makes for fascinating reading.
My favourite quotes are:
By and large, for most people input is still ASCII. For the output, you don’t want it to be ASCII. I would say that if you are an unsophisticated user, you may want to use the input with standard math. But if you really want to use the input many times you will hate the slowness of using the mouse in a graphical input. You really want to type in things, in ASCII.
and
In Canada, professors are liabilities; in Switzerland, professors are assets.
If you have the time (it is over 80 pages long!), have a read, it really is quite fun.
- JacquesC's blog
- Login or register to post comments
- Try Maple 9.5
11 min 53 sec ago - Thanks a lot.
I have
6 hours 36 min ago - This site
6 hours 40 min ago - Great improvement
6 hours 47 min ago - 64-bit Ubuntu
7 hours 51 min ago - misunderstood
8 hours 23 min ago - java -version
8 hours 24 min ago - Exactly
8 hours 17 min ago - Standard vs. command line
9 hours 16 min ago - sort of
9 hours 17 min ago
- Does Maple 12 support Ternary diagrams?
- Table from procedure
- Maple Mentor Awards: The Big Kahuna
- The actual architecture
- new package adoption
- Conjectures ripe for Maple experimentation
- overloaded operators
- poll: change in Maple that you want most?
- The future of FourierTrigSeries package
- Maple 12.01 is now Available
Comments
Maple versus Mathematica
On p. 2 of the interview the following passage appears: "Since then, he feels that Maple has lost its battle with Mathematica."
That is interesting. I guess I have to read on to find out exactly why. Does he reveal that?
Market share
I believe that he means in terms of market share, as well as "mind share". Many many more people have heard of Mathematica than of Maple. Of course, that may be an entirely irrelevant statistic: when interestect with potential users of these products, it is quite possible that the statistic is not so skewed anymore.
He basically bemoans the issue that very little attention was paid to interface issues early on. He is also mystified by the "fact" that the market seemed to prefer a product that looked good over a product that was correct. This was one of the hard lessons -- that marketing trumps technical matters.
This has to be taken with a big grain of salt. Advanced users of Mathematica express very similar frustrations as Maple users over interface issues. Features that are easy to sell and easy to demo are not necessarily useful features!
My statistics
collected while I was "ambassador" of Maplesoft in Argentina in the 90's clearly shows that only a minority of physicists, astronomers and engineers were users of CAS and of those, the large majority used Mathematica. If they have ever heard of Maple, their apriori perception most frequently was (aparently) of something of second rate. And the unavoidable first question was "how does it compare to Mathematica?".
The same pattern seemed to hold in neighboring countries with the exception of Brazil.
On the other hand, among mathematicians, the distribution was more even.
Most probably, this distribution reflects in each case the distribution of usage among their colleagues in the northern hemisphere, from where these copies came.
I partially agree
I partially agree with you.
Probably also in Italy Mathematica is more known than Maple among physicists, but nearly equally among mathematicians.
However, I think that the difference is not very big, moreover in the latest years Maple seems to have gained terrain.
In the libraries of my University (Florence) the books about Mathematica are perhaps more common, but an introduction to Maple and Maple programming is actually included in some courses.
As for me, I feel more confortable with Maple.
Wrapping over content
It is comforting to read that "He is also mystified by the "fact" that the market seemed to prefer a product that looked good over a product that was correct."
In my opinion this state of affairs holds also today, probably even stronger. I guess that that is what happens with every company that becomes owned by stockholders. In this respect the following excerpt from
http://mathworld.wolfram.com/about/erics_commentary.html,
in which Eric W. Weisstein comments on the lawsuit served on him and Wolfram Research in the spring of 2000 by CRC Press LLC, is highly interesting, I think:
In our world in which consumers seem to become ever more desperately dependent upon shallow gadgets and accessories this depressing state of affairs seems unavoidable, I think, and probably will only become worse in the future - if not instead the global economy collapses as a direct consequence of the fact that the (completely mad) paradigm of sustained economical growth is fundamentally inconsistent with our planet being a materially finite system.
But I am being lead astray. Back to the beautiful world of mathematics and theoretical physics ...
Semi-private
Note that Maplesoft itself is "semi private". From the perspective of the law it is not a public company. However, the company structure has a (largish) number of shareholders how own the company, and vote on who the board of directors is. Once in a while, the company issues dividends to those shareholders when it is profitable. The board of directors, along with the CEO, decide whether the corporation should go for the "long term" or the "short term". Which it is can best be seen by the evolution of the main product, Maple, and the introduction of the plethora of side-products over the past few years. Whether this is good or bad really depends on whether you are a (major) shareholder of Maplesoft or a heavy user of Maple.
Thanks
Thanks for this insight into the structure of MapleSoft. I can only agree with you on the last sentence of yours.
JacquesC, you may be correct -
JacquesC, you may be correct, but my preferred method is the mouse.
Most people who assist in this forum also seem to prefer your method of input, however it would seem to me to still be difficult to determine the preferred method by the majority, since it is first difficult to determine what group of people comprise the majority, and second, there is a relatively small minority of users of all types who actually participate within this forum.
The quote was from Gaston
It is important to note that the quote was from Gaston - I just happen to like it because it reflects my personal opinion for my own use of Maple. But I have a definite usage style: I am a ``power user'', who does not use Maple as a glorified calculator, but rather as an advanced productivity-enhancing tool. Pointy-clicky features definitely allow more people to draw more power out of Maple. But that merely moves the bar from glorified calculator to super-duper calculator. That usage mode of Maple can, at best, draw out about 20% of Maple's true power. To get at the rest, you need to dig in deeper.
Note that I am not against pointy-clicky features. Some of them even enhanced the productivity of power users. The best example is Microsoft's last 2 versions of Visual Studio. Using F# in Visual Studio is definitely better than using it old-style (with a text editor and a command line). The features provided by Visual Studio are definite productivity enhancers for serious programmers.
I think I understand
I suppose I'm of the same or at least similar persuasion. One thing I'd like to see, is a more efficient means of entering large numeric data. For example the following little "squiggle", scratched out on a touchpad, could represent the numeric value "98765932" - a lot quicker than punching it out on a keypad. Perhaps, someday it will.
I don't think I understand
Why should that squiggle represent 98765932 rather than 98765933?
If a squiggle is going to be able to represent an arbitrary natural number of up to 8 digits, then there must be at least 10^8 different possible squiggles, distinguishable both to us (the makers of the squiggle) and to the machine. I think for most people, accurate squiggle-making at the required level of precision would turn out to be more difficult than typing it on a keypad.
the squiggle - Robert (updated)
You may have missed the idea. The squiggle would not represent numeric data - the drawing of the squiggle would. The movement across the x/y of the touchpad would have created that numeric data.
With that in mind, there are numerous ways to accomplish this. One is simply to have the size of the increase/decrease depend upon the X position and either position or velocity of the Y position. For example at a low positioning of Y and increase in X, there would be an increase in the lower digits. Increasing Y (while still moving along the X axis) would create an exponential increase in the upper digits.
I should have had something to demonstrate before mentioning this, but I just now made a simple application (Windows) giving an idea:
2timv.com/misc/NumChng.zip ( there is a windows executable within the archive not a maple worksheet )
That application will require the installation of the .NET 2.0 environment to run. If you don't have it and really want to run it, I've created an installation source that installs the .NET environment as well as the application at the link below:
2timv.com/misc/numApp/publish.htm
I designated specific regions in an attempt to simplify the example. The rate of increase within any region (not in my example) could be fine tuned by simply holding down a particular keyboard key, so the rate of increase, even at the smallest level, could just creep along. Keep in mind that the number shown could just as easily represent 98.765932, so the rate of increase for the lowest particular digit of interest could require a great deal of movement anyhow. The decimal point location could be placed when finished, so during construction it could be interpretted however you please.
Rather than the method shown in the example, I think a better model would be to draw a plot as the data is created, and then the movement over the pad in a reverse direction could just as easily be made to automatically backstep (undraw the plot) to decrease the value of the numeric data.
The sample is just thrown together, only about half works, is very sloppy, etc, but should be enough to give an idea of what I'm thinking. If anyone is interested in any of this, I can perhaps make a better example and add it to my blog rather than take up too much space within this one.
Very interesting
Thank you for the link, Jacques, it has been an interesting and useful reading.
I'd like to ask you two question, but, please, feel free not to answer me if you find them unpleasant.
1) If Gonnet had taken control on Maplesoft on 1994, do you think that Maple development in the next years would have been very different ? Would Maple and Maplesoft be very different now ?
2) I'm just a simple user and I don't know (except for some basic concepts like those found on Maple Programming Guides) how a CAS works internally, I don't know algorithms and programming tecniques to build a software like Maple. I read that Gonnet said that "code ages" and I found his statements convincing. You are an early developer of Maple, a power user, a tester and one of the greatest experts of CA in all the world: have Maple and other CAS significantly changed internally or are the differences in their engines quite small and simply new features have been built on top of them ?
Thank you.
Have a nice day.
Gabriele I.
Belated reply
Last week was really busy for me, so now is the first time where I have a moment where I can answer this properly.
1) Yes, I am absolutely convinced that the next few years would have been very different; Maple and Maplesoft would be very different. Would 'different' mean better? It is possible. But I did work at Maplesoft for a time when Gaston was trying to 'direct' the company and its development remotely from Switzerland. That was not a happy time for the employees, who were extremely resentful of having someone who only knew bits and pieces of the issues make sweeping decisions "from on high". The decisions may have been right in some cases but we certainly felt like some of them were absolutely wrong.
For example, Gaston for a very long time prevented lexical scoping from being implemented in the language. He said he just didn't see the point, and it would slow down Maple unecessarily. That was one of the first thing that was implemented once it was finally possible to do so. AFAIK, Darwin has lexical scoping now, as Gaston saw the benefits [and that it could be implemented at no real efficiency cost].
2) Long before Gaston Gonnet, David Parnas wrote about Software Aging (online version). That paper is an excellent read.
Maple is now 28 years old - and some of the fundamental decisions of the early years are still there. Some of those decisions were brilliant, others were not. However many of those decisions were made within the context of what was well-known in 1980 [ie state-of-the-art circa 1973] by the people doing the actual work. Remember, you can't expect experts in data structures and computer algebra to also be experts in programming languages and software engineering, right? So Maple has indeed aged quite a lot. Every single force documented in Parnas' paper has acted on Maple. [The same is true for Maple's competition too!]
To answer your fundamental question: no, the internal workings of CAS systems do not change significantly once these systems reach the age of 2 or 3 years old. Very significant new features (Threads very recently, modules longer ago, etc) can be added, but a set of a dozen or so fundamental decisions (basic data-structures and their implementation, garbage collection strategy, basic semantics of the language, general syntax of the language, structure of the language interpreter, the interaction paradigm, abstraction and information hiding tools, the meaning of some concepts (types, symbols, variables, ...), etc) become fixed. Many of the decisions taken on those issues between 1980-1985 were excellent in the context of those years. Unfortunately, a number of these have 'aged' significantly, so that a new system would most definitely choose otherwise.
The main reason that the Computer Algebra landscape only has Maple and Mathematica as the only viable competitors is that building a decent system seems to require around 100 person-years, and take at least 8 elapsed years to get something stable. One can build a nice system for a smaller niche in less time and effort, but not something as broad as these two. So that this a huge barrier to entry. And because the competition does not stand still, attempts at breaking in (MuPAD) did not succeed [though there are a host of other reasons why MuPAD did not succeed]. That is also the same reason that Matlab is pretty much alone in its field (Scilab notwithstanding), even though it is even older [and it shows].
Addendum
I should have made it clear that the fact that the core design decisions behind Maple can no longer be changed does not mean that Maple cannot evolve or isn't evolving. From looking at what is done in each release, it should be quite clear that it is definitely evolving. We can certainly discuss (and often have) whether this evolution is 1) fast enough, and 2) in places of interest to [current] Maple users.
What it does imply is that some avenues of evolution are closed. But in some ways, it is not clear how much that really matters. For example, the current design decisions don't really restrict how good a symbolic integrator or a symbolic differential equation solver you can write in Maple. Granted, some of the internals may be sub-optimal, but that has no real effect on whether an answer canor cannot be computed. At worst, it affects performance.
improving the internals
The internals of Maple can still be improved. I think the best way to scale the system is to develop special purpose high performance libraries and call them for large problems. It also helps to add "programmer packages" such as LinearAlgebra:-Modular that allow Maple developers to access high speed compiled code. With packages like that you can (carefully) code a high-level algorithm in Maple and get 90% of the speed and efficiency of C.
what about assume?
I find curious that no mention is made in this interview to the 'assume'
facility. In the article "Simplification and the assume facility" by Robert M
Corless and Michael B. Monagan, MapleTech vol.1, num.1, p.24 (1994),
references 6 and 7 are two articles by Trudy Weibel and Gaston Gonnet dealing with the design of this facility, I think.
For me, the handling of properties is a very important issue. But clearly it
was not included in the initial design of the system. Sounds to me that it
was made as a needed patch in the way that it was possible at that time. And
that now it could be implemented better, but it will not because of some of
these aging issues.
On the assume facility
[My guess as to] why assume and many other things are not discussed in this interview: to have done so would have made it 300 pages instead of the (already long) 82 pages it is. Gaston (and his ex-student Trudy Weibel) were indeed the original designers of assume, with Gaston (re)implementing the whole facility. But Gaston also wrote many other significant parts of Maple - he was extremely productive, and had a flair for knowing which facility was core to the rest of the system. He often did not implement the pieces of Maple that were most user-visible, but he very frequently implemented those pieces which were foundational for much of the system. So his design decisions mattered a lot.
You are absolutely right that the implementation of assume as it currently stands is a patch on top of Maple. Based on what was available at that time, it was certainly a "local optimum" implementation. Even Gaston has stated (later) that if attributes had been available (something he also implemented), maybe that would have been a viable implementation mechanism. A new system, implemented from scratch but with these issues in the original requirements would indeed result in a different design. What that design would be, I am not sure if anyone has really thought it through, since it clearly would never happen. [The end result would not be 'Maple' anymore].
efficiency issues
I think that the disregard to the issues of efficiency in the machine-human
interaction was an important error.
I have been using Reduce, Derive and Mathematica 1.x during the late 80's and early 90's. They all had ascii output (2D but ascii). The main problem that I
had at that time was the difficulty in the interpretation of the results
whenever the output became "large".
One way was to print the output and transcribe it by hand. This could be a long,
painstaking and error prone process. With the advent of Mathematica and 386's, in 92-93 I used to output in TeX form, saved to a file, repeated edit/tex/dvi view until I got it display in multiple lines, and then printed (in a dot matrix printer). In ten minutes or so I could have the output nicely printed...
So, it was largely irrelevant for me whether the CAS took 0.2s or 2s to
evaluate the integral.
At that time I used what I could get and I did not know that typesetted output
was possible but developers did not cared about it.
I think that the first CAS that I have seen with 2D typesetted output was
Maple V Release 2 in mid '93. It was a kind of revolution!
Pretty printing
Maple already had an ASCII pretty-printer from Maple 4.2 [when ?updates,v42 documents it was improved]. Clearly, the pretty-printer pre-dates that.
The 'latex' command existed at least in 1992.
In Maple V Release 2 under Windows, what you would have seen is probably my port (from the X11 version of Maple) of Tim Tyhurst's pretty-printer. That was a fair bit of work, as the underlying font metrics in Windows work quite differently than under X11. Tim's was already Maple's 3rd pretty-printer! He based his work on what David Clark had done, who had written his "in anger" at how bad Maple's first pretty-printer was. As far as I know, the pretty-printer in Standard is the 6th that Maplesoft has written, where Tim Tyhurst had written the 4th (part of the equation editor in Classic -- few people know it has one!). The 5th was never released. Maplesoft owns the rights to yet another pretty-printer, which used to be used in MapleNet, but I am informed that it no longer is. [Which is too bad, as I think it produced better results than the curren one!].
it was at a Mac
of a mexican colleague that I saw for the first time Maple V Release 2 in mid '93. Only some months later I have tried the Windows version. Here we had only PCs then.
In fact, in '89 I have missed the opportunity to try Maple. I have attended the First Brazilian School on Computer Algebra in Rio de Janeiro. It run parallel courses on Reduce and Maple. At that time the usual CAS within the community of relativists was Reduce, and I was using it since '87. And I have never heard before of Maple, so I choosed the course on Reduce...
1 Meg Mac
Ah yes, those were the glory days. Maple would compute just fine, with an interestingly usable user-interface based on MPW -- all in 1 Megs of memory!
That small GUI
I have always thought that a combination of a simple GUI like that of Maple V Release 2 or 3 with the current version of the kernel and library would be a very interesting combination. Ie something more confortable than the Command line UI but using less resources than Classic GUI.
In my experience, that simple GUI was very stable (as far as Windows 3.1 allowed). Classic is not so stable.
That combination might be useful for improved performance while in a GUI: old machines, portable devices or cheaper individual versions.
Thank you, Jacques!
Thank you very much, Jacques, for your kind and valuable reply.
Your answers are deep, sharp, well documented and very useful to gain a wider and wiser knowledge of Maple and of what is related to computer algebra.
Thank you again!
Gabriele I.