The definition I was using is that a function f is any element of A -> B where A and B are sets.  I find the MathWorld definition hopelessly confused in its notation, while the Wikipedia entry seems to confuse relation with function [ie the definition without the restriction is for a relation, not a function].

Note that if A=B=reals, then the number of elements of A -> B is huge, and most of them cannot be 'named', although they are all functions.  This simple cardinality argument shows that there must be a difference between 'mathematical function' and 'computable function' (ie algorithm). 

That exp(x)=13 is a typo -- it should have been exp(x)-13 as well.

Of course, saying that exp(x)=13 is 'an equation' doesn't help unless you define what that is!

I definitely agree that it makes sense to offer "some reward" for good reporting of new bugs.

Personally, I would suggest something like either $5 credit/bug, or 1 week license extension for every 5 bugs (or both), etc.   For a company which needs its users to upgrade (like so many other software companies) for its continued survival, one good way to encourage customer loyalty is for the company to be loyal to its users.  The relationship can be a rewarding partnership, even if it is between a paying customer and a for-profit company.

A "denotational semantics" is a way to associate a 'mathematical object' from a (supposedly) well-understood domain to a syntactic expression.

What is exp(x)=13 supposed to be, as a mathematical object?  This may seem like an easy question, but it turns out to be extremely difficult.

For example, not that there is an 'x' in exp(x)-13.  What is that?  exp(x)-13 is not a 'function' [there are no variables in functions].  What is it?

By 'function', I meant the mathematical meaning of function, namely an assignment of a value in a range for values in the domain.  An 'expression', in both logic and CS, is a syntactic term from a (formal) language.  A 'procedure' is then one way to represent a very small class of functions, namely those which are 'computable'.  But mathematics is about much more general functions.

And 'open term' is an expression with free variables in it.  So proc(x) exp(x)-13 end is both a procedure and a representation of a function. exp(x)-13 is an expression and an open term (x is free). In this case, there is a morphism that can go from one to the other, and vice-versa. But consider proc(x) (x-1)/(x-1) end and (x-1)/(x-1). The first is a representation of a function which is 1 everywhere except that it is undefined at 1, while the second is a representation of member of Q(x) which is equivalent to 1.  There is no way to go back-and-forth between these.

The lambda calculus is Turing-complete, so while it may look like a toy, it is extremely powerful.  Its very simplicity makes it easy to analyze.

Most general problems in calculus are wildly uncomputable (or undecidable).  That doesn't mean that there isn't a very useful subset of the problems for which there are efficient decision procedures!  The issue becomes one of being to identify which questions are interesting. 

I believe that computers can be taught to do the same kind of mathematics as humans, given enough time.  What does seem to be impossible is to do calculus by just doing straightforward computations, you have to (compute!) some proofs too.

The calculus taught for undergraduate students shouldn't be very hard to implement. It is very algorithmic

The problem with that is that the end result is wrong! If you look carefully at the exercises given to students, you'll see that quite a few of them are about cases where the 'rules' do not work (because the function is not continuous enough, there is a singularity, etc, etc). Basically, the calculus is very computational for nice functions, but is very ill-behaved otherwise.  Maple and most CAS assume that all functions are nice, which is where things go horribly wrong.  The side conditions on those 'rules' cannot be ignored -- and it is exactly those side conditions which make things non-algebraic.  The side-conditions are all about analyticity properties, which often (still) do not have good algorithms.  In other words, discharging the side conditions needs a little bit of theorem proving capabilities.  [Which, incidentally, was the reason for assume facility].

As it turns out, complex numbers tends to make things considerably easier, not harder, that is really not the source of the problems.  The source really is that the 'rules' of calculus have important side conditions which Maple ignores, because verifying some of them is too onerous.

If you want a CAS built using your described scheme, take a look at MathXpert.  Personally, I don't think such a system could ever scale up to the power of any decent CAS.

In fact, my current plans for building a solid CAS involve doing exactly the opposite: I start from lots of abstract nonsense, and 'specialize' down to the easier domains.

My next attempt would involve replacing sqrt(3) by a variable (say s3), adding s3^2-3 to the system of equations.  Then I would make sure to put s3 in the 'right' place in the ordering of variables.

After that, I would consider some changes of variables.  The above looks like an algebraization of a system in spherical coordinates.  Sometimes, going algebraic is the wrong thing to do.  Going back to the original equations and dealing with differential equations might be simpler!

