Pynac comparison functions do not provide a SWO #9880

jpflori · 2010-09-09T09:01:09Z

Here is a short example found by Burcin and reproducing the bug:

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()

This is already being discussed here: http://groups.google.com/group/sage-support/browse_thread/thread/7c85f02c76012722

The following patches are for the Sage library to enable access to the PyNaC order and randomly test that it is a SWO:

Install the package from here: http://boxen.math.washington.edu/home/jpflori/spkg/pynac-0.3.0.spkg

Then apply

Depends on #13213
Depends on #9890
Depends on #14550

CC: @kcrisman @zimmermann6

Component: symbolics

Keywords: pynac spkg

Author: Burcin Erocal, Jean-Pierre Flori, Volker Braun

Reviewer: Burcin Erocal, Jean-Pierre Flori

Merged: sage-5.11.beta0

Issue created by migration from https://trac.sagemath.org/ticket/9880

The text was updated successfully, but these errors were encountered:

jpflori · 2010-09-29T14:10:17Z

The bug happened because of the comparison functions which are used in a call to std::sort.

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.

I tested the above fix with pynac 0.2.1.

jpflori · 2010-10-11T14:51:48Z

Attachment: trac9880_pynac_order_burcin_original.patch.gz

Burcin original patch

jpflori · 2010-10-11T14:52:10Z

Patch to apply on top of the other one

jpflori · 2010-10-11T14:57:20Z

comment:3

Attachment: trac9880-pynac_order_jp_new.patch.gz

We've been working on a patch to fix the issue.

Original discussion is here:

http://groups.google.com/group/pynac-devel/browse_thread/thread/a36020bf9208bf08/abdf6671ef0b926a#abdf6671ef0b926a

Burcin produced a patch restoring GiNaC original order for internal use and using the new ones only for printing ; thus fixing the bug.

I then worked on top of it to get a more consistent order.

You can test them using pynac 0.2.1 from #9901 ("cd spkg/standard/pynac-0.2.1/src/" then "hg import" both patches and build/install, you should "./sage -b" if upgrading from a previous version of pynac).

I don't consider that version as definitve, but would like to get some feedback on the order used for printing.

I don't use everything pynac provides so it is more than probable that some expression are not correctly printed now.

Do not hesitate to report it.

kcrisman · 2010-11-18T16:11:14Z

comment:5

#10282 almost certainly is the same thing.

kcrisman · 2010-11-18T16:18:04Z

comment:6

Fixing this probably will close #9632 - just putting that here for the record.

vbraun · 2010-11-24T01:20:48Z

comment:7

Apply trac_9880_revert_marking_random_from_trac_10187.patch to re-enable doctests that fail on OSX/PPC.

kcrisman · 2010-11-24T03:39:11Z

comment:8

(Just OS X, not any particular architecture, I think.)

vbraun · 2010-12-01T14:07:35Z

Attachment: trac_9880_revert_marking_random_from_trac_10187.patch.gz

Re-enable doctests that fail on PPC due to this issue (updated)

kcrisman · 2011-01-13T16:08:17Z

comment:9

I don't use everything pynac provides so it is more than probable that some expression are not correctly printed now.

Do not hesitate to report it.

I'd like to test this at some point, but have two problems.

There is too much C++ for me to review it properly, unless a lot of it really is just reverting. Is there an easy way to figure out what is actual new code, and what is going back to something more-or-less Ginac?
I am not sure exactly what sort of expressions would not be properly printed. Can you give any kind of example of what sort of bad behavior to look for with testing (perhaps randomized)?

jpflori · 2011-01-13T16:34:56Z

comment:10

I guess there are two main parts in this ticket, I did not have a look for a long time, so all this should be taken carefully :

