[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] [#47 complexForm(log(%i) - log(-%i))] meaning of y > 0
[Axiom-developer] [#47 complexForm(log(%i) - log(-%i))] meaning of y > 0; symbolic floating point
Sat, 16 Jul 2005 12:52:08 -0500
Thanks, and yes, I was wrong again (shame on me): the range of the single
argument 'atan' does not cover $[0, 2\pi)$. But the only way to return results
in case variables are involved in the arguments of 'atan(x,y)' is to use
provisos (I thought I was able to avoid this with the sign convention). Even if
we were able to make 'EXPR INT' into an 'OrderedRing', the tests such as 'if y
> 0 then' will have a different meaning than when 'y' takes a value in 'INT'
whatever the ordering on 'EXPR INT' may be. Such tests must be done using
values of 'y', not the expression represented by 'y' (thus, the code for
'myatan2' used these tests incorrectly for general expressions 'y'). So it
seems we need 'OrderedRing' not on 'EXPR INT' but on 'INT', which is okay,
except that in 'COMPLEX R' we have no way to know about what 'R' is (see also
last paragraph in this reply).
One possible way is to use a three argument 'atan': in addition to the 'x,y'
coordinates, also include the quadrant. This would allow a user to supply the
crucial information and also make it automatic when the quadrant can be
deduced. We can allow the quadrant information to be specified as "unknown" or
"failed" and then return the expression unevaluated in that case.
The amount of simplification that should be carried out should also be part of
the discussions. For example, in a two-argument version,
'atan(2*(x^2+1),(x^2+1))' should be evaluated to 'atan(1/2)' but any such
simplification either is difficult (not possible?) or may lose information on
the quadrant if not carefully done. For example, 'atan(2*(x^2+1),-(x^2+1))' and
'atan(-2*(x^2+1), (x^2+1))' should give different answers. But how can we test
signs on expressions? (Note that this is *different* from how to make 'EXPR
INT' into an 'OrderedRing' because we are talking really on the level of the
base domain: signs of expressions as values, not as expressions.) It would seem
that we need to get into the full-blown cylindrical algebraic decomposition
(CAD) stuff, even just for the polynomial expressions. And 'INT' is not quite
the base domain to perform these computations.
Stepping back a bit, let's see why 'EXPR INT' is involved in the original post
to evaluate 'argument(-%i)'. Functions (and especially, when implemented as
operators) like 'argument' and 'atan' perhaps should be defined only under a
domain which is closed with respect to them (so 'argument: Complex R -> R'
would be considered closed, but 'argument: Complex Integer -> Expression
Integer' is not.) In 'Complex Integer' these functions are meaningful only
because the set of Gaussian integers is mathematically a subset of the field of
complex numbers. The Axiom construction is complicated by the fact that $\pi$
may be symbolic and hence lives in 'Expression R'. And once expanded to
'Expression R', the problem with what to do with variable inputs further
complicates the implementation. Thus in evaluating 'argument((-1+%i)::Complex
Integer)', Axiom needs to invoke 'argument: Complex EXPR INT->EXPR INT'. Would
it be appropriate to invoke something like 'argument: Complex Float -> Flo!
at' instead? (This would avoid the issue of variables in input arguments.)
This discussion naturally leads one to question why specific constants such as
$\pi$ live in separate domains in Axiom (contrary to a purely mathematical
model). *Must* these constants be numerically represented under 'Float'? Can
one create something called 'SymbolicFloat' where roughly, 'SymbolicFloat' is a
mix of floating point numbers, symbolic algebraic numbers, and symbolic
transcendental numbers, and yet retains the properties of 'RealNumberSystem'
and 'OrderedRing' (so whenever an inequality in this domain is to be tested,
all symbolic constants will be temporarily converted to floating point with an
accuracy sufficient to resolve the decision, but the symbolic constants still
remain symbolic in subsequent computations)?
forwarded from http://page.axiom-developer.org/zope/mathaction/address@hidden