February 2007 - GiNaC-devel

[PATCH] fix incorrect result: degree(c*x^(-1), x^(-1)) gives zero
by Alexei Sheplyakov 01 Mar '07

01 Mar '07

Hello! degree(c*x^(-1), x^(-1)) (in ginsh notation) gives zero instead of expected 1. On the other hand, degree(x^(-1), x^(-1)) and coeff(c*x^(-1), x^(-1)) work fine. This patch makes degree (and ldegree) work correct with such arguments. --- ginac/mul.cpp | 12 ++++++++++-- 1 files changed, 10 insertions(+), 2 deletions(-) diff --git a/ginac/mul.cpp b/ginac/mul.cpp index dd96a70..9bbcd61 100644 --- a/ginac/mul.cpp +++ b/ginac/mul.cpp @@ -315,7 +315,11 @@ int mul::degree(const ex & s) const epvector::const_iterator i = seq.begin(), end = seq.end(); while (i != end) { if (ex_to<numeric>(i->coeff).is_integer()) - deg_sum += i->rest.degree(s) * ex_to<numeric>(i->coeff).to_int(); + deg_sum += recombine_pair_to_ex(*i).degree(s); + else { + if (i->rest.has(s)) + throw std::runtime_error("mul::degree() undefined degree because of non-integer exponent"); + } ++i; } return deg_sum; @@ -328,7 +332,11 @@ int mul::ldegree(const ex & s) const epvector::const_iterator i = seq.begin(), end = seq.end(); while (i != end) { if (ex_to<numeric>(i->coeff).is_integer()) - deg_sum += i->rest.ldegree(s) * ex_to<numeric>(i->coeff).to_int(); + deg_sum += recombine_pair_to_ex(*i).ldegree(s); + else { + if (i->rest.has(s)) + throw std::runtime_error("mul::ldegree() undefined degree because of non-integer exponent"); + } ++i; } return deg_sum; -- 1.4.4.4 Best regards, Alexei -- All science is either physics or stamp collecting.

2 1

[PATCH] Update documentation on extending GiNaC
by Alexei Sheplyakov 22 Feb '07

22 Feb '07