Burcin patch which (more or less) revert the internal ordering in Pynac to the original one in Ginac and create new methods to use a different order for printing. We could maybe only apply the part reverting the internal order to Ginac original one to get the bug solved and close this ticket.
However, it is not a solution to use Ginac order for printing because it is quite random and unpredictable, it depends on variable order creation among others. That's the reason for the different order for printing (and getting operands and so on). It was not quite coherent, whence my patch to make it a little better. We could merge that in a second ticket. By the way, the order implemented right now should be more or less degrevlex.
With that new framework, we could also quite easily allow the use of different orders for manipulating (ie printing, getting operands...) symbolic expressions in Sage (Burcin already mentionned that somewhere on the Web IIRC).
I think there is still work to do regarding expressions manipulation (see easier access to operands of a symbolic expression #9989)
I don't really have an idea of what could get misprinted with Burcin+my patch applied. You could try multivariate polynomials to check it follows degrevlex, then such expressions times exponentials and let me know what you feel.

vbraun · 2011-01-13T16:36:11Z

comment:11

I could review the c++ but the code in the ticket seems to work for me. If it segfaults for you, how about including a full sage session with a stack backtrace at the very least?

jpflori · 2011-01-13T16:47:42Z

comment:12

There is all you are asking for in the original discussion linked in the ticket description.

Maybe something changed since then, the ticket is quite old.

jpflori · 2011-01-13T17:15:34Z

comment:13

As far as I'm concerned, it still segfaults with the Sage 4.6 package for 32-bit Ubuntu provided on sagemath.org, as well as on a 64 bit Sage 4.6 that I built myself.

I did not test it any 4.6.1 alpha or rc yet.

jpflori · 2011-01-14T07:31:44Z

comment:14

I finally got Sage 4.6.1 final built from scratch, and:

indeed the specific instance of the bug mentionned here is no longer present
however, it does not mean that the bug is solved because:
- nothing changed in pynac (IIRC)
- the problem in the ordering used by pynac (which caused the bug when called within std::sort) are still present, I'll post a problematic expression asap

By the way, the problem of different ordering on different architecture should still be present (10187#!comment:39).

jpflori · 2011-01-14T09:36:42Z

comment:15

Ok, here is a kind of strange example for the problems of ordering still hapenning with Sage 4.6.1:

sage: b_0,b_1,b_2=var('b_0,b_1,b_2')
sage: f = 1/27*b_2^2/(2^b_2)^2 + 1/27*b_1^2/(2^b_1)^2 + 1/27*b_0^2/(2^b_0)^2 + 1/27*b_2/(2^b_2)^2 - 2/81/(2^b_2)^2 + 1/27*b_1/(2^b_1)^2 + 8/243/(2^b_2)^2 - 1/81*b_0/(2^b_0)^2 - 1/27*b_1^2/((2^b_2)^2*(2^b_1)^2) - 1/27*b_0^2/((2^b_2)^2*(2^b_0)^2) - 20/243/(2^b_1)^2 + 1/9/2^b_0 + 4/81*b_0/(2^b_0)^2 - 8/243/(2^b_2)^2 - 2/9/(2^b_2*2^b_1) - 2/9/(2^b_2*2^b_0) + 8/243/(2^b_1)^2 - 1/9/2^b_0 + 2/9/(2^b_2*2^b_1) + 2/9/(2^b_2*2^b_0) - 2/27*b_1*b_2/((2^b_2)^2*(2^b_1)^2) - 1/27*b_2^2/((2^b_2)^2*(2^b_1)^2) - 2/27*b_0*b_2/((2^b_2)^2*(2^b_0)^2) - 1/27*b_2^2/((2^b_2)^2*(2^b_0)^2) + 2/81/(2^b_1)^2 - 1/27*b_0^2/((2^b_1)^2*(2^b_0)^2) - 2/27*b_0*b_1/((2^b_1)^2*(2^b_0)^2) - 1/27*b_1^2/((2^b_1)^2*(2^b_0)^2) - 2/81/(2^b_0)^2 + 5/27*b_1/((2^b_2)^2*(2^b_1)^2) + 5/27*b_2/((2^b_2)^2*(2^b_1)^2) + 5/27*b_0/((2^b_2)^2*(2^b_0)^2) + 5/27*b_2/((2^b_2)^2*(2^b_0)^2) + 5/27*b_0/((2^b_1)^2*(2^b_0)^2) + 5/27*b_1/((2^b_1)^2*(2^b_0)^2) - 4/81/((2^b_2)^2*(2^b_1)^2) + 1/27*b_0^2/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) + 2/27*b_0*b_1/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) + 2/27*b_0*b_2/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) + 1/27*b_1^2/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) + 2/27*b_1*b_2/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) + 1/27*b_2^2/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) - 4/81/((2^b_2)^2*(2^b_0)^2) - 4/81/((2^b_1)^2*(2^b_0)^2) - 11/27*b_0/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) - 11/27*b_1/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) - 11/27*b_2/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) + 64/81/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) + 35/81
sage: f
1/27*b_2^2/(2^b_2)^2 + 1/27*b_1^2/(2^b_1)^2 + 1/27*b_0^2/(2^b_0)^2 + 1/27*b_2/(2^b_2)^2 + 1/27*b_1/(2^b_1)^2 - 8/243/(2^b_2)^2 + 2/9/(2^b_2*2^b_1) + 2/9/(2^b_2*2^b_0) - 2/27*b_1*b_2/((2^b_2)^2*(2^b_1)^2) - 1/27*b_2^2/((2^b_2)^2*(2^b_1)^2) - 2/27*b_0*b_2/((2^b_2)^2*(2^b_0)^2) - 1/27*b_2^2/((2^b_2)^2*(2^b_0)^2) + 14/243/(2^b_1)^2 + 1/27*b_0/(2^b_0)^2 + 2/243/(2^b_2)^2 - 2/9/(2^b_2*2^b_1) - 2/9/(2^b_2*2^b_0) - 1/27*b_1^2/((2^b_2)^2*(2^b_1)^2) - 1/27*b_0^2/((2^b_2)^2*(2^b_0)^2) - 20/243/(2^b_1)^2 - 1/27*b_0^2/((2^b_1)^2*(2^b_0)^2) - 2/27*b_0*b_1/((2^b_1)^2*(2^b_0)^2) - 1/27*b_1^2/((2^b_1)^2*(2^b_0)^2) - 2/81/(2^b_0)^2 + 5/27*b_1/((2^b_2)^2*(2^b_1)^2) + 5/27*b_2/((2^b_2)^2*(2^b_1)^2) + 5/27*b_0/((2^b_2)^2*(2^b_0)^2) + 5/27*b_2/((2^b_2)^2*(2^b_0)^2) + 5/27*b_0/((2^b_1)^2*(2^b_0)^2) + 5/27*b_1/((2^b_1)^2*(2^b_0)^2) - 4/81/((2^b_2)^2*(2^b_1)^2) + 1/27*b_0^2/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) + 2/27*b_0*b_1/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) + 2/27*b_0*b_2/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) + 1/27*b_1^2/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) + 2/27*b_1*b_2/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) + 1/27*b_2^2/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) - 4/81/((2^b_2)^2*(2^b_0)^2) - 4/81/((2^b_1)^2*(2^b_0)^2) - 11/27*b_0/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) - 11/27*b_1/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) - 11/27*b_2/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) + 64/81/((2^b_2)^2*(2^b_1)^2*(2^b_0)^2) + 35/81

