is is powerful, not fast. It does have some code to try to resolve the really simple cases quickly, but this has limits. So if efficiency is something you care about, then it is worthwhile to do this.

That said, I tend to want my inner loops to be as fast as possible, while I like my interface code to be as smart as possible.  By interface code, I mean the entry points to big routines like solve, dsolve and so on.

Since these objects are quite large, effecting a 'simplification' is something that has to be done somewhat carefully.  But this is where some of Maple's ability to go between expressions and procedures comes in, as well as using that trusty tool, subsindets.

We would like to have some simplifications applied, so we do two things:

1. change the squaring to an expanded squaring
2. change the square-root to a call to the function

Sol2 := subsindets([Sol], name ^ 2, x->Expand(x)): 
Sol3 := subsindets(Sol2, anything ^ identical(1/2), x->Sqrt(op(1,x))):

Instead of doing an assignment, we will go through a procedure.

pp := subs({Sqrt=sqrt,Expand=expand}, convert(CompSeq(locals=[w],[op(Sol3),w]),procedure));/
w := pp():

And now we are back to where Robert left off. However, ww[7,0] is now ``simpler''!

The expression given above is indeed for a calendar function -- and it comes from translating a 'decision table' into first-order logic!

I have already expressed my view that FOL is akin to assembler in this context, and would not be the way I would approach the problem of deciding whether a particular decision table is complete (and if its rows are disjoint).  But people doing software specifications are really beholden for FOL, so it's rather like trying to steer the Titanic by throwing pebbles at it from the side.

The expression given above is indeed for a calendar function -- and it comes from translating a 'decision table' into first-order logic!

I have already expressed my view that FOL is akin to assembler in this context, and would not be the way I would approach the problem of deciding whether a particular decision table is complete (and if its rows are disjoint).  But people doing software specifications are really beholden for FOL, so it's rather like trying to steer the Titanic by throwing pebbles at it from the side.

On a fast machine, trying to find the order 2 Subfields of the generating polynomial for cos(2*Pi/257) takes too long -- I stopped it after 2 hours of computation time on a fast machine [it only allocated 47Megs, which is not bad].  Either this is a really hard computation or this particular algorithm has not been optimized for large queries, I don't know which it is.

Factoring the resulting polynomial over Z[sqrt(257)] is very fast though.  But it just splits the degree 128 polynomial into two degree 64 polynomials.

Historically, there were only types.  Type-checking is generally something you want to be fast, and most types in Maple are structural, and thus can be checked very quickly [although there are, like always in Maple, exceptions].

Much later came the concept of properties, with the advent of assume.  Very easily, even for simple properties, assume can be rather time-consuming.  And because Maple developers are generally efficiency-obsessed, the idea of mixing these was always regarded as being in bad taste.   Is this still a good idea?  That is certainly something worth debating.  Historically speaking, does it make sense?  Yes, I definitely believe so.

The sad thing is, since this is now ancient history, the cabal that currently holds sway at Maplesoft has as a basic article of faith that backwards compatibility of the basic language must be near absolute.  [Why this doesn't carry over to the GUI still mystifies me.]

Historically, there were only types.  Type-checking is generally something you want to be fast, and most types in Maple are structural, and thus can be checked very quickly [although there are, like always in Maple, exceptions].

Much later came the concept of properties, with the advent of assume.  Very easily, even for simple properties, assume can be rather time-consuming.  And because Maple developers are generally efficiency-obsessed, the idea of mixing these was always regarded as being in bad taste.   Is this still a good idea?  That is certainly something worth debating.  Historically speaking, does it make sense?  Yes, I definitely believe so.

The sad thing is, since this is now ancient history, the cabal that currently holds sway at Maplesoft has as a basic article of faith that backwards compatibility of the basic language must be near absolute.  [Why this doesn't carry over to the GUI still mystifies me.]

It should not be too hard to automate this - inside solve and convert/radical.  Now, we know in advance that sqrt(17) is special, but what if we didn't?  That nasty degree 8 RootOf sure would not have helped!  But that is not so...

e := cos(2*Pi/17):rof := convert(e, RootOf):
> pol := subs(_Z=z, op(1,rof)):
> evala(Subfields(pol,2));
                                         2
                         {RootOf(-17 + _Z )}

So now we know that there is something going on with that, we can proceed to factor over that extension field.  If that is not enough, we can keep on going, finding other subfields of interest. 

There are all sorts of really useless buttons - paste from Word (too uncommon), Replace (can be done with the mouse), underline (bad style, not recommended), strike-out (too uncommon), the 3 justification buttons (rare for posts here), and maybe anchor (ditto, though it might be nice to use that in the future).  So there is lots of room to clean things up, which will make room for more useful buttons [like <code>].  To post Maple code, it is very important that it visually look different than the surrounding text!

[This is what happens when the developers of a product, in this case mapleprimes, are not also users of the product, independently of their task as developer/administrator.  You don't get to really know and understand the common usage patterns.  I am sure Scott03 could have told you that lots of people use <code> and <pre> all the time.]

See how this Maple code map(foo, [1,b,`*`]) is formatted?  I manually inserted a code tag, and it worked.  But I did have to edit HTML [by using the 'Source' button] to do it.  It would indeed be nice if that were one of the standard buttons.

The online documentation for the FCKEditor makes it pretty clear that this is easy to configure server-side.  As is obvious, since the 'maple' tag sure isn't standard!

I had to make changes to all 3 of my Firefox installations for the editor to work properly.  Under Tools->Options, Content Tab, one needs to use the 'advanced' button besides the Javascript toggle and also set 'hide the status bar', otherwise the editor will not show up at all.

Gaston Gonnet, one of the co-founders of Maple, was originally from Uruguay.

A macro processor only makes things easier if there is someone around who understands it and can maintain it.  When it is undocumented, it becomes a liability.

Gaston Gonnet, one of the co-founders of Maple, was originally from Uruguay.

A macro processor only makes things easier if there is someone around who understands it and can maintain it.  When it is undocumented, it becomes a liability.

This seems like a bug in Roots.  It is meant to be used in first-year calculus.  So although what you say is completely correct, it is also not something you should ever expect first-year students to know (or understand).  So, if Roots sees a float, it should just call fsolve on its own.  Isn't that part of the design principles of the Student package? 

This looks a little weird, but works quite well:

seq((i->x->i*x)(i),i=1..3);

The reason it works is also to do with evaluation rules!