It takes too long to check "x in list" in symbolics!

15 views
Skip to first unread message

Golam Mortuza Hossain

unread,
Aug 20, 2009, 7:11:13 AM8/20/09
to sage-...@googlegroups.com
Hi,

It takes too long to check whether x is in a list in new symbolics

---------
sage: var('x,x1,x2,x3,x4')
(x, x1, x2, x3, x4)
sage: f = function('f')
sage: mylist = [x1,x2,x3,x4,f(x1),f(x2),f(x3),f(x4)]

sage: timeit('x in mylist')
5 loops, best of 3: 461 ms per loop
--------

If your program needs to check it couple of more times
----------
sage: timeit('x in mylist')
5 loops, best of 3: 1.26 s per loop
sage: timeit('x in mylist')
5 loops, best of 3: 3.4 s per loop
----------

For a comparison
---------
sage: timeit('x1 in mylist')
625 loops, best of 3: 473 ns per loop
---------

Reason for this huge discrepancy stems from the fact that
except for last example, in all previous cases maxima is called
to check the equality.

Thus it seems, new symbolics depends on maxima for basic
operations even now.

I don't know the rationale behind this design given pynac has
a method to compare two symbolic expression (ex1.is_equal(ex2)).

In any case, this design ensures writing a program in new symbolics
where some basic tests like "if x in list" needs to done, is no better than
old symbolics.

Cheers,
Golam

William Stein

unread,
Aug 20, 2009, 12:28:26 PM8/20/09
to sage-...@googlegroups.com

That's not for any list, but it is for the one you constructed. I
think to get the new symbolics out at some point we finally gave in
and made the compare method fall back to Maxima (in case several
pynac-based methods failed) so that massive amounts of user code and
doctests wouldn't break. Fixing this is obviously something that
needs to be done. Hopefully you will do it! :-)

William

Golam Mortuza Hossain

unread,
Aug 20, 2009, 12:57:48 PM8/20/09
to sage-...@googlegroups.com
Hi,


That why I wrote "symbolics" in the title :-). BTW, I encountered
this while doing my own work using sage. So I consider this as
a serious drawback.


>  I
> think to get the new symbolics out at some point we finally gave in
> and made the compare method fall back to Maxima (in case several
> pynac-based methods failed) so that massive amounts of user code and
> doctests wouldn't break.  Fixing this is obviously something that
> needs to be done.  Hopefully you will do it! :-)

I guess, a policy decision is involved here as to whether use mathematical
identities by default or as an option during comparison. To clarify:

ex = sin(x)^2 + cos(x)^2 - 1

In pynac, for above expression "ex.is_zero()" test will result False by default
where as current maxima based comparison will return True.

Personally, I feel we should have a flag something like

(1) ex.is_zero(use_identity=False)

or may be a new method

(2) ex.is_trivially_zero()


So that users/developers can make their choice depending on their need.


Cheers,
Golam

William Stein

unread,
Aug 20, 2009, 1:02:50 PM8/20/09
to sage-...@googlegroups.com
On Thu, Aug 20, 2009 at 9:57 AM, Golam Mortuza

+1

>
>
>>  I
>> think to get the new symbolics out at some point we finally gave in
>> and made the compare method fall back to Maxima (in case several
>> pynac-based methods failed) so that massive amounts of user code and
>> doctests wouldn't break.  Fixing this is obviously something that
>> needs to be done.  Hopefully you will do it! :-)
>
> I guess, a policy decision is involved here as to whether use mathematical
> identities by default or as an option during comparison. To clarify:
>
> ex = sin(x)^2 + cos(x)^2 - 1
>
> In pynac, for above expression "ex.is_zero()" test will result False by default
> where as current maxima based comparison will return True.
>
> Personally, I feel we should have a flag something like
>
> (1) ex.is_zero(use_identity=False)
>
> or may be a new method
>
> (2) ex.is_trivially_zero()
>
>
> So that users/developers can make their choice depending on their need.
>

I can see no drawback to that. I like it. Explicit is better than implicit.

-- William

Jason Grout