The expression for f should get (a little bit) simplified.

For example, there are different summands where the only symbolic expressions used are (2!^b_2)!-2 and they should get automatically gathered when pynac creates the object.

In fact calling expand() method on f gives you the right expression, but if things were working correctly you should not have to do this.

gagern · 2011-01-20T08:10:21Z

comment:16

Can someone experiencing this bug please provide a gdb backtrace? There is a (small) possibility that this issue here might be related to an issue I encounter with sage on Gentoo Linux (with segfault in PyNaC as well), and I'd like to know for sure whether the error occurs inside the function __cxxabiv1::__cxa_allocate_exception or not.

jpflori · 2011-01-20T10:51:02Z

comment:17

The detailed description of the segfault mentionned here is available in the discussion mentionned in the ticket description.

I'll put it here so that everybody finds it:

the segfault happens in a call to std::sort() in a call to compare() because the ordering used by pynac is not a strict weak ordering. so it is kind of random. and I think youre bug is completely unrelated.
the piece of code in the ticket description do not produce the segfault anymore since sage 4.6.1 (still present in 4.6.0), however the order was not changed, so it could still happen with other pieces of code, so here is a backtrace produce with a previous version of sage:

!#0 GiNaC::power::compare (this=0x449be20, other=...) at !power.cpp:899
!#1 0x00007fffd7a9cc18 in void
std::!__unguarded_linear_insert<!__gnu_cxx::!__normal_iterator<GiNaC::expair*,
std::vector<GiNaC::expair, std::allocatorGiNaC::expair > >,
GiNaC::expair,
GiNaC::expair_rest_is_less>(!__gnu_cxx::!__normal_iterator<GiNaC::expair*,
std::vector<GiNaC::expair, std::allocatorGiNaC::expair > >,
GiNaC::expair, GiNaC::expair_rest_is_less) ()
from /home/jp/boulot/thèse/sage/sage-4.5.2/local/lib/
libpynac-0.2.so.0
!#2 0x00007fffd7a9cefa in void
std::!__final_insertion_sort<!__gnu_cxx::!__normal_iterator<GiNaC::expair*,
std::vector<GiNaC::expair, std::allocatorGiNaC::expair > >,
GiNaC::expair_rest_is_less>(!__gnu_cxx::!__normal_iterator<GiNaC::expair*,
std::vector<GiNaC::expair, std::allocatorGiNaC::expair > >,
!__gnu_cxx::!__normal_iterator<GiNaC::expair*,
std::vector<GiNaC::expair, std::allocatorGiNaC::expair > >,
GiNaC::expair_rest_is_less) () from /home/jp/boulot/thèse/sage/
sage-4.5.2/local/lib/libpynac-0.2.so.0
!#3 0x00007fffd7a95657 in
sort<!__gnu_cxx::!__normal_iterator<GiNaC::expair*,
std::vector<GiNaC::expair, std::allocatorGiNaC::expair > >,
GiNaC::expair_rest_is_less> (this=) at /usr/
include/c++/4.4/bits/!stl_algo.h:5260
!#4 GiNaC::expairseq::canonicalize (this=) at
!expairseq.cpp:1177
!#5 0x00007fffd7a994a4 in GiNaC::expairseq::construct_from_epvector
(this=0x44a5070, v=,
do_index_renaming=) at !expairseq.cpp:1055
!#6 0x00007fffd7a58685 in GiNaC::add::add (this=0x44a5070, vp=...,
oc=) at !add.cpp:100
!#7 0x00007fffd7a5871f in GiNaC::add::expand (this=0x449eb80,
options=) at !add.cpp:669
!#8 0x00007fffd7a9231d in GiNaC::ex::expand (this=, options=3620337048) at !ex.cpp:78
!#9 0x00007fffd773e386 in
!__pyx_pf_4sage_8symbolic_10expression_10Expression_expand
(!__pyx_v_self=,
!__pyx_args=0x601160, !__pyx_kwds=0x0) at sage/symbolic/
!expression.cpp:13604
!#10 0x00007ffff7b107ca in call_function (f=0x44a4580, throwflag=) at Python/!ceval.c:3706
!#11 PyEval_EvalFrameEx (f=0x44a4580, throwflag=)
at Python/!ceval.c:2389
!#12 0x00007ffff7b124ad in PyEval_EvalCodeEx (co=0x79c4c0,
globals=, locals=,
args=0x0,
argcount=, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/!ceval.c:2968
!#13 0x00007ffff7b12582 in PyEval_EvalCode (co=0x449be20,
globals=0x1135200007879, locals=0x7fffd7c9f598) at Python/!ceval.c:522
!#14 0x00007ffff7b3014c in run_mod (
.
.
.

