30.04.2011 02:16, Aaron S. Meurer пишет:
> So Ondřej, Christian, and I talked about this before GSoC, but I
> forgot to mention it on the list. We need to figure out, as a
> community, how to remove the old assumptions system and merge in the
> new one. We have already had several branches attempting to do it,
> and we couldn't even get a GSoC to do it because we don't really have
> a clear strategy on how to do it.
>
> So I think what we need to do is edit this wiki page
> (https://github.com/sympy/sympy/wiki/Assumptions) and under the
> "Approaches" section, but your ideas on how to do it, along with a
> list of pros and cons, like
>
> Idea: Describe the idea.
>
> Pros: List the pros.
>
> Cons: List the cons.
>
> And edit each idea with the pros and cons that you see with it. And
> then from there hopefully we will be able to see which way will be
> the best, or at least it will be easier to make a decision about it.
>
> By the way, the examples on that page need to be removed, or
> refactored to fit the above form. The page was hijacked from
> something else, so probably they should just be removed.
>
> Aaron Meurer
>
Hi all!
Sorry, I have not can to respond immediately. But I read print listing
of the this topic yesterday,
I wonder that no one havn't answer what are aims of the assumptions and
what are the assumptions designed for?
May be it is clear for all, but I think it is mistake if we omit this
step and begin with construction of architecture. In complex cases the
design and architecture depend on the aims and use cases of assumptions
system. If we invite aims, (and only then the descriptions syntax and
use cases) only then we can think how to handle with them more
efficiently. An what restrictions are,
In general (for many systems: languages, platforms, ) the restrictions
define the syntax and use-cases too.
(And assumptions can be splitted and classified - for some of them one
strategy is needed, for other types of assumptions - another)
Also I think it is strategic mistake if we invite general description of
assumptions and only then will decide how to handle with all of them in
the core.
May be someone oriented on the others CAS's system, but I warn that they
are not the etalons and may be have (traditional historical) mistakes of
design (how it was for series). But they can take into account too.
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 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.