unread,
Aug 20, 2009, 2:03:51 PM8/20/09
to sage-...@googlegroups.com


perhaps ex.is_zero(simplify=False) ?


> or may be a new method
>
> (2) ex.is_trivially_zero()


+1

Jason

--
Jason Grout

Golam Mortuza Hossain

unread,
Aug 20, 2009, 4:37:06 PM8/20/09
to sage-...@googlegroups.com
Hi,

On Thu, Aug 20, 2009 at 3:03 PM, Jason Grout<jason...@creativetrax.com> wrote:
>> I guess, a policy decision is involved here as to whether use mathematical
>> identities by default or as an option during comparison. To clarify:
>>
>> ex = sin(x)^2 + cos(x)^2 - 1
>>
>> In pynac, for above expression "ex.is_zero()" test will result False by default
>> where as current maxima based comparison will return True.
>>
>> Personally, I feel we should have a flag something like
>>
>> (1) ex.is_zero(use_identity=False)
>>
> perhaps ex.is_zero(simplify=False) ?


Yes, thats even better.

So the next BIG question is what should be the *default* value
of this flag for comparison? In other words, by default do we call
maxima or accept pynac's False return as definitive?

Personally, I am for accepting pynac's answer by default as it
would massively speed up test like "if x in list" for symbolics.


Cheers,
Golam

William Stein

unread,
Aug 21, 2009, 4:47:36 PM8/21/09
to sage-...@googlegroups.com

We must default to pynac, in my opinion.  The question then just becomes
how to make pynac's comparison better.
 



Cheers,
Golam





--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

Golam Mortuza Hossain

unread,
Aug 21, 2009, 7:36:51 PM8/21/09
to sage-...@googlegroups.com
Hi.

On Fri, Aug 21, 2009 at 5:47 PM, William Stein<wst...@gmail.com> wrote:
>
>> Personally, I am for accepting pynac's answer by default as it
>> would massively speed up test like "if x in list" for symbolics.
>
> We must default to pynac, in my opinion.  The question then just becomes
> how to make pynac's comparison better.

Cool. I just opened a ticket

http://trac.sagemath.org/sage_trac/ticket/6799

I will try to see how much breakage is caused by
a brutal swich-over.

Having something like a ".full_simplify()" within pynac should
be a gradual and long-term goal for sage symbolics.

Some relevant comments are in here

http://www.ginac.de/FAQ.html#sincos

Cheers,
Golam

Robert Bradshaw

unread,
Aug 22, 2009, 1:40:19 PM8/22/09
to sage-...@googlegroups.com
On Aug 21, 2009, at 1:47 PM, William Stein wrote:

> On Thu, Aug 20, 2009 at 1:37 PM, Golam Mortuza Hossain
> <gmho...@gmail.com> wrote:
>
> Hi,
>

> On Thu, Aug 20, 2009 at 3:03 PM, Jason Grout<jason-
> sa...@creativetrax.com> wrote:
> >> I guess, a policy decision is involved here as to whether use
> mathematical
> >> identities by default or as an option during comparison. To
> clarify:
> >>
> >> ex = sin(x)^2 + cos(x)^2 - 1
> >>
> >> In pynac, for above expression "ex.is_zero()" test will result
> False by default
> >> where as current maxima based comparison will return True.
> >>
> >> Personally, I feel we should have a flag something like
> >>
> >> (1) ex.is_zero(use_identity=False)
> >>
> > perhaps ex.is_zero(simplify=False) ?
>
>
> Yes, thats even better.
>
> So the next BIG question is what should be the *default* value
> of this flag for comparison? In other words, by default do we call
> maxima or accept pynac's False return as definitive?
>
> Personally, I am for accepting pynac's answer by default as it
> would massively speed up test like "if x in list" for symbolics.
>
> We must default to pynac, in my opinion. The question then just
> becomes
> how to make pynac's comparison better.

Once pynac's comparison is as good as maximas, it may well be just as
slow as well, so I'm not sure this solves the problem. We should, of
course, be asking pynac if they're equal first.

- Robert

Reply all
Reply to author
Forward
0 new messages