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
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
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
+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
perhaps ex.is_zero(simplify=False) ?
> or may be a new method
>
> (2) ex.is_trivially_zero()
+1
Jason
--
Jason Grout
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
Cheers,
Golam
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
> 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