On Wed, Jun 18, 2008 at 11:23 AM, Pearu Peterson
<[EMAIL PROTECTED]> wrote:
>
>
>
> On Jun 18, 9:13 am, "Ondrej Certik" <[EMAIL PROTECTED]> wrote:
>> On Wed, Jun 18, 2008 at 11:03 AM, Pearu Peterson
>>
>> <[EMAIL PROTECTED]> wrote:
>>
>> > Hi,
>>
>> > In sympycore we have Verbatim class that holds expressions without
>> > any evaluation. E.g. it can hold the expression 'x - y' in both
>> > forms: Add(x, -y) and Sub(x, y). Converting to Verbatim and back
>> > to the default representation is relatively cheap. May sympy should
>> > implement a similar scheme in order to better support the cse
>> > algorithm.
>>
>> Thanks for the tip. BTW, you don't seem to have a class Sub in
>> sympycore, definitely not exported by default.
>
> sympycore does not have classes Add, Mul, et as well:)
> However, Sub is not exposed indeed (may be it should),
> it is available as class method to ring algebras:
>>>> Calculus.Sub(x, y)
> Calculus('x - y')
>>>> Calculus.Add(x, y)
> Calculus('x + y')
>
> Anyway, here's how Verbatim can be used in sympycore (the interface
> has room for improvement, of course):
>>>> from sympycore import *
>>>> from sympycore.utils import SUB, ADD
>>>> x,y,z,v,w=map(Symbol,'xyzvw')
>>>> Verbatim(SUB, (x,y))
> Verbatim('x - y')
>>>> Verbatim(ADD, (x,-y))
> Verbatim('x + -y')
>>>> print Verbatim(SUB, (x,y)).as_tree()
> Verbatim:
> SUB[
> SYMBOL[x]
> SYMBOL[y]
> ]
Thanks for the example. Isn't just implementing a class Sub in SymPy
(+conversion methods) a better solution? It is like having the
Integral or Derivative class,
it also isn't used by default, but if the user requests it, he can have it.
On Wed, Jun 18, 2008 at 10:45 AM, Robert Kern <[EMAIL PROTECTED]> wrote:
>
> On Wed, Jun 18, 2008 at 03:29, Ondrej Certik <[EMAIL PROTECTED]> wrote:
>
>>>> It does, but it can be easily fixed, see above. I.e. fixing your
>>>> algorithm. :) The other option, as you said, is fixing sympy. We would
>>>> have to introduce a Sub class.
>>>> But I think it would just make things more complex. No?
>>>
>>> For all of sympy, yes. However, I think we could keep these
>>> transformations local to the cse module. You would have to implement
>>> just enough of Sub to replace Add(x, Mul(-constant, y)) and go back
>>> again.
>>
>> That's basically what my patch does.
>
> Yes, but down inside the guts of the CSE algorithm. My preference is
> to keep the core algorithm generic. It is currently entirely agnostic
> to the actual contents of the tree.
>
>> In terms of maintainability, I
>> think it's easier to maintain the two added lines, rather than a full
>> Sub class.
>
> If that were the only optimization, I would agree. However, this
> expression was the first I tested the algorithm on, and I found two
> places for optimization. I think we'll find more. Preprocess, CSE,
> then postprocess is more extensible, IMO, than adding special cases
> inside the CSE. I think that the product-of-powers case can only
> really be done by preprocessing, so we might as well do all of the
> optimizations by preprocessing. Unit testing is easier by separating
> the concerns of optimizing the representation and doing CSE. It opens
> the possibility for the user to select the optimizations they need.
>
> These are also things that can be added later, so having the core CSE
> implementation could go in right away (pending unit tests and multiple
> expressions).
I agree. But you know what Linus says[1], right :), so the current options are:
1) commit your patch as is and wait until someone fixes the x-y
problem in a general way
2) commit your patch + my patch + a good comment, that adding further
special cases are not acceptable and one should refactor it, and give
a reference to this thread,
3) do not commit anything, and wait until someone implements the general way
Each option has advantages and disadvantages, I think I myself am for
2), but if majority of you think we should just go the 1) or 3) way,
it's ok with me too.
Ondrej
[1] http://lkml.org/lkml/2000/8/25/132
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
