Hi, I condensed my previous post on subclassing symbol into this little program, which crashes at the last line. Any idea why? Is it a bug or do I just not understand C++ inheritance? #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main() { symbol x("x"); x = realsymbol("y"); cout << x << endl; } Jan
Dear Jan, I think it is crucial that you would provide the full definition of your derived class. Otherwise it is not possible to track the issue. Best wishes, Vladimir -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/
On Fri, 13 May 2016 19:16:29 +0200, Jan Rheinländer <jrheinlaender@gmx.de> said:
JR> Hi, I condensed my previous post on subclassing symbol into this JR> little program, which crashes at the last line. Any idea why? Is JR> it a bug or do I just not understand C++ inheritance? JR> #include <iostream> #include <ginac/ginac.h> using JR> namespace std; using namespace GiNaC; JR> int main() { symbol x("x"); x = realsymbol("y"); cout << x JR> << endl; } JR> Jan JR> _______________________________________________ GiNaC-devel JR> mailing list GiNaC-devel@ginac.de JR> https://www.cebix.net/mailman/listinfo/ginac-devel
Dear Vladimir, realsymbol is not my derived class. See ginac/symbol.h ! Am 13.05.2016 um 23:32 schrieb Vladimir V. Kisil:
Dear Jan,
I think it is crucial that you would provide the full definition of your derived class. Otherwise it is not possible to track the issue.
Best wishes, Vladimir
On Sat, 14 May 2016 04:53:54 +0200, Jan Rheinländer <jrheinlaender@gmx.de> said:
JR> Dear Vladimir, realsymbol is not my derived class. See JR> ginac/symbol.h ! Yes, and as far as I am aware there is no problem with realsymbol in GiNaC. Furthermore, in my own project (see the end of the email) I have successfully derived several new classes following the advise from the GiNaC tutorial. If you are looking for an assistance you need to provide a complete piece of software, including the full description of your derived class, which causes the issue. Best wishes, Vladimir -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/
Dear Jan, Please accept my apology, you did send a complete example and I have overseen that. In my opinion, the issue is not with the inheritance as such. Symbol x is not assumed to be a left value. There are GiNaC::ex for this. Best wishes, Vladimir -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/
On Sat, 14 May 2016 09:21:23 +0100, "Vladimir V. Kisil" <kisilv@maths.leeds.ac.uk> said:
On Sat, 14 May 2016 04:53:54 +0200, Jan Rheinländer <jrheinlaender@gmx.de> said:
JR> Dear Vladimir, realsymbol is not my derived class. See JR> ginac/symbol.h ! VVK> Yes, and as far as I am aware there is no problem with VVK> realsymbol in GiNaC. Furthermore, in my own project (see the VVK> end of the email) I have successfully derived several new VVK> classes following the advise from the GiNaC tutorial. VVK> If you are looking for an assistance you need to provide a VVK> complete piece of software, including the full description of VVK> your derived class, which causes the issue. VVK> Best wishes, Vladimir -- Vladimir V. Kisil VVK> http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius VVK> Transformations http://goo.gl/EaG2Vu Software: Geometry of VVK> cycles http://moebinv.sourceforge.net/ VVK> _______________________________________________ GiNaC-devel VVK> mailing list GiNaC-devel@ginac.de VVK> https://www.cebix.net/mailman/listinfo/ginac-devel
Dear All, I investigated the crash. It is caused by an infinite loop of calls in GiNaC::ex::ex at /usr/include/ginac/ex.h:265 in GiNaC::symbol::eval at /usr/include/ginac/symbol.h:49 in GiNaC::ex::construct_from_basic(GiNaC::basic const&) from /usr/lib/libginac.so.5 This happens because the assignment symbol x("x"); x = realsymbol("y"); is done through the inherited operator const basic & basic::operator=() which resets the status_flags::evaluated (for different classes) and this flag is never set again for symbols. Now the first question is: do we really want a symbol to be assigned through operator=? If the answer is "yes" then there is the second question is: to repair the situation either * an adjusted symbol::operator=() shall be provided, which sets the flag evaluated; or * at ex:eval() we shall set status_flags::evaluated for GiNaC::symbol and its children? Another option is: basic::operator= shall reset status_flags::evaluated only if another object is not of a child class. My understanding of GiNaC is not sufficient to take decision on this matter. Best wishes, Vladimir -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/
On Sat, 14 May 2016 10:03:26 +0100, "Vladimir V. Kisil" <kisilv@maths.leeds.ac.uk> said:
VVK> Dear Jan, VVK> Please accept my apology, you did send a complete VVK> example and I have overseen that. In my opinion, the issue is VVK> not with the inheritance as such. Symbol x is not assumed to be VVK> a left value. There are GiNaC::ex for this. VVK> Best wishes, Vladimir -- Vladimir V. Kisil VVK> http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius VVK> Transformations http://goo.gl/EaG2Vu Software: Geometry of VVK> cycles http://moebinv.sourceforge.net/
On Sat, 14 May 2016 09:21:23 +0100, "Vladimir V. Kisil" VVK> <kisilv@maths.leeds.ac.uk> said:
On Sat, 14 May 2016 04:53:54 +0200, Jan Rheinländer <jrheinlaender@gmx.de> said:
JR> Dear Vladimir, realsymbol is not my derived class. See JR> ginac/symbol.h ! VVK> Yes, and as far as I am aware there is no problem with VVK> realsymbol in GiNaC. Furthermore, in my own project (see the VVK> end of the email) I have successfully derived several new VVK> classes following the advise from the GiNaC tutorial. VVK> If you are looking for an assistance you need to provide a VVK> complete piece of software, including the full description of VVK> your derived class, which causes the issue. VVK> Best wishes, Vladimir -- Vladimir V. Kisil VVK> http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius VVK> Transformations http://goo.gl/EaG2Vu Software: Geometry of VVK> cycles http://moebinv.sourceforge.net/ VVK> _______________________________________________ GiNaC-devel VVK> mailing list GiNaC-devel@ginac.de VVK> https://www.cebix.net/mailman/listinfo/ginac-devel VVK> _______________________________________________ GiNaC-devel VVK> mailing list GiNaC-devel@ginac.de VVK> https://www.cebix.net/mailman/listinfo/ginac-devel
Hello,
I condensed my previous post on subclassing symbol into this little program, which crashes at the last line. Any idea why? Is it a bug or do
#include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC;
int main() { symbol x("x"); x = realsymbol("y");
Assigning an instance of a subclass is in general a bad idea, see https://en.wikipedia.org/wiki/Object_slicing In this particular case GiNaC::basic assignment operator resets status_flags::evaluated Thus when an ex gets constructed from the symbol here
cout << x << endl;
ex::construct_from_basic enters an infinite recursion in const ex tmpex & = other.eval(); since symbol::eval() is essentially a nop. Sooner or later the program exhausts the stack and segfaults. So this is sort of GiNaC bug, but it's certainly useful for it lets you know that your code is wrong. #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main() { symbol x("x"); x.dbgprinttree(); x = realsymbol("y"); x.dbgprinttree(); return 0; } x (symbol) @0x7ffc08327bc0, serial=1, hash=0x1, flags=0x6, domain=0 y (symbol) @0x7ffc08327bc0, serial=2, hash=0x1, flags=0x0, domain=0 So x remains complex (domain == 0) after assigning y. This is natural from C++ point of the view, however this is most likely not what you mean. Without the bug which triggers an infinite recursion the original problem (assigning an instance of a subclass) will be more difficult to find. Hope this helps, Alexey
Hello, thank you for your comments and explanations on C++ inheritance issues. I was away for two weeks and apologize for the delay in answering. I have a need to change the domain and the commutativity of a symbol after creation. From what I gather, this is not possible with the existing symbol class. So what I would try next is to define a new symbol subclass which stores domain and return_type in a member and has ::set operators to change them. Jan Am 15.05.2016 um 20:21 schrieb Alexey Sheplyakov:
Hello,
I condensed my previous post on subclassing symbol into this little program, which crashes at the last line. Any idea why? Is it a bug or do #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC;
int main() { symbol x("x"); x = realsymbol("y"); Assigning an instance of a subclass is in general a bad idea, see https://en.wikipedia.org/wiki/Object_slicing In this particular case GiNaC::basic assignment operator resets status_flags::evaluated
Thus when an ex gets constructed from the symbol here
cout << x << endl;
ex::construct_from_basic enters an infinite recursion in
const ex tmpex & = other.eval();
since symbol::eval() is essentially a nop. Sooner or later the program exhausts the stack and segfaults. So this is sort of GiNaC bug, but it's certainly useful for it lets you know that your code is wrong.
#include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC;
int main() { symbol x("x"); x.dbgprinttree(); x = realsymbol("y"); x.dbgprinttree(); return 0; }
x (symbol) @0x7ffc08327bc0, serial=1, hash=0x1, flags=0x6, domain=0 y (symbol) @0x7ffc08327bc0, serial=2, hash=0x1, flags=0x0, domain=0
So x remains complex (domain == 0) after assigning y. This is natural from C++ point of the view, however this is most likely not what you mean. Without the bug which triggers an infinite recursion the original problem (assigning an instance of a subclass) will be more difficult to find.
Hope this helps, Alexey _______________________________________________ GiNaC-devel mailing list GiNaC-devel@ginac.de https://www.cebix.net/mailman/listinfo/ginac-devel
participants (3)
-
Alexey Sheplyakov
-
Jan Rheinländer
-
Vladimir V. Kisil