--- doc/examples/mystring.cpp | 104 +++++++++++++++++++++++++++++++++++++++++++++ doc/tutorial/ginac.texi | 51 ++++++++++++++-------- 2 files changed, 136 insertions(+), 19 deletions(-) diff --git a/doc/examples/mystring.cpp b/doc/examples/mystring.cpp new file mode 100644 index 0000000..cf0d8a2 --- /dev/null +++ b/doc/examples/mystring.cpp @@ -0,0 +1,104 @@ +/** + * @file mystring.cpp Example of extending GiNaC: writing new classes + */ +#include <iostream> +#include <string> +#include <stdexcept> +using namespace std; + +#include <ginac/ginac.h> +using namespace GiNaC; + +class mystring : public basic +{ + GINAC_DECLARE_REGISTERED_CLASS(mystring, basic) + +public: + mystring(const string &s); + mystring(const char *s); + ex eval(int level) const; + +private: + string str; + +protected: + void do_print(const print_context &c, unsigned level = 0) const; + +}; + +GINAC_IMPLEMENT_REGISTERED_CLASS_OPT(mystring, basic, + print_func<print_context>(&mystring::do_print)) + +// ctors +mystring::mystring() : inherited(&mystring::tinfo_static) { } +mystring::mystring(const string &s) : inherited(&mystring::tinfo_static), str(s) { } +mystring::mystring(const char *s) : inherited(&mystring::tinfo_static), str(s) { } + +// comparison +int mystring::compare_same_type(const basic &other) const +{ + const mystring &o = static_cast<const mystring &>(other); + int cmpval = str.compare(o.str); + if (cmpval == 0) + return 0; + else if (cmpval < 0) + return -1; + else + return 1; +} + +// archiving/unarchiving +mystring::mystring(const archive_node &n, lst &sym_lst) : inherited(n, sym_lst) +{ + n.find_string("string", str); +} + +void mystring::archive(archive_node &n) const +{ + inherited::archive(n); + n.add_string("string", str); +} + +ex mystring::unarchive(const archive_node &n, lst &sym_lst) +{ + return (new mystring(n, sym_lst))->setflag(status_flags::dynallocated); +} + +// printing +void mystring::do_print(const print_context &c, unsigned level) const +{ + // print_context::s is a reference to an ostream + c.s << '\"' << str << '\"'; +} + +/** + * evaluation: all strings automatically converted to lowercase with + * non-alphabetic characters stripped, and empty strings removed + */ +ex mystring::eval(int level) const +{ + string new_str; + for (size_t i=0; i<str.length(); i++) { + char c = str[i]; + if (c >= 'A' && c <= 'Z') + new_str += tolower(c); + else if (c >= 'a' && c <= 'z') + new_str += c; + } + + if (new_str.length() == 0) + return 0; + else + return mystring(new_str).hold(); +} + +int main(int argc, char** argv) +{ + ex e = mystring("Hello, world!"); + cout << is_a<mystring>(e) << endl; + cout << ex_to<basic>(e).class_name() << endl; + cout << e << endl; + ex another = pow(mystring("One string"), 2*sin(Pi-mystring("Another string"))); + cout << another << endl; + return 0; +} diff --git a/doc/tutorial/ginac.texi b/doc/tutorial/ginac.texi index 2560703..2650462 100644 --- a/doc/tutorial/ginac.texi +++ b/doc/tutorial/ginac.texi @@ -7733,9 +7733,8 @@ The RTTI in GiNaC is based on two mechanisms: @item The @code{basic} class declares a member variable @code{tinfo_key} which -holds an unsigned integer that identifies the object's class. These numbers -are defined in the @file{tinfos.h} header file for the built-in GiNaC -classes. They all start with @code{TINFO_}. +holds a variable of @code{tinfo_t} type (which is actually just +@code{const void*}) that identifies the object's class. @item By means of some clever tricks with static members, GiNaC maintains a list @@ -7772,17 +7771,6 @@ using namespace std; using namespace GiNaC; @end example -The first thing we have to do is to define a @code{tinfo_key} for our new -class. This can be any arbitrary unsigned number that is not already taken -by one of the existing classes but it's better to come up with something -that is unlikely to clash with keys that might be added in the future. The -numbers in @file{tinfos.h} are modeled somewhat after the class hierarchy -which is not a requirement but we are going to stick with this scheme: - -@example -const unsigned TINFO_mystring = 0x42420001U; -@end example - Now we can write down the class declaration. The class stores a C++ @code{string} and the user shall be able to construct a @code{mystring} object from a C or C++ string: @@ -7866,11 +7854,14 @@ which are the two constructors we declared. Let's proceed step-by-step. The default constructor looks like this: @example -mystring::mystring() : inherited(TINFO_mystring) @{@} +mystring::mystring() : inherited(&mystring::tinfo_static) @{@} @end example The golden rule is that in all constructors you have to set the -@code{tinfo_key} member to the @code{TINFO_*} value of your class. Otherwise +@code{tinfo_key} member to the @code{&your_class_name::tinfo_static} +@footnote{each GiNaC class has static member called tinfo_static. +This member is declared by the GINAC_DECLARE_REGISTERED_CLASS macros +and defined by the GINAC_IMPLEMENT_REGISTERED_CLASS macros}. Otherwise it will be set by the constructor of the superclass and all hell will break loose in the RTTI. For your convenience, the @code{basic} class provides a constructor that takes a @code{tinfo_key} value, which we are using here @@ -7960,8 +7951,8 @@ all relevant member variables. Now the only thing missing is our two new constructors: @example -mystring::mystring(const string &s) : inherited(TINFO_mystring), str(s) @{@} -mystring::mystring(const char *s) : inherited(TINFO_mystring), str(s) @{@} +mystring::mystring(const string &s) : inherited(&mystring::tinfo_static), str(s) @{@} +mystring::mystring(const char *s) : inherited(&mystring::tinfo_static), str(s) @{@} @end example No surprises here. We set the @code{str} member from the argument and @@ -8100,7 +8091,7 @@ public: ex mystring::eval(int level) const @{ string new_str; - for (int i=0; i<str.length(); i++) @{ + for (size_t i=0; i<str.length(); i++) @{ char c = str[i]; if (c >= 'A' && c <= 'Z') new_str += tolower(c); @@ -8198,6 +8189,28 @@ should become a need. That's it. May the source be with you! +@subsection Upgrading extension classes from older version of GiNaC + +If you got some extension classes for GiNaC 1.3.X some changes are +necessary in order to make your code work with GiNaC 1.4. + +@itemize @bullet +@item constructors which set @code{tinfo_key} such as + +@example +myclass::myclass() : inherited(TINFO_myclass) @{@} +@end example + +need to be rewritten as + +@example +myclass::myclass() : inherited(&myclass::tinfo_static) @{@} +@end example + +@item TINO_myclass is not necessary any more and can be removed. + +@end itemize + @node A comparison with other CAS, Advantages, Adding classes, Top @c node-name, next, previous, up -- 1.4.4.4 -- All science is either physics or stamp collecting.

