06.05.2011 20:32, Ronan Lamy пишет:
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).
It depends on the point of view what to consider assumption system.
If I look on the expression like (a la Mathematica, or new assumption
system):
In[0]: simplify( sqrt(x**2), (x>0) | (x is Real) )
Then I see: (1) assumptions on the right side after comma.
Yes, it seems that the assumptions are connected to the variable `x` only.
But I also see, (2) that they act on the first part `sqrt(x**2)`.
In other words, this sort of assumptions are defined with connection to
the variable, but the whole rule (association) connected both to
variable and `sqrt(x**2)`. From programmer point of view I see the rule.
If I look on the old system then I see the same:
In[0]: x = Symbol("x", positive=True)
In[1]: sqrt(x**2)
with the difference that the assumptions acts to the followed
expressions (so they defined the rules how do deal with those expressions).
That is what I meant upon the (c).
Why do I rise this question - the implementation is differ if we connect
assumption only to symbols or of we consider rules (caching, algorithms,
global/local problems)
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.
Tom have clear it. I have used words when describe assumption, Tom -
`ExtendedReal` syntax which precise defines how to deal and with what to
deal. (one variant), so there is no context.
Another question what to do with the S(1) function.
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].
Yes, it is a variant. Which can be classified as Mathematical
assumptions (whether we are on some field/ring or on another).
But may be the variants of algorithms and use-cases.
E.g.
- can be used automatic type conversion if possible:
ExtendedReal(1)/0 => ExtendedReal(1)/ExtendedReal(0) => (use
ExtendedReal.div) => oo.
- specifity of field:
1/0 ( in ExtendedReal) => ExtendedReal(1)/ExtendedReal(0) => oo.
At the wiki page, as I understand, the algorithm is described (and it
seems that it is related with hierarchy of algebras as Frederik mention
while he write about parent algebra).
"In order to allow conversion between algebras, every algebra needs to
be able to convert its elements into elements of Verbatim, and it needs
to provide a general method to construct its own representations of a
given S-expr. For this to make sense the possible heads have to be
standardised somewhat, but not completely: while (probably) every
algebra needs to represent addition and should use ADD for that, not
every algebra knows about the sine function. In general if compatibility
with other algebras is not important, private identifiers can be used
for the heads. If an algebra encounters an unrecognised head, it can
simply throw an exception."
The rest of the letter I don't undersatand becouse the issues are
difficult for me (without examples of use-cases and aims of assumptions)
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.
If I understand correctly, we concern the fundamental question what are
the cause and what corollary.
We can define and deal with algebra and then invite representation for
it e.g. with the help of objects with some properties and behaiviour.
Or we can invite some object and operation with them then analize
algebraic properties from it.
I suppose that the last is more extentable and interesting (at least for
me) for mathematical research (especialy when we can invite miltivariant
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 ...].
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.
--
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.