And valgrind output also:
==27910== Invalid read of size 8
==27910== at 0x282C4BF1: void
std::!__unguarded_linear_insert<!__gnu_cxx::!__normal_iterator<GiNaC::expair*,
std::vector<GiNaC::expair, std::allocatorGiNaC::expair > >,
GiNaC::expair,
GiNaC::expair_rest_is_less>(!__gnu_cxx::!__normal_iterator<GiNaC::expair*,
std::vector<GiNaC::expair, std::allocatorGiNaC::expair > >,
GiNaC::expair, GiNaC::expair_rest_is_less) (!ptr.h:99)
==27910== by 0x282C4EF9: void
std::!__final_insertion_sort<!__gnu_cxx::!__normal_iterator<GiNaC::expair*,
std::vector<GiNaC::expair, std::allocatorGiNaC::expair > >,
GiNaC::expair_rest_is_less>(!__gnu_cxx::!__normal_iterator<GiNaC::expair*,
std::vector<GiNaC::expair, std::allocatorGiNaC::expair > >,
!__gnu_cxx::!__normal_iterator<GiNaC::expair*,
std::vector<GiNaC::expair, std::allocatorGiNaC::expair > >,
GiNaC::expair_rest_is_less) (!stl_algo.h:2161)
==27910== by 0x282BD656: GiNaC::expairseq::canonicalize()
(!stl_algo.h:5260)
==27910== by 0x282C14A3:
GiNaC::expairseq::construct_from_epvector(std::vector<GiNaC::expair,
std::allocatorGiNaC::expair > const&, bool) (!expairseq.cpp:1055)
==27910== by 0x28280684:
GiNaC::add::add(std::auto_ptr<std::vector<GiNaC::expair,
std::allocatorGiNaC::expair > >, GiNaC::ex const&) (!add.cpp:100)
==27910== by 0x2828071E: GiNaC::add::expand(unsigned int) const
(!add.cpp:669)
==27910== by 0x282BA31C: GiNaC::ex::expand(unsigned int) const
(!ex.cpp:78)
==27910== by 0x28811385:
!__pyx_pf_4sage_8symbolic_10expression_10Expression_expand(_object*,
_object*, _object*) (!expression.cpp:13604)
==27910== by 0x4F137C9: PyEval_EvalFrameEx (!ceval.c:3706)
==27910== by 0x4F154AC: PyEval_EvalCodeEx (!ceval.c:2968)
==27910== by 0x4F15581: PyEval_EvalCode (!ceval.c:522)
==27910== by 0x4F3314B: PyRun_StringFlags (!pythonrun.c:1335)
==27910== by 0x4F122DD: PyEval_EvalFrameEx (!ceval.c:4437)
==27910== by 0x4F154AC: PyEval_EvalCodeEx (!ceval.c:2968)
==27910== by 0x4E9BDDE: function_call (!funcobject.c:524)
==27910== by 0x4E6FAA2: PyObject_Call (!abstract.c:2492)
==27910== by 0xD7E0981:
!__pyx_pf_4sage_9structure_11sage_object_load (!sage_object.c:7304)
==27910== by 0x4F137C9: PyEval_EvalFrameEx (!ceval.c:3706)
==27910== by 0x4F154AC: PyEval_EvalCodeEx (!ceval.c:2968)
==27910== by 0x4F15581: PyEval_EvalCode (!ceval.c:522)
==27910== by 0x4F14853: PyEval_EvalFrameEx (!ceval.c:4401)
==27910== by 0x4F154AC: PyEval_EvalCodeEx (!ceval.c:2968)
==27910== by 0x4F13844: PyEval_EvalFrameEx (!ceval.c:3802)
==27910== by 0x4F154AC: PyEval_EvalCodeEx (!ceval.c:2968)
==27910== by 0x4F13844: PyEval_EvalFrameEx (!ceval.c:3802)
==27910== Address 0x97e4280 is 16 bytes before a block of size 416
alloc'd
==27910== at 0x4C24CCC: operator new(unsigned long)
(!vg_replace_malloc.c:220)
==27910== by 0x28286727: std::vector<GiNaC::expair,
std::allocatorGiNaC::expair >::reserve(unsigned long)
(!new_allocator.h:89)
==27910== by 0x282C0D4A:
GiNaC::expairseq::make_flat(std::vector<GiNaC::expair,
std::allocatorGiNaC::expair > const&, bool) (!expairseq.cpp:1138)
==27910== by 0x282C149B:
GiNaC::expairseq::construct_from_epvector(std::vector<GiNaC::expair,
std::allocatorGiNaC::expair > const&, bool) (!expairseq.cpp:1051)
==27910== by 0x28280684:
GiNaC::add::add(std::auto_ptr<std::vector<GiNaC::expair,
std::allocatorGiNaC::expair > >, GiNaC::ex const&) (!add.cpp:100)
==27910== by 0x2828071E: GiNaC::add::expand(unsigned int) const
(!add.cpp:669)
==27910== by 0x282BA31C: GiNaC::ex::expand(unsigned int) const
(!ex.cpp:78)
==27910== by 0x28811385:
!__pyx_pf_4sage_8symbolic_10expression_10Expression_expand(_object*,
_object*, _object*) (!expression.cpp:13604)
==27910== by 0x4F137C9: PyEval_EvalFrameEx (!ceval.c:3706)
==27910== by 0x4F154AC: PyEval_EvalCodeEx (!ceval.c:2968)
==27910== by 0x4F15581: PyEval_EvalCode (!ceval.c:522)
==27910== by 0x4F3314B: PyRun_StringFlags (!pythonrun.c:1335)
==27910== by 0x4F122DD: PyEval_EvalFrameEx (!ceval.c:4437)
==27910== by 0x4F154AC: PyEval_EvalCodeEx (!ceval.c:2968)
==27910== by 0x4E9BDDE: function_call (!funcobject.c:524)
==27910== by 0x4E6FAA2: PyObject_Call (!abstract.c:2492)
==27910== by 0xD7E0981:
!__pyx_pf_4sage_9structure_11sage_object_load (!sage_object.c:7304)
==27910== by 0x4F137C9: PyEval_EvalFrameEx (!ceval.c:3706)
==27910== by 0x4F154AC: PyEval_EvalCodeEx (!ceval.c:2968)
==27910== by 0x4F15581: PyEval_EvalCode (!ceval.c:522)
==27910== by 0x4F14853: PyEval_EvalFrameEx (!ceval.c:4401)
==27910== by 0x4F154AC: PyEval_EvalCodeEx (!ceval.c:2968)
==27910== by 0x4F13844: PyEval_EvalFrameEx (!ceval.c:3802)
==27910== by 0x4F154AC: PyEval_EvalCodeEx (!ceval.c:2968)
==27910== by 0x4F13844: PyEval_EvalFrameEx (!ceval.c:3802)

