Conjecture1 : if you asked every single person working in the Math Group at Maplesoft about this issue, I believe that all of them would agree with you. Conjecture 2: all of the same people would say that it's too late to change it. This kind of old, deep design bug has been there since the dawn of time - one can find traces of such muddying of concepts going all the way back to the earliest versions of Maple. I would say this was probably there already in 1981. But in 1981, no one involved with Maple had enough experience building a system like Maple to know that there was going to be a clash between mathematics and computer science! It is only much much later that this kind of issue was discovered, and by then such a change would have been a major endeavour. [Such changes are possible, but the last time big changes were done was with Maple 6. The fundamental design of Maple has been fixed since then.] Maple is a 27 year old piece of software. There are very very few pieces of software which are still in active use and active development that are that old! Actually, Maple is older than some of the developers working on it... Shameless plug: a graduate course I am teaching that deals with these issues -- the clash between computer science and mathematics, especially in the area of Calculus, in systems like Maple.

Conjecture1 : if you asked every single person working in the Math Group at Maplesoft about this issue, I believe that all of them would agree with you. Conjecture 2: all of the same people would say that it's too late to change it. This kind of old, deep design bug has been there since the dawn of time - one can find traces of such muddying of concepts going all the way back to the earliest versions of Maple. I would say this was probably there already in 1981. But in 1981, no one involved with Maple had enough experience building a system like Maple to know that there was going to be a clash between mathematics and computer science! It is only much much later that this kind of issue was discovered, and by then such a change would have been a major endeavour. [Such changes are possible, but the last time big changes were done was with Maple 6. The fundamental design of Maple has been fixed since then.] Maple is a 27 year old piece of software. There are very very few pieces of software which are still in active use and active development that are that old! Actually, Maple is older than some of the developers working on it... Shameless plug: a graduate course I am teaching that deals with these issues -- the clash between computer science and mathematics, especially in the area of Calculus, in systems like Maple.

The pde solver in Maple V Release 5 used completely different conventions than the ones in the new, modern pde solver. Right now, I don't quite remember what these were... Check out the help page, it was documented [I don't have a copy of a Maple that old]. However, I seem to remember that lower-case variables might have stood for arbitrary functions. But that is a very old memory.

The pde solver in Maple V Release 5 used completely different conventions than the ones in the new, modern pde solver. Right now, I don't quite remember what these were... Check out the help page, it was documented [I don't have a copy of a Maple that old]. However, I seem to remember that lower-case variables might have stood for arbitrary functions. But that is a very old memory.

That some months ago the number of posts on primes by the main developer (Will) has dropped drastically. And that his recent posts have a different "signature" than older posts. The best guess is that Will was transfered internally within Maplesoft to another job, and no one has (yet??) been assigned to replace him. So there is a mounting backlog of maintenance on mapleprimes which is not being done.

Converting an arbitrary list of base 10 digits back to a number would be done by proc(l) convert(l, 'base', 10, 10^nops(l)) end proc

If you want to test a proper predicate (ie a semantic condition) in Maple, you use is(), not type -- type is mostly for syntactic properties [with exceptions, of course, since early Maple developers were all classical computer scientists or (very) classical mathematicians, and not logicians]. More precisely,

Q := x -> piecewise(is(x,'rational'), 1,0):
int(Q(x),x=0..1);

                                  0

Of course, 3-valued logic is getting in the way here. So we can integrate the same function, but defined dually:

QBar := x -> piecewise(is(x,'irrational'),0,1):
int(QBar(x),x=0..1);

                                  1

As far as I know, there is no formal definition of the concept 'integral' used in Maple [and I do not say this idly, I asked all of the people who had written some of the code behind 'int', and none of them used any definition more formal than "it's the inverse of what the diff command does"].

If you want to test a proper predicate (ie a semantic condition) in Maple, you use is(), not type -- type is mostly for syntactic properties [with exceptions, of course, since early Maple developers were all classical computer scientists or (very) classical mathematicians, and not logicians]. More precisely,

Q := x -> piecewise(is(x,'rational'), 1,0):
int(Q(x),x=0..1);

                                  0

Of course, 3-valued logic is getting in the way here. So we can integrate the same function, but defined dually:

QBar := x -> piecewise(is(x,'irrational'),0,1):
int(QBar(x),x=0..1);

                                  1

As far as I know, there is no formal definition of the concept 'integral' used in Maple [and I do not say this idly, I asked all of the people who had written some of the code behind 'int', and none of them used any definition more formal than "it's the inverse of what the diff command does"].

There really ought to be keyboard short-cuts for doing operations even on the palettes and docks. I have my screen set at an insanely high resolution (2048x1536), and while I have no problems reading the results, hitting the border arrows require requires a rather outrageous amount of dexterity.

There really ought to be keyboard short-cuts for doing operations even on the palettes and docks. I have my screen set at an insanely high resolution (2048x1536), and while I have no problems reading the results, hitting the border arrows require requires a rather outrageous amount of dexterity.

I believe that, to ensure that this suggestion "effectively" gets picked up, it has been recommended that you submit this directly to support@maplesoft.com (they do not have the time to gather up stuff from mapleprimes, or so I am told).

I believe that, to ensure that this suggestion "effectively" gets picked up, it has been recommended that you submit this directly to support@maplesoft.com (they do not have the time to gather up stuff from mapleprimes, or so I am told).

I used system-designer-speak instead of using a lucid example (as you have), but we are in agreement.

I used system-designer-speak instead of using a lucid example (as you have), but we are in agreement.

Either using the palettes or the keyboard, free-form entry is problematic because so many inputs are "syntactically valid Maple", while a much much smaller number of inputs is "semantically understandable by Maple". Unfortunately, there is still no button (or context-menu option, or ...) which will check if an expression you enter is "meaningful (in the context of calculus)", which is what a lot of beginning users really need. Actually, while I am sure some experts love the flexibility in being able annotate their documents with arbitrary mathematics, most users are only interested in mathematics which is "meaningful", and most of the time, that can even be interpreted to mean "meaningful to Maple". So it would be very useful if the default mode of entry would force users to enter only maple-meaningful Math; advanced users (as they currently do by switching to 1D mode) could turn on the option of being able to enter arbitrary mathematics via the equation editor. [Free-form entry is a clear issue of ``featuritis'' winning over ``usability'']