My next attempt would involve replacing sqrt(3) by a variable (say s3), adding s3^2-3 to the system of equations.  Then I would make sure to put s3 in the 'right' place in the ordering of variables.

After that, I would consider some changes of variables.  The above looks like an algebraization of a system in spherical coordinates.  Sometimes, going algebraic is the wrong thing to do.  Going back to the original equations and dealing with differential equations might be simpler!

Indeed, 'tryhard' is a piece of art by Gaston Gonnet.

It is best described as art, as only its author has any real understanding of why it works.  And even he doesn't understand when it will work beautifully and when it will never come back.  There were, unfortunately, many such pieces of art in Maple.  Luckily some of them have been replaced by pieces of solid engineering.  However, it often took the engineers multiple years to replace the art which was crafted in a few months!

Indeed, 'tryhard' is a piece of art by Gaston Gonnet.

It is best described as art, as only its author has any real understanding of why it works.  And even he doesn't understand when it will work beautifully and when it will never come back.  There were, unfortunately, many such pieces of art in Maple.  Luckily some of them have been replaced by pieces of solid engineering.  However, it often took the engineers multiple years to replace the art which was crafted in a few months!

Note that the problem that 'tryhard' attempts to solve, via heuristics, is NP-complete.  No one has ever done an asymptotic analysis of the heurisitics, so it is entirely possible that they are not polynomial-time.

Note that the problem that 'tryhard' attempts to solve, via heuristics, is NP-complete.  No one has ever done an asymptotic analysis of the heurisitics, so it is entirely possible that they are not polynomial-time.

If I remember well, at low Digits, evalhf used either the built-in function (when the platform provides one which is accurate enough), or otherwise an approximation based on the (Horner form of) a polynomial interpolant.  I believe it also uses range reduction for arguments which are too small/too large.  But it has been a very long time, I could be misremembering.

If I remember well, at low Digits, evalhf used either the built-in function (when the platform provides one which is accurate enough), or otherwise an approximation based on the (Horner form of) a polynomial interpolant.  I believe it also uses range reduction for arguments which are too small/too large.  But it has been a very long time, I could be misremembering.

The original authors of a lot of Maple were computer scientists and not pure mathematicians.  They believed that mathematics, as taught to them in their undergraduate mathematics courses, could be implemented as a set of direct rules (because it feels like that in undergraduate mathematics).  Unfortunately, with enough mathematical education, you realize that that is quite wrong, and that even simple mathematics is much more complicated than that.  Unfortunately a lot of the incorrect design decisions that were taken in the early days by these (otherwise brilliant!) computer scientists were so deeply buried in the fabric of Maple that many of them took years of hard work to 'undo'.  I know, I was one of the people who spent years repairing Maple after the over-simplification of (x^2)^(1/2) was removed from Maple's kernel.  Very slowly, over the past 15 years, more of these have been 'fixed'.  But there are some over-simplifications which remain, and they may never be fixed, not without creating a whole new system.

Other parts of Maple are 'broken' because there are huge holes in the theory.  For example, Calculus is all about functions, while Maple is not at all about functions, it is about expressions.  It other words, it is about syntactic expressions which are supposed to denote functions.  Unfortunately, there is no denotational semantics for open terms!  [defn: open term = term with free variables].  Just as bad, if you use the naive interpretation of open terms as being implicitly quantified (or more precisely, an implicit lambda), that still doesn't help much because:

1. The lambda calculus is usually typed -- but what is supposed to be the domain of definition?
2. Not all Maple expressions are functions, some are meant to be formal objects (like polynomials or series, for example)
3. The denotational semantics of the lambda calculus is via pointwise evaluation, and functions are all assumed to be total [partial functions are totalized by adding an explicit 'bottom' element].  This is not standard mathematics!

I could go on, but that is probably enough.

I know that many of the current Maple developers are indeed mathematicians -- and I know several who would really love to fix several of those early mistakes, but who also know that it may never happen.

I should point out that, without some serious theoretical work, I don't think the SAGE developers have much chance to really improve things either.  The problem is quite deep.  If it was possible to 'algebraize' calculus, I am quite sure that the Axiom people would have done so long long ago -- but they didn't.  There is a good reason for that!