vbraun · 2011-02-28T14:47:22Z

comment:18

Replying to @jpflori:

the segfault happens in a call to std::sort() in a call to compare() because the ordering used by pynac is not a strict weak ordering. so it is kind of random.

std::sort with anything but a strict weak ordering is a receipe for disaster. It is expected to crash, and it does in the example. So you are saying that we must never use GiNaC internal order for sorting.

I take it that expair_is_greater_degrevlex does implement a strict weak ordering, so it is safe to use with std::sort?

Is the patch in this ticket still relevant or has this been fixed elsewhere?

jpflori · 2011-02-28T17:22:19Z

comment:19

The problem is not the GiNaC original internal order (even if http://www.ginac.de/reference/structGiNaC_1_1expair__rest__is__less.html states it is not a SWO... at least using it makes the bug disappear and inconsistencies in automatic simplifications disappear; if it does not work, i guess it should be fixed by GiNaC team) but the modification of that order used in pynac (and so in Sage).

AFAIK the two patches here are still necessary, the segfault disappeared (!?!) but i still get some problems with automatic simplification as shown in #9880 comment:15.

the first patch (by Burcin) reverts the original GiNaC ordering for internal use (e.g. to be used in call to std::sort) in pynac and use the modified order only for printing (it should also be uesd at some point for operands access and so on).
the second one (by me) should be applied on top of the first one and tries to polish the order used for printing so that is looks more like degrevlex.

It should not be much more difficult to implement other orders for printing (and operands access).

vbraun · 2011-02-28T17:41:16Z

comment:20

I have a suspicion that gcc's std::sort implementation changed which hides the bug. But just because its hidden doesn't mean that its still there. I'm currently trying to install some old versions to test.

vbraun · 2011-03-01T13:19:47Z

comment:21

I don't understand the GiNaC documentation that you referred to (http://www.ginac.de/reference/structGiNaC_1_1expair__rest__is__less.html). They state it is not a SWO, and their example is that neither 3x<2x nor 2x<3x. But thats perfectly fine in a SWO, you can have incomparable elements. The only constraint on incomparable elements is transitivity, that is, if A and B are incomparable and B and C are incomparable then A and C are also incomparable. Do you understand why its not a SWO?

jdemeyer · 2013-05-28T20:29:24Z

Changed dependencies from #13213 to #13213, #14550

jdemeyer · 2013-05-28T20:29:24Z

comment:91

Please rebase to #14550.

burcin · 2013-05-29T08:07:56Z

comment:92

Replying to @jdemeyer:

Please rebase to #14550.

Done.

jdemeyer · 2013-05-29T12:33:25Z

comment:94

Please rebase to #9890 (the latest patch applies with fuzz 2).

jdemeyer · 2013-05-29T12:33:25Z

Changed dependencies from #13213, #14550 to #13213, #9890, #14550

burcin · 2013-05-29T12:56:44Z

comment:95

Attachment: trac_9880-fix_doctests-sage_5_10_beta2.take3.patch.gz

Replying to @jdemeyer:

Please rebase to #9890 (the latest patch applies with fuzz 2).

Done.

jdemeyer · 2013-06-06T12:35:30Z

Merged: sage-5.11.beta0

jpflori added c: symbolics labels Sep 9, 2010

jpflori assigned burcin Sep 9, 2010