I know that my posts are read by many people at Maplesoft (from comments I have received in person). Oftentimes, they even agree with me -- a statement which is all too often followed by a deep sigh.

I am not foolish enough to think that anyone is ``listening'', nor would I actually want that.  What I want is for people (including Maplesoft employees) to critically evaluate what is current practice versus what I say.  If this critical evaluation causes people to re-evaluate their position, I am glad, that is success.  Note that if they decide not to make any changes, because their re-evaluation concluded that the current position is, given all available data, better than the other options, I am still happy.  I want people to question the status quo, so that they think about the underlying assumptions.

I sometimes take positions which I know are unrealistic, for the express purpose of getting people to think.

> OrProp(RealRange(2,Open(5)),5);

                           RealRange(2, 5)

> AndProp(OrProp(RealRange(1,Open(5)) ,RealRange(5,10)) , RealRange(2,5));

                           RealRange(2, 5)

> OrProp(RealRange(2,Open(5)),5);

                           RealRange(2, 5)

> AndProp(OrProp(RealRange(1,Open(5)) ,RealRange(5,10)) , RealRange(2,5));

                           RealRange(2, 5)

Already the call PDEtools[dpolyform](y(x) = ln(x) + ln(1/x),no_Fn); produces this same problem.   This is inherent in the use of 'differential algebra' and 'differential polynomials', which is an over-simplification of the underlying analytic problem.

Note that gfun[holexprtodiffeq] has the same problem.

In the problem that reminded me of this method, you are probably right that solve is in fact doing all the hard work.  Which is good, in a way - it means that dsolve is properly calling solve!

The fundamental technique works rather well though, in many cases yielding solutions that are interestingly different than solve's.  To me, this says that something 'deeper' is going on -- that on some problem, the 'smooth' structure contains information which can somehow be leveraged in different ways than the 'algebraic' structure. 

I should have found a better example (as there are so many).  The title of the paper was simply too good for me to pass up...

This policy is a very positive change.  It 'fits' well with what has evolved on the web as a customer-friendly approach to mailing lists and information access. 

I would be quite glad if more of my posts elicited such responses. 

This policy is a very positive change.  It 'fits' well with what has evolved on the web as a customer-friendly approach to mailing lists and information access. 

I would be quite glad if more of my posts elicited such responses. 

My crystal ball tells me that C# has a good short-term future (C# 3.0 has some fantastic features in it), and that the languages to watch out for are F# and Scala.  They strike a really good balance between clean design a being pragmatic.

There are much better languages out there, but their fundamental problem is that most assume more intelligence than the average programmer seems to possess.

I fondly remember a talk by the 'creator' of Javascript at a programming language conference.  His first slide?  "I'm sorry" in big bold letters.  His talk was extremely well received. 

And reading between some of Jacques' posts makes me guessing
that a good bunch of developers would prefer to improve things, but
are constrained to other tasks.

I thought I had said this quite directly, and from recent conversations, this is still my opinion.  The effort of the developers is mostly spent on areas deemed ``strategic'' to the corporation, ie those areas which might serve to increase sales (of all Maplesoft products).  The question then becomes: it does not appear that serving the needs of current users is viewed as ``strategic''.  Whether this makes sense or not, I will leave to others to ponder and debate.  I can certainly see arguments for both sides.

And reading between some of Jacques' posts makes me guessing
that a good bunch of developers would prefer to improve things, but
are constrained to other tasks.

I thought I had said this quite directly, and from recent conversations, this is still my opinion.  The effort of the developers is mostly spent on areas deemed ``strategic'' to the corporation, ie those areas which might serve to increase sales (of all Maplesoft products).  The question then becomes: it does not appear that serving the needs of current users is viewed as ``strategic''.  Whether this makes sense or not, I will leave to others to ponder and debate.  I can certainly see arguments for both sides.

The basic technology for identify is PSLQ (essentially a descendant of LLL).  It is basically all (very clever) linear algebra, no trees anywhere.  Looking at the problem as a search problem in a database is an approach favoured by Wolfram Research.  Maplesoft favours algorithms, which is what PSLQ is.

The basic technology for identify is PSLQ (essentially a descendant of LLL).  It is basically all (very clever) linear algebra, no trees anywhere.  Looking at the problem as a search problem in a database is an approach favoured by Wolfram Research.  Maplesoft favours algorithms, which is what PSLQ is.

The problem here is not the "programming language" Java, but rather its library.  In particular, both AWT and Swing are so bad that the Eclipse Foundation created its own set of user interface widgets from scratch.  These work a fair bit better, but they are still not great - nowhere near what is available on any native platform.

Standard Maple, AFAIK, uses Swing.  From what I can tell, that seems to be the real source of problems.  Even Sun knows this is an issue - Swing is essentially Java 1.2, even though Java itself took a great leap forward with 1.5 (and is now at 1.6), unfortunately Swing has not kept up.  My impression is that it is a doomed technology, and people who still use Java use the Eclipse stuff instead.

It is now essentially documented, through OpenMaple, which uses the same protocols.  It is all done through INTERFACE_ 'messages', whose origin in the libray can be looked at, and if Classic was open-sourced, then we could see how at least the old messages are received.