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
>
>>>> 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
>
> There are more collection-like concepts than that. Lumping them all
> together under the name "algebra" (or whatever) is a recipe for
> conflicting expectations and bad design. I can think of:
> * the Python type of objects
> * the interface of objects. That's not always formalised in Python, but
> when it is, it's a base class, possibly abstract.
> * algebraic structures like groups, rings, fields
> * mathematical sets - note that the same set can have different
> structures applied over it, for instance (ZZ, +) is a group, (ZZ, +, *)
> is a ring.
>
>>
>> Notice that every element that we ever compute with belongs to some
>> algebra.
>
> Here's our fundamental disagreement, I think. Objects aren't
> intrinsically part of an algebra, they happen to belong to some set over
> which some algebraic structure is defined and used.
>
>> 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 ...].
>
> I suppose that the distinction is between formulas with free symbols and
> closed formulas. The former are assumptions, the latter "mathematical
> facts".
>>
>> 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.
>
> +1
>
>> How is this distinction reflected in the implementation of polys (if at
>> all)?
>
> AFAIK, at the public interface level, it's not. Instances of Poly can
> only represent polynomial expressions, not true polynomials.
>
>>> 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.
>
--
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.
