- GiNaC-devel - ginac.de

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-234-g079c558
by git＠ginac.de 09 Nov '10

09 Nov '10

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via 079c558d4f9758cd2777a2808a02d64cb1f70c8e (commit) from cbb93fadabbd56ba006902967b15b2b2aebb037c (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 079c558d4f9758cd2777a2808a02d64cb1f70c8e Author: Alexei Sheplyakov <alexei.sheplyakov(a)gmail.com> Date: Tue Nov 9 08:27:47 2010 +0100 power::series(): handle someg (trivial) singularities of the exponent... ... so GiNaC can expand expressions like cos(x)^(sin(x)/x) // (x -> 0) (1 + x)^(1/x) // x -> 0 and so on. [Reported by Camille Gillot.] ----------------------------------------------------------------------- Summary of changes: check/exam_pseries.cpp | 18 ++++++++++++++++++ ginac/pseries.cpp | 23 +++++++++++++++++++++++ 2 files changed, 41 insertions(+), 0 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[PATCH] power::series(): handle some (trivial) singularities of the exponent...
by Alexei Sheplyakov 08 Nov '10

08 Nov '10

... so GiNaC can expand expressions like cos(x)^(sin(x)/x) // (x -> 0) (1 + x)^(1/x) // x -> 0 and so on. --- ginac/pseries.cpp | 23 +++++++++++++++++++++++ 1 files changed, 23 insertions(+), 0 deletions(-) diff --git a/ginac/pseries.cpp b/ginac/pseries.cpp index 4a8d7d6..c290fe0 100644 --- a/ginac/pseries.cpp +++ b/ginac/pseries.cpp @@ -1116,6 +1116,29 @@ ex power::series(const relational & r, int order, unsigned options) const must_expand_basis = true; } + bool exponent_is_regular = true; + try { + exponent.subs(r, subs_options::no_pattern); + } catch (pole_error) { + exponent_is_regular = false; + } + + if (!exponent_is_regular) { + ex l = exponent*log(basis); + // this == exp(l); + ex le = l.series(r, order, options); + // Note: expanding exp(l) won't help, since that will attempt + // Taylor expansion, and fail (because exponent is "singular") + // Still l itself might be expanded in Taylor series. + // Examples: + // sin(x)/x*log(cos(x)) + // 1/x*log(1 + x) + return exp(le).series(r, order, options); + // Note: if l happens to have a Laurent expansion (with + // negative powers of (var - point)), expanding exp(le) + // will barf (which is The Right Thing). + } + // Is the expression of type something^(-int)? if (!must_expand_basis && !exponent.info(info_flags::negint) && (!is_a<add>(basis) || !is_a<numeric>(exponent))) -- 1.7.2.3

1 0

msvc support patches
by Alexei Sheplyakov 08 Nov '10

08 Nov '10

Hello, Jens, could you please pull from git://github.com/AlexeiSheplyakov/GiNaC.git master.msvc.support The following changes since commit cbb93fadabbd56ba006902967b15b2b2aebb037c: mul: algebraic_subs_mul(), has(): don't write beyond the end of array (2010-10-09 18:39:41 +0200) are available: Jan Rheinländer (7): clifford: fix a few GCCisms (or, not). symmetry::compare_same_type(): const-correctness fix Add few defines for msvc (__func__, __alignof__). [msvc] Work around strange scoping and name mangling rules. [msvc] Yet another compiler bug work around. [msvc] msvc cannot handle string constants above 16k Omit extra qualification (as in struct foo f() vs foo f()). check/time_uvar_gcd.cpp | 35 +++++++++++++++++++++++------------ ginac/clifford.cpp | 6 +++--- ginac/compiler.h | 5 +++++ ginac/ex.h | 12 +++++++++++- ginac/exprseq.cpp | 6 ++++++ ginac/parser/parse_binop_rhs.cpp | 2 +- ginac/parser/parser.cpp | 3 +-- ginac/polynomial/collect_vargs.cpp | 2 +- ginac/symmetry.cpp | 2 +- 9 files changed, 52 insertions(+), 21 deletions(-) Best regards, Alexei

1 0

About a (poor) parity in expressions.
by Francois Maltey 18 Oct '10

18 Oct '10

Hello, I'm a ginac user because I use Sage, and I work around expressions. I discover that ginac remains function arguments (more than the other computer algebra system). So sin(x)+sin(-x) remains sin(x)+sin(-x), and I don't get 0. The only automatic rewrite rules I discover around signs and integers are : 1 / exp(x) ==> exp(-x) exp(x)^2 ==> exp(2*x) I don't speak about exp(log(x)) ==> x, sin(atan(x)) ==> x/sqrt(x^2+1), ... Are there other rewrite rules ? After some computations, I offen get a result as sin(x)+sin(-x) or cos(x)-cos(-x). I know it's almost impossible to choose between cos(a-b) and cos(b-a). But it's possible to choose only one expression between a-b and b-a : 1/ Look at the only numeric constant in a product, and test if it's a positive one. 2/ Look at the first term in a sum, and test this first term. Can I find it in ginac or must I use this sage function : def pseudoPositive (expr) : if expr._is_real() : return bool (RR(expr) >= 0) if expr._is_numeric () : return bool ((expr.real() > 0) or (expr.real() == 0 and expr.imag() > 0)) if expr._is_symbol() : return True opor = expr.operator() opands = expr.operands() if opor == operator.mul : return pseudoPositive (opands[-1]) if opor == operator.add : return pseudoPositive (opands[0]) return True Then I redefine the usual functions as sin by : def rewSin (expr) : if pseudoPositive (expr) : return sin (expr) else : return -sin(-expr) By this way I get all the easy simplifications. Where do ginac developpers see these rules ? inside-ginac or outside-ginac ? It's not a good idea to (re-)code these rules inside sage if I can get them by ginac. Many thanks for your advices. Francois (in France)

4 5

GiNaC for Mac OS X fink
by David Fang 13 Oct '10

13 Oct '10

Hi all, Quick announcement: A package for ginac-1.5.8 on Mac OS X has been recently added to fink (http://www.finkproject.org/) It builds against cln-1.3.1. It is currently only available in the unstable tree. Enjoy! Fang

1 0

Re: [GiNaC-devel] [GiNaC-list] archiving custom functions
by grey_earl＠web.de 13 Oct '10

13 Oct '10

Hi, there still seems a problem left - after unarchiving, substituting doesn't work anymore with realsymbols, while it works with symbols. I augmented the testcase, which now is #include <iostream> #include <fstream> #include <stdexcept> using namespace std; #include <ginac/ginac.h> using namespace GiNaC; int main() { archive aro, ari; realsymbol r("r"); symbol s("s"); ex test, test2; test = r+s; cerr << "writing archive\n"; ofstream aus("test.gar"); aro.archive_ex(test, "test"); aus << aro; aus.close(); cerr << "done writing archive\n"; cerr << "reading archive\n"; ifstream ein("test.gar"); ein >> ari; ein.close(); cerr << "done reading archive\n"; lst symlst; symlst = r,s; cerr << "unarchiving\n"; try { test2 = ari.unarchive_ex(symlst); } catch (std::exception &e) { cerr << e.what() << std::endl; } cerr << "recovered expression\n\n"; cerr << "expression = " << test2 << "\n"; test = test2.subs(lst(r==0,s==0)); cerr << "substituting (r=0,s=0) = " << test << "\n"; return 0; } Thanks! ___________________________________________________________ GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://movieflat.web.de

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-233-gcbb93fa
by git＠ginac.de 09 Oct '10

09 Oct '10

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via cbb93fadabbd56ba006902967b15b2b2aebb037c (commit) from e99d0d58c1bbaa8ee73e4a90a90aa1086f2f813d (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit cbb93fadabbd56ba006902967b15b2b2aebb037c Author: Alexei Sheplyakov <alexei.sheplyakov(a)gmail.com> Date: Sat Oct 9 18:39:41 2010 +0200 mul: algebraic_subs_mul(), has(): don't write beyond the end of array algebraic_match_mul_with_mul() iterates over operands of mul, that is for (size_t i=0; i<e.nops(); ++i) However, the size of arrays (`vectors' in STL speak) passed to this function is seq.size(), which is nops() - 1 for any mul object. Thus algebraic_match_mul_with_mul() accesses beyond the arrays limit. Usually it's not a problem, since any reasonable implementation of std::vector<bool> packs booleans into ints (or longs). However, some STL implementations (in particular, the one shipped with msvc) are more picky, and access beyond the vector<bool> limits results in a segfault. Therefore let's play safe and allocate proper number of elements (that is, nops()) for those arrays (subsed and currsubsed). ----------------------------------------------------------------------- Summary of changes: ginac/mul.cpp | 12 +++++++----- 1 files changed, 7 insertions(+), 5 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-252-g052f124
by git＠ginac.de 09 Oct '10

09 Oct '10

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, ginac_1-5 has been updated via 052f124551d2b78104b0de2008db6b8819713625 (commit) from c40c54f17b68f79ee42833adb3364970385e2caa (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 052f124551d2b78104b0de2008db6b8819713625 Author: Alexei Sheplyakov <alexei.sheplyakov(a)gmail.com> Date: Sat Oct 9 18:39:41 2010 +0200 mul: algebraic_subs_mul(), has(): don't write beyond the end of array algebraic_match_mul_with_mul() iterates over operands of mul, that is for (size_t i=0; i<e.nops(); ++i) However, the size of arrays (`vectors' in STL speak) passed to this function is seq.size(), which is nops() - 1 for any mul object. Thus algebraic_match_mul_with_mul() accesses beyond the arrays limit. Usually it's not a problem, since any reasonable implementation of std::vector<bool> packs booleans into ints (or longs). However, some STL implementations (in particular, the one shipped with msvc) are more picky, and access beyond the vector<bool> limits results in a segfault. Therefore let's play safe and allocate proper number of elements (that is, nops()) for those arrays (subsed and currsubsed). (cherry picked from commit cbb93fadabbd56ba006902967b15b2b2aebb037c) ----------------------------------------------------------------------- Summary of changes: ginac/mul.cpp | 12 +++++++----- 1 files changed, 7 insertions(+), 5 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[PATCH] mul: algebraic_subs_mul(), has(): don't write beyond the end of array
by Alexei Sheplyakov 09 Oct '10

09 Oct '10

algebraic_match_mul_with_mul() iterates over operands of mul, that is for (size_t i=0; i<e.nops(); ++i) However, the size of arrays (`vectors' in STL speak) passed to this function is seq.size(), which is nops() - 1 for any mul object. Thus algebraic_match_mul_with_mul() accesses beyond the arrays limit. Usually it's not a problem, since any reasonable implementation of std::vector<bool> packs booleans into ints (or longs). However, some STL implementations (in particular, the one shipped with msvc) are more picky, and access beyond the vector<bool> limits results in a segfault. Therefore let's play safe and allocate proper number of elements (that is, nops()) for those arrays (subsed and currsubsed). Thanks to Jan Rheinländer for a bug report. --- ginac/mul.cpp | 12 +++++++----- 1 files changed, 7 insertions(+), 5 deletions(-) diff --git a/ginac/mul.cpp b/ginac/mul.cpp index dfda410..3733bc4 100644 --- a/ginac/mul.cpp +++ b/ginac/mul.cpp @@ -729,6 +729,9 @@ bool algebraic_match_mul_with_mul(const mul &e, const ex &pat, exmap& repls, int factor, int &nummatches, const std::vector<bool> &subsed, std::vector<bool> &matched) { + GINAC_ASSERT(subsed.size() == e.nops()); + GINAC_ASSERT(matched.size() == e.nops()); + if (factor == (int)pat.nops()) return true; @@ -760,8 +763,8 @@ bool mul::has(const ex & pattern, unsigned options) const if(is_a<mul>(pattern)) { exmap repls; int nummatches = std::numeric_limits<int>::max(); - std::vector<bool> subsed(seq.size(), false); - std::vector<bool> matched(seq.size(), false); + std::vector<bool> subsed(nops(), false); + std::vector<bool> matched(nops(), false); if(algebraic_match_mul_with_mul(*this, pattern, repls, 0, nummatches, subsed, matched)) return true; @@ -771,8 +774,7 @@ bool mul::has(const ex & pattern, unsigned options) const ex mul::algebraic_subs_mul(const exmap & m, unsigned options) const { - std::vector<bool> subsed(seq.size(), false); - exvector subsresult(seq.size()); + std::vector<bool> subsed(nops(), false); ex divide_by = 1; ex multiply_by = 1; @@ -781,7 +783,7 @@ ex mul::algebraic_subs_mul(const exmap & m, unsigned options) const if (is_exactly_a<mul>(it->first)) { retry1: int nummatches = std::numeric_limits<int>::max(); - std::vector<bool> currsubsed(seq.size(), false); + std::vector<bool> currsubsed(nops(), false); exmap repls; if(!algebraic_match_mul_with_mul(*this, it->first, repls, 0, nummatches, subsed, currsubsed)) -- 1.7.1

1 0

Is this a bug?
by Jan private 08 Oct '10

08 Oct '10

Hello Alexei, while compiling an application with MSVC, I stumbled on this (because the code crashed) File: mul.cpp Function: ex mul::algebraic_subs_mul(const exmap & m, unsigned options) These two vectors are sized to seq.size(): std::vector<bool> subsed(seq.size(), false); std::vector<bool> currsubsed(seq.size(), false); They are then used in: algebraic_match_mul_with_mul() This iterates over the nops() of the mul: for (size_t i=0; i<e.nops(); ++i) { Can it be that the nops() of the mul is (always) equal to seq.size() + 1? Output of one example: ----- Code inserted in mul::algebraic_subs_mul(): std::cout << "mul::algebraic_subs_mul: nops: " << this->nops() << ", seq.size(): " << seq.size() << std::endl; std::cout << "mul::algebraic_subs_mul: " << tree << *this << dflt << std::endl; ------------ Output: mul::algebraic_subs_mul: nops: 2, seq.size(): 1 mul::algebraic_subs_mul: mul @00769848, hash=0x769820, flags=0x3, nops=2 mm 1 (numeric) @00753360, hash=0x160af41d, flags=0xf ----- overall_coeff 1/10 (numeric) @00769828, hash=0x36fbefb6, flags=0xf ===== ------------- Because the code crashes on the last iteration of the for loop, and if I size the vectors to seq.size()+1 (or maybe better nops()) it does not crash any more. Another possibility is that there is another error earlier on which results in a mul with seq.size() = 1 and nops() = 2 (for my example). Regards, Jan

2 1