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
From it immediately followed that it is not quite correct:
01.05.2011 23:35 +0400, Tom Bachmann
Every assumption is about symbols.
I think that my statement is true, or at least should be true.
Everything that is not a symbol (or involves a symbol) is some concrete
mathematical entity, and all of its properties are settled (in
principle, in practice it might be hard to find out if a certain number
is e.g. positive, even if it is specified uniquely).
So basically I'm saying that things like "I'm an integer" or "I'm
commutative" are not really assumptions, they are type information if
you will. Integer(1) is not the same as Rational(1) is not the same as
eye (identity matrx).
So in particular ExtendedReal(1)/ExtendedReal(0) = oo,
ExtendedComplex(1)/ExtendedComplex(0) = zoo, Real(1)/Real(0) = nan, or
perhaps even an exception [unless we do some auto-conversion].
So we then have the following objects:
* algebras (or domains, or whatever) represent collections that are
typically manipulated together
* concrete elements of algebras. These are definite mathematical
objects, all of whose properties are known in principle.
* symbolic elements. These are elements which contain free symbols, and
not all of whose properties are known
Notice that every element that we ever compute with belongs to some
algebra. All assumptions are about "symbolic elements". They can be used
to do transformations of the expressions that would not be allowed for
all possible values of the free symbols, usually with the intent of
giving the user a better answer to a query [actually this seems a bit
vacuous ...].
Notice also that not everyhing that looks like a symbol is a symbolic
element (this is probably obvious to everyone but me): in e.g. a
polynomial algebra the generator X is a definite entity and *not* a free
symbol. Every statement that makes sense in this algebra is known about
X. A symbolic element would be a parametric family of polynomials,
something like X**2 + p*X + q. Here the p and q are symbols that
represent elements of the coefficient ring. It is sensible to make
assumptions about them, e.g. p > 0 or "X**2 + p*X + q is irreducible" or
whatever.
How is this distinction reflected in the implementation of polys (if at
all)?
I can't discuss further about the algorithms, what to do with branches,
and how it related with cache system without resolving those questions:
precise description of assumptions aims, working-off of the use cases
(and resolving some logical problems which exists in the current system
or can be raised in the future).
P.S.
About "stopping any development by Ronan's attitude" and hanging of
branches.
I think that we must do not ignore the strategic decisions.
I understand that the project must be on the development. But if the new
code (more and more new code) which is based on the bad strategic
decision, then it is meaningless at whole after all.
"If we have a bad strategy and a bad tactic then we lose a battle
rapidly. If we have a bad strategy and the best tactic then we lose a
battle as time goes by. If we have bad tactic and good strategy then we
win a battle finally. And if we have a good tactic and good strategy
then we win a battle rapidly."
If there are difficulties with strategic core decisions then first of
all we must recognize them.
And may be they must be published on the wiki page or in mailing list too:
The offer:
- the arguments for.
- the arguments contra.
before to come to a conclusion or before the decision.
--
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.
