Hi,
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)
sage: y = var('y')
sage: g = sin(y)
sage: f.domain() == g.domain()
False
sage: f == g
False
sage: h = sin(domain=X,codomain=Y)
sage: f == h
False
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).
Note also that this provides a means of resolving sqrt(x)^2 and
similar expressions.
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:
sage: sin_inv = sin.inverse() # well-defined on some default subspace
of the codomain?
sage: sin_inv.domain()
???
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
domain and codomain contains a +oo and/or -oo. Personally, I think
isolated poles
(or codimension >= 1 poles) should be allowed, but sqrt(x) should
require x.domain()
to be contained in the positive reals (or a complex domain and some
choice of branch).
Thus sqrt(exp(x)) would be valid but not x = var('x'); sqrt(x). This
would provide some
mathematical rigor without killing usability.
--David
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