1 0

real/imag parts of add.
by Chris Dams 19 Feb '07

19 Feb '07

Dear all, In add::real_part and add::imag_part it was not yet tested whether the real/imag parts were nonzero. I now added these tests. A patch is in CVS. Best wishes, Chris

1 0

pseries patch
by Vladimir Kisil 13 Feb '07

13 Feb '07

Dear All, I come across an inability of GiNaC to compute simple series, e.g. in the following example: #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main(){ possymbol t("t"); cout << pow(2-sqrt(1-t), -1).series(t==0,2) << endl; cout << pow(1-sqrt(1-pow(t,2)), -1).series(t==0,2) << endl; } A simple patch included in the attachment seems to solve the issue. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

4 5

Re: [GiNaC-list] pseries patch
by Vladimir Kisil 12 Feb '07

12 Feb '07

Dear Alexei, ASh> I propose this patch instead: Yes, this is better, but ASh> + if (eb.info(rational_function)) should it be like that: + if (eb.info(info_flags::rational_function)) Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

2 1

Less indices in epxressions.
by Chris Dams 07 Feb '07

07 Feb '07

Dear all, I already mentioned this idea quite a few years ago, but I think it really would be good to have. The idea is to turn contractions of an object with something else that has a single index into one object. A new notation for the output would be necessary for this and I guess using a colon would not be bad. That way we would get A~mu~nu*v.mu*w.nu -> A:v:w. The advantages are: * More compact expressions, hence more efficient to store; * More efficient to manipulate because functions like simplify_indexed would have fewer indices to rename. Not to mention automatic dummy index renaming. * More readable output, because if the factors in the example just-given end up somewhere near the beginning of a large product, somewhere near the middle and somewhere near the end it realy isn't readable. Also a notation for the inner product would be necessary. I think something like v:w or maybe inp(v,w) would be nice. I think in the case of a contraction with a tensor I could simply add a flag to the class idx that indicates whether the index is really an index or is a contraction. The point is that we should still store the dimension in the case one is doing dimensional regularization. What do you think? Chris

1 0

No more exit from numeric.cpp
by Chris Dams 07 Feb '07

07 Feb '07

Dear all, I now removed the exit-statements from numeric.cpp and use again array indices instead of push backs for the Lanczos coefficients. That way it should be clear enough from the indices if somebody by incident deletes a line somewhere. Best wishes, Chris

1 0

Release of GiNaC 1.3.7
by Jens Vollinga 05 Feb '07

05 Feb '07

Hello everybody, GiNaC 1.3.7 is out and available. The changes are: - Fixed bug in expansion of power. - Fixed bugs in functions S() (infinite loop), H() and zeta() (wrong results). - Rebuilt bison related files with bison version 2.3 (fixes parse error bugs). - Improved power::eval(). - Improved libreadline detection. As always, this release can be downloaded from http://www.ginac.de/Download.html Best wishes, Jens

1 0

upcoming release
by Jens Vollinga 05 Feb '07

05 Feb '07

Dear all, I am now starting to do the 1.3.7 release. @Alexei: I put your patch into CVS. Thanks! Regards, Jens

1 0

Fixed bug in power::expand_mul, but .....
by Chris Dams 01 Feb '07

01 Feb '07

Dear all, I fixed a bug in power::expand_mul by calling the method mul::combine_pair_with_coeff_to_pair from this function. However, the comments are strongly discouraging. They say, as you can read in the source: "it is safe not to call mul::combine_pair_with_coeff_to_pair() since n is an integer". So, basically I am rather rudely ignoring the comments, but I really don't understand what is unsafe about this method, so maybe someone can enlighten me. Many thanks, Chris

2 2