I should have tried my own idea before posting it!  [I was in a hurry when I posted it].  It seems that assuming traps all errors itself and simply returns the value of its argument if the assumptions "go wrong".  It is unclear to me if that is actually the right design.  I would rather think that that is a bug.

made things way too easy... 

No one has yet to fully expand out 'wmsical' though.

You can probably achieve something similar via assuming.  Replace the assume call with

and let assuming take care of the careful interfacing with assume.

You can probably achieve something similar via assuming.  Replace the assume call with

and let assuming take care of the careful interfacing with assume.

Ok, one more hint: is the programmer behind the modern version of the combstruct package.

In certain settings, closed-form has a very precise technical definition.  But overall it is a fairly supple term.  In general it is defined to be "in terms of functions that are so well understood or so important that they have names".  As you remark, that is often a cheat.  A 2F1 hypergeometric function is a solution of a 2nd order ODE -- that certainly isn't`` simpler'' than a 1D integral!
 

In certain settings, closed-form has a very precise technical definition.  But overall it is a fairly supple term.  In general it is defined to be "in terms of functions that are so well understood or so important that they have names".  As you remark, that is often a cheat.  A 2F1 hypergeometric function is a solution of a 2nd order ODE -- that certainly isn't`` simpler'' than a 1D integral!
 

I should have tried that myself, silly me.  I'll know better next time!

I should have tried that myself, silly me.  I'll know better next time!

Not Paulina.  While she has been using Maple quite some time, she has been officially involved with Maplesoft for much less time than that.

The name was coined by the same person who ported the old X11 plot driver for Maple V (release 1, the one just called "Maple V") to Microsoft Windows 3.0.  I was the one who did the original worksheet interface, but she did the plot driver port. 

And no, that's not a typo, this was definitely 3.0, the Windows 3.1 port did not happen until Maple V Release 2, which I also did.  3.1 was seriously better behaved as an O/S than 3.0.  At least you had a 50/50 chance of 3.1 staying 'up' if your program core dumped; in 3.0, your machine invariably went down and you had to reboot.  Made debugging much more challenging!

You have to explicitly assume that a>0,b>0, c>0 and that they are the sides of a triangle.  That last bit implies a relation that is easy to write down for a right triangle, but involves another quantity (the cosine of an angle) otherwise.  So you are right, but so is Maple!  The issue is that you have more knowledge, from which what you say can be derived.  Without it, there are other cases that need to be accounted for, which is what Maple does [and is the right thing to do].

This is one lesson that most users of computerized mathematics [including myself!] need to learn multiple times before it really sinks in: you need to tell your system all your assumptions, otherwise how else is it going to know what you're talking about?  If you listen to yourself explain your mathematical problem (verbally or in writing like you did above) and compare that to what you actually typed in Maple, you'll notice a non-trivial gap.  That gap results in the answers you get (sometimes!) being other than what you expect.

sqrt(a*b) is not equal to sqrt(a)*sqrt(b), especially when one (or both) of a and b are negative reals.  So the correct answer probably depends on the sign of s-a, s-b and s-c.  That is why you can't get it to work, and why the nice formula has the minus under the square root.

What assume will accept as meaningful input is a much, much larger set than what are 'properties'.  This is one of those areas where Maple is successfully being nice to the user in allowing an appropriate amount of flexibility.  The definition of property is, to my mind, properly restricted to a much better defined subset (which roughly corresponds to what you get from about).

In other words, assume takes as input expressions which represent properties, as opposed to input which is a property.  A bit subtle, but very convenient.

It's really the same thing as ChebyshevT(n,x) representing a polynomial, while not actually being a polynomial.

What assume will accept as meaningful input is a much, much larger set than what are 'properties'.  This is one of those areas where Maple is successfully being nice to the user in allowing an appropriate amount of flexibility.  The definition of property is, to my mind, properly restricted to a much better defined subset (which roughly corresponds to what you get from about).

In other words, assume takes as input expressions which represent properties, as opposed to input which is a property.  A bit subtle, but very convenient.

It's really the same thing as ChebyshevT(n,x) representing a polynomial, while not actually being a polynomial.