07.05.2011 22:20, Aaron S. Meurer пишет:
On May 6, 2011, at 10:32 AM, Ronan Lamy wrote:
Le jeudi 05 mai 2011 à 20:18 +0100, Tom Bachmann a écrit :
First of all thanks alexey, for steering the discussion into an
important direction!
On 05.05.2011 19:42, Alexey U. Gudchenko wrote:
Well, when I have concerned the assumptions, I noticed, first
of all, that they are used for this users aims:
(a) simplification. Assumption help us to simplify expressions
for the user. he typical example:
sqrt(x**2)
abs(x) # x is Real
_
x # x is positive.
Complex case (related with expression):
sqrt((x + y)**2)
abs(x + y) # (x + y) is Real
_
(x + y) # (x + y) is positive.
BTW. It would be good when the CAS can analyze some complex
expression, and offer to the user what assumptions can simplify
those expressions.
how_to_simplify(sqrt(x**2))
[assume that x is positive: then sqrt(x**2) --> x, ...]
BTW, the assumption `x is positive` have nothing better than `x
is grater then, saying, 7`. The reasons of its existence are
the same.
BTW, `is_positive` assumptions have special classification type
(it is distinguished from assumption `is_zero` which related
with another sort of assumption).
(b) Mathematical assumptions. The typical example: whether we
are on some field or on another.
BTW, This construction can resolve problem to ask assumption
system permanently during the calculations. if we have some
nested or sets of general function {`A`, `B`, `C`}, and every
of them internally analaze the assumptions and have code
blockes like "A: A_complex if arg complex, A_real, if arg
real...", so they can grouped to sets {`A_real`, `B_real`,
`C_real`} without internal asking about assumptions.
One can say that those methods has domain parameter, like in
Sage, or in Polys in SymPy (if I am not mistaken).
I have sowen that Tom already added at the wiki page about
connection asuumptions with algebras (That's good).
(c) In general, especially when we consider them from
programmatic side (not mathematically) Assumptions plays the
role of rules how to calculate or simplify expressions. Nothing
else.
The typical example is:
1/0
oo (assume that we are deal with reals)
1/0
zoo (assume that we in complex)
(In this case an assumption must not be related with symbols)
I noticed that (c) (assumtions are the rules not only for
symbols, but for operations too, how to deal with them) is a
general case of the assumption system. Is not it? But we must
catch the balanse how to describe assumtions
For me, (c) isn't part of the assumption system. It's rather an
interpreter setting that should only be used by client code and
not within sympy (counting isympy as client code). Also, I'm not
sure if that's exactly what you're suggesting, but having
Integer(1)/Integer(0) return different results based on context is
bad - for exactly the same reasons as Basic.keep_sign.
I agree. Having global directives like this is a bad idea, if just
because it's extremely annoying to test. To do it correctly, you
would have to run the tests with it off and then again with it on,
which causes a combinatorial explosion in the number of combinations
we have to test. Of course, in reality, if the module is well tested
on its own, you should only have to run the tests for that module
(like in theory, you should only have to run the polys tests in the
different ground types). But furthermore, if some test sets the
global parameter (like was happening with keep_sign), you get
different results depending on what order the tests are run in.
This is one of the reasons why I'm presently leaning toward some kind
of local assumptions implementation, like Vinzent's.
Aaron Meurer
Well, I didn't told about global directives here.
I only to say, that SymPy must maintain and control ariouse algebras.
Somehow, global or not. (BTW Tom's variant with
ExtendedReal(1)/ExtendedReal(0), is not global usage)
In the current situation, when SymPy return only `zoo` for `1/0` it
means that global directives are used implicitly ("we work in the
ExtendedComplex field"), without any controls of it.
But the possibility of usage various of algebras is importent - it is a
requirement for SymPy. An we must take it into account, and only then
think how to realize it.
And the usage of global or local syntax for it - is a requirement for
realization (possible it or not).
Alexey U.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
