ack, first first paragraph has the sentences out of order - an example
of giving a "useful result with an implicit assumption" is:
http://reference.wolfram.com/mathematica/tutorial/IndefiniteIntegrals.html
"Mathematica gives the standard result for this integral, implicitly
assuming that n is not equal to -1."
Integrate[x^n, x]
the result is x^(1+n)/(1+n)
(this even happens when you give the option GenerateConditions->True)
It would be much better to return the solution and its assumption. (or
even better, all possible solutions, or some sort of message that not
all solutions could be found)
On Sep 13, 12:48 am, Chris Chiasson <[EMAIL PROTECTED]> wrote:
> On the other hand, sometimes Mathematica makes assumptions "in order
> to return useful results" that are sometimes wrong and then people
> complain about it on the mailing list. It is probably much easier to
> ask the user to declare something as real than it is to ask the user
> to figure out that the software made an incorrect assumption. (I am
> specifically thinking of integration.)
>
> Anyway, about the (sin+cos)(1) giving sin(1)+cos(1):
> In Mathematica, this is implemented by a generalized function called
> Through (that operates on expression trees). It isn't automatic like
> people are suggesting here. Also, other operations are possible, such
> as threading, distribution, outer and inner products, etc (not all of
> which make sense here). It seems like people are thinking of a direct
> mapping between syntax and the operations that are performed. Should
> there be some level of generalized expression handling that allows
> manipulation of expressions, or should everything be hard-coded for
> each class?
>
> On Sep 12, 8:17 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
>
> > On 9/12/07, David Kohel <[EMAIL PROTECTED]> wrote:
>
> > > Just to add my 2 bits, I think we should aim for something like the
> > > following:
>
> > > sage: x = var('x')
> > > sage: X = x.domain()
> > > sage: X
> > > Affine line over the Real Field
> > > sage: X.identity()
> > > x
> > > sage: f = sin(x)
> > > sage: X == f.domain()
> > > True
> > > sage: f = sin(domain=X,codomain=X)
> > ...
> > > Note that the default domain could be a Complex Field rather than a
> > > Real Field.
> > > In order to allow domains which are, say, the positive real numbers, I
> > > don't see
> > > how to get around the need for a class for such domains (i.e.
> > > RealField() does
> > > not do the job).
> > [...]
> > > However it also introduces some headaches, like when (or on what
> > > domain) is the
> > > composition sqrt(x) defined, and how to specify the domain of an
> > > inverse function:
> > >[...]
> > > With this approach, one has to make a design decision whether a
> > > function must be
> > > defined everywhere on a domain, whether it can have isolated poles,
> > > and if the ...
> > [...]
> > > This would provide some
> > > mathematical rigor without killing usability.
>
> > The entire point of the SAGE symbolic calculus package is to not
> > do what you're suggesting above. It is meant for pure symbol
> > manipulation and calculus, even if this might not be completely
> > rigorous. It's a completely different kind of thinking than what
> > goes into Magma or even advanced rigorous mathematics.
> > And for certain types of problems (the vast majority of the ones
> > undergrad non-math majors encounter), this non-rigorous
> > symbol manipulation is by far the easiest thing to use. There is
> > a genuine reason why Maple and Mathematica have millions of users,
> > and more formal rigorous systems (e.g., Axiom) have far less, even
> > though they to some extent address the same problems.
>
> > My goal for for SAGE is to provide a viable open source alternative to
> > Maple, Mathematica, Matlab, and Magma. To do this it's critical that
> > there
> > be a part of SAGE that can truly be as usable for non-mathematicians
> > as Maple. We're far from there yet, but I think the current calculus
> > package
> > is a step in the right direction, and what you're suggesting isn't.
>
> > I think that something like you're suggesting definitely has a place for
> > people with much more mathematical maturating that "undergrad science
> > majors". But I think the two must be complementary, not that one replaces
> > the other.
>
> > I remember reading a long thread on axiom-devel that was a discussion
> > between Ondrej Certik and the axiom developers. It ended rather
> > abruptly when one of them wrote that they were not interested at all in
> > "formal symbol manipulation" and Ondrej replied that possibly non-rigorous
> > formal symbol manipulation was *precisely* what he is interested in.
> > There is certainly a very important place for this sort of computation.
>
> > William
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
