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:
> Hello,
>
> I'm using Sage to do some symbolic computations.
> What I am basically trying to do is to compute sums made of terms of
> the form :
> cst_{i_0,...,i_d)*b_0^{i_0}*...*b_d^{i_d}*2^{-b_0-...-b_d}
> where the b_i are variables
> (i.e. a product of an exponential with b_i in the exponent by a
> multivariate polynomial in b_i)
> using functions (especially symbolic_sum) from sage.calculus.calculus.
> I am regularly calling expand() and simplify() functions as well as
> some custom functions using substitute() to get a more compact
> expression and avoid redundant terms.
> Everything works fine as long as the sums are not too "complicated",
> but Sage segfaults when they become too big.
> Running Sage with the -gdb flag, gives different errors according to
> which of my functions I am calling, but both errors seem to be related
> to a "compare" function in Pynac (SIGSEGV or SIGBUS):
>
> First error message :
> Program received signal SIGSEGV, Segmentation fault.
> GiNaC::power::compare (this=0x3281c20, other=...) at power.cpp:899
> 899 power.cpp: Aucun fichier ou dossier de ce type.
> in power.cpp
>
> Second error message :
> Program received signal SIGBUS, Bus error.
> GiNaC::mul::compare (this=0x83490e0, other=...) at mul.cpp:1174
> 1174 mul.cpp: Aucun fichier ou dossier de ce type.
> in mul.cpp
>
>
> My box is running a Debian unstable with packages from the
> experimental repository.
> My kernel version is 2.6.35, compiled by myself.
> My cpu is a Intel(R) Core(TM)2 Quad CPU Q6600.
> The error is happening with Sage 4.5.2 and 4.4.4.
> I compiled both of them myself with gcc (Debian 4.4.4-11) 4.4.5
> 20100824 (prerelease).
> I also tried the precompiled sage-4.5.2-linux-64bit-ubuntu_10.04_lts-
> x86_64-Linux which gives me the same result.
>
> 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.
> I am currently trying to compile Sage on another box to do another
> test.
> Any help will be appreciated, and thanks for a such a great piece of
> software.
>
> Best regards,
>
> Jean-Pierre Flori
>
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
> 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
This discussion should really be on pynac-devel. I set the Reply-To
address accordingly. I hope it works. ;)
On Fri, 1 Oct 2010 06:52:11 -0700 (PDT)
Jean-Pierre Flori <jpf...@gmail.com> wrote:
> Some remarks and questions...
>
> I guess the order you want is 'degrevlex' as Sage's default order for
> multivariate polynomial ring and as the name of your functions
> suggest.
> Am I wrong ?
You are right, some approximation of 'degrevlex'.
> At present, I did not modify a lot of things.
> A few signs, replaced seq[0] by the smallest item of the sequence
> sorted with the printing order.
Nice. I totally forgot about having to sort subexpressions.
> I guess we want symbolic variables to be bigger than numerics.
> So I changed the sign for different typeid's.
OK.
> What is your opinion about symbolic exponents ?
> (If I am not wrong, in mul object, they are encapsulated in power
> object so it counts for 1.
> So total_degree(a^b*x) == 2.)
> In the compare_mul_power, you decided to compare the exponent of the
> power object to the one of the smallest item (which could in fact be
> the same power object) of the mul object if it is symbolic.
> So 3*x^y will be smaller than x^y (considering that y > 1).
> That is not a "real" problem because 3*x^y+x^y will be simplified into
> 4*x^y.
> But we also get that a^b > a^b*x (if b > 1) with the current strategy
> and it prints a^b + a^b*x...
It looks like you just need to return a^b < a^b*x. This is also what we
have now:
sage: var('a,b,x')
(a, b, x)
sage: a^b + a^b*x
a^b*x + a^b
Note that the patch reverses the order used for printing. AFAIR, it
used to be that we said x^3 < x^2 to be able to print x^3 + x^2.
> Shouldn't we consider the degree of the power is 1, so at least the
> above case is solved.
> Or do something more complicated comparing exponents...
If you always take the degree of power objects to be 1, you end up
saying a^b == a^c. Something more complicated is required there...
> I do not understand the comment of William Stein about symbols
> ordering.
> When a polynomial ring is created in Sage, the variables are ordered
> according to the order they were "created", i.e.
> PR.<x,y> = PolynomialRing(QQ) will result in x > y
> and PR.<y,x> = PolynomialRing(QQ) in y > x
He's probably trying to describe this order:
sage: var('z,x,y,a')
(z, x, y, a)
sage: a+x+y+z
a + x + y + z
Cheers,
Burcin
Thank you for the patch. I don't have time to test it right now, but
at least it applies cleanly on top of mine.
I will be offline for a couple of days at a meeting by a lake side
conference center in Austria, which unfortunately doesn't have wifi. I
should be able to respond to your message properly when I get back in
the weekend.
BTW, does your patch add a comparison operator for functions? We could
sort them alphabetically based on the function name for example. This
would resolve #9632.
Cheers,
Burcin
On Fri, 8 Oct 2010 17:00:29 -0700 (PDT)
Jean-Pierre Flori <jpf...@gmail.com> wrote:
> The version up now seems in a good shape.
> http://perso.telecom-paristech.fr/pynac_order-2.patch
This address gives a 404 error for me. Can you attach the patch to the
trac ticket?
> The few tests I ran for held expressions were ok.
>
> I forgot the idea of computing total exponents, that would slow
> everything down and would only introduce problems.
> The comparison is made kind of like before : symbolic exponents are
> wrapped inside power objects so that they count for 1 in total
> degrees, and those power kind of act like "new" variables.
> We get x^2 > x^a > x^b > x for example.
At the moment, we have this:
sage: var('a,b')
(a, b)
sage: x^2 + x^a + x^b + x
x^b + x^a + x^2 + x
How come the new order is different? Note that all these are power
objects, so the comparison functions of mul are not relevant here.
> The main thing I'm not completely happy with is the way we compare
> complex numbers with norm.
> We could maybe use GiNaC function.
> However when I tried it with hold, I got strange errors :
> HIT STUB : Number_T_to... unable...
> happening in numeric.cpp.
> The code I used is still within order.cpp but commented out.
I can take a look at this once I download the patch.
Thank you.
Burcin
I guess we'll have to do this.
Using a consistent order for __cmp__() is enough, so the printing order
is not necessary. Keeping the GiNaC order for __cmp__() would make it
much faster, though this will be
* very confusing to users,
* not consistent between different runs of Sage
There is not much of a choice really.
We will also have to change the operands(), iterator(), etc. functions
to address the operands in the printing order.
Cheers,
Burcin