<snip>
> I didn't manage to reproduce the bug with a short and simple piece of
> code.
> However I can mail the source code and instructions to reproduce the
> bug to anyone who can help.
> I will also provide any information needed to investigate this
> problem.
Thanks for the report.
If you send me your example, I can take a look at it tomorrow.
Cheers,
Burcin
Here is a short example to replicate the first error mentioned below:
b = [var('b_%s'%i) for i in range(4)]
precomp = (2^b_2 + 2)*(2^b_1 + 2^(-b_1) + 2^b_1*2^b_0 - 2^b_1*2^(-b_0)
- 2^(-b_1)*2^b_0 - 2^(-b_1)*2^(-b_0) + 2^b_0 + 2^(-b_0) - 9) + (2^b_1 +
2^(-b_1) + 2^b_1*2^b_0 - 2^b_1*2^(-b_0) - 2^(-b_1)*2^b_0 -
2^(-b_1)*2^(-b_0) + 2^b_0 + 2^(-b_0) - 9)/2^b_2
repl_dict = {b_0: b_0, b_3: b_1, b_2: b_3, b_1: b_2}
P = precomp.substitute(repl_dict)
P.expand()
I will take a break now. I'd appreciate any help tracking down the
problem (in pynac) if anybody has the time.
Cheers,
Burcin
On Wed, 1 Sep 2010 08:25:07 -0700 (PDT)
Jean-Pierre Flori <jpf...@gmail.com> wrote:
On Thu, 9 Sep 2010 02:13:27 -0700 (PDT)
Jean-Pierre Flori <jpf...@gmail.com> wrote:
> I created a Ticket on Sage's Trac:
> http://trac.sagemath.org/sage_trac/ticket/9880
>
> It could be a problem with the comparison function
> "expair_rest_is_less" used by "std::sort" function like in the
> following link:
> http://gcc.gnu.org/ml/gcc-bugs/2010-08/msg01163.html
This is indeed the problem. Thanks for tracking it down.
In the process of adapting GiNaC for use in Sage, I changed the
comparison functions to give a consistent order between different runs.
Apparently, the new comparison functions I wrote are not consistent.
For a long time, I wanted to rip out these new functions, and use them
only for printing. The following patch is a first step towards this:
http://sage.math.washington.edu/home/burcin/pynac/pynac_order.patch
After applying this patch to pynac (see here [1] for instructions on
how to set up a pynac development environment), the segfault you
reported, and the bug at #9046 goes away.
Note that this is very much a work in progress. I didn't take care to
make sure these comparison functions are consistent either. In the
process of copying things over, I even flipped a few signs in the
results.
This needs much work to be finished, we need to make sure the order
is consistent and correct, and it matches the one currently used by
Sage. The issue of accessing the operands of a symbolic expression also
needs to be sorted out, but that's merely a user interface issue.
I'd appreciate help with any of this, since I don't have much time to
spend on Sage/pynac these days. I'd be glad to answer any questions
though.
Cheers,
Burcin
On Sun, 12 Sep 2010 09:21:12 -0700 (PDT)
Jean-Pierre Flori <jpf...@gmail.com> wrote:
> Thanks for the patch, I'll have a look at the comparison functions
> when I have some time, surely next week.
> Where can I find the one defined by Sage ?
They are spread out through the classes in pynac. Look for compare()
and compare_same_type() functions in mul, power, function, etc.
> I have another question: are the source codes of GiNaC and pynac still
> "synchronized" in some way ?
Not really. I pull some patches from GiNaC when I think they are
relevant.
> I saw that some recent changes are similar in both git repositories,
> but as I was going through the source code, I saw that
> numeric::do_print_csrc is defined in GiNaC but not in pynac.
The numeric class in pynac is completely rewritten to use python
objects instead of CLN. It's normal that those methods are missing.
Cheers,
Burcin
On Mon, 13 Sep 2010 04:58:00 -0700 (PDT)
Jean-Pierre Flori <jpf...@gmail.com> wrote:
> I've got some other questions:
These should be on a separate thread, on sage-devel or pynac-devel.
> - Sage and pynac do not realize that 2^(-b_0) and (2^b_0)^(-1) are
> equal.
> I guess there is no canonical way of expanding 2^(a*b) into something
> else, but it could be a good idea doing it when a or b is an integer
> and the other one a variable ?
I don't understand your suggestion. Are you saying we should
* expand 2^(-b) to (2^b)^(-1) or
* simplify (2^b)^(-1) to 2^(-b)?
Apart from a few simple modifications, e.g., exp(a)^b -> exp(a*b) when
possible, pynac keeps the automatic evaluation rules from GiNaC.
These operations effect the performance of the library quite a bit. We
should be careful before adding more of them, and perhaps consult the
GiNaC developers in the process.
> - Should symbolic sums be implemented into pynac (at some point...) to
> avoid calling Maxima ?
They should be implemented in Sage. I don't think this requires any
modification at the C++ level in the pynac library.
Actually, I am working on this right now.
> By the way calling symbolic_sum(1,x,0,b_0) gives me an error whereas
> calling sum(1,x,0,b_0) does not.
This is the difference between sage.misc.functional.symbolic_sum and
sage.calculus.calculus.symbolic_sum. The latter tries to convert the
output received from maxima to the parent of the given expression. In
your example, this is ZZ. The conversion fails of course. The wrapper
sage.misc.functional.symbolic_sum first converts the first argument to
a symbolic expression, which prevents the error.
When we move to new code in sage/symbolic/summation/* (which is not in
the library yet), things will be much cleaner.
Cheers,
Burcin
On Wed, 29 Sep 2010 07:00:39 -0700 (PDT)
Jean-Pierre Flori <jpf...@gmail.com> wrote:
> Ok, I have finally looked at the comparison functions and exchanging :
> cmpval = seq[0].coeff.compare(other.exponent);
> by
> cmpval = -seq[0].coeff.compare(other.exponent);
> in mul::compare_pow (mul.cpp:1265) seems to prevent the above bug from
> happening.
> It seems to fit better with the change made by William Stein in
> power::compare_same_type (power.cpp:951).
> However it doesn't mean the problem is completely solved...
> I'll try to take a deeper look at the comparison functions at some
> point.
Thank you for following up on this and taking the time to go through
the comparisons.
I was planning to build on the patch I posted before [1] to fix this
problem once and for all (perhaps rather optimistically).
[1] http://sage.math.washington.edu/home/burcin/pynac/pynac_order.patch
Note that your suggestions fixes your bug (#9880), but doesn't effect
#9046.
Cheers,
Burcin
> Maybe it is a good thing to keep the same order as ginac internally
> and your more usual ordering for printing.
It is good to keep the ginac ordering internally. The user friendly
ordering is more expensive so it slows down computations, even when
you don't print intermediate expressions.
> However if you'd better not duplicate code, I can look at the "-
> x^2+x^2" part of bug #9046.
> Now I may understand a big enough part of pynac code to do that.
That's right. You're one of the few people who spent so much time
staring at pynac code. :)
> But if you'd better use the above patch, that won't be necessary.
I would like to replace the orders completely. I wanted to attack
this problem for a long time. Now that we started, we might as
well finish. :)
Can you help put the patch in usable shape? At the moment the ordering
it defines is completely different from the one we use in Sage. This
must be because I changed some signs while I was copying code.
If you can make the ordering consistent, I can fix the other relevant
places (op(), etc.).
Thanks.
Burcin
> On 29 sep, 20:28, Burcin Erocal <bur...@erocal.org> wrote:
> > On Wed, 29 Sep 2010 09:48:25 -0700 (PDT)
> >
> > Jean-Pierre Flori <jpfl...@gmail.com> wrote:
> > > Maybe it is a good thing to keep the same order as ginac
> > > internally and your more usual ordering for printing.
> >
> > It is good to keep the ginac ordering internally. The user friendly
> > ordering is more expensive so it slows down computations, even when
> > you don't print intermediate expressions.
> My bad, I didn't read your previous post correctly, I thought that
> patch reverted the change you made in the ordering, but in fact it put
> these changes in separate functions and use them only for printing...
> That is why I tried to fix the bug in the code without your patch...
> So I guess I should work WITH the patch !
Yes, please work with the patch. :)
<snip>
> > > But if you'd better use the above patch, that won't be necessary.
> >
> > I would like to replace the orders completely. I wanted to attack
> > this problem for a long time. Now that we started, we might as
> > well finish. :)
> So once more I'm confused..
> What do you mean by replace the orders completely ?
> Having separate functions for internal use and printing as with what
> your patch does ?
<snip>
I want to continue with the patch, to go back to using the original
comparison functions from ginac and use the new ones only for printing.
> >
> > Can you help put the patch in usable shape? At the moment the
> > ordering it defines is completely different from the one we use in
> > Sage. This must be because I changed some signs while I was copying
> > code.
> I'll help with pleasure. Just want to be sure to take the right
> direction !
Thank you. Please don't hesitate to ask if you need any help.
Cheers,
Burcin
> Some remarks and questions...
<snip>
I replied to this on pynac-devel:
http://groups.google.com/group/pynac-devel/msg/f3032856d1ed6953
Cheers,
Burcin