Convert function.pl into C++ (well, almost) source and header.
The code is much more readable now, as it's (almost) plain C++ (except
simple pythonic `preprocessor' instructions). As a side effect perl is
no longer necessary for building GiNaC.
[bugfix] Always #include <lst.h> before using lst. Fixes build error on MinGW.
[temp.expl.spec] says:
6 If a template, a member template or the member of a class template
is explicitly specialized then that specialization shall be declared
before the first use of that specialization that would cause an implicit
instantiation to take place, in every translation unit in which such a
use occurs; no diagnostic is required. If the program does not provide
a definition for an explicit specialization and either the specialization
is used in a way that would cause an implicit instantiation to take place
or the member is a virtual member function, the program is ill-formed,
no diagnostic required. An implicit instantiation is never generated for
an explicit specialization that is declared but not defined.
Apparently we are breaking this rule (presumably since the commit 99901bd5c742
`Parser can now read GiNaC lists (lst) defined by braces.'). In particular,
parser.cpp does not include lst.h (neither directly nor indirectly) which
contains explicit specialization of lst::info(). However, parser.cpp
(indirectly) includes both container.h and registar.h, so the GiNaC::lst type
is declared (and is complete) before the first usage. Thus lst::info() gets
implicitly instantiated (using the general definition provided in container.h)
when compiling the parser.cpp file, and libginac fails to link properly due
to mutliply defined symbols:
configure: correctly set rpath for linking with CLN ...
... as to not break tests for libreadline and dlopen().
Problem:
When using GCC 4.6 the configure script fails to find libreadline and
libdl, although both libraries are definitely installed. See
http://www.ginac.de/pipermail/ginac-list/2012-January/001868.html for
more details.
Reason:
Apparently GCC 4.6 dislikes the -R/the/path switch (libtool way to say
-Wl,-rpath,/the/path in a cross platform manner). Previous versions of
GCC used to ignore the -R switch, however, GCC 4.6 errors out instead.
Thus the configure script fails to detect readline and dlopen.
Solution:
Set the rpath (for linking with CLN) using the compiler friendly syntax
(i.e. -Wl,-rpath -Wl,/the/path instead of -R/the/path).
Now that C++11 is out, there is no more need for oracling
about how it might eventually standardize the branch cuts of
elementary and inverse trigonometric and hyperbolic functions.
Quick and dirty bug fix for the parser to read GiNaC::lst again.
The parser only accepts lst in the form lst(...) not {...}, though.
Function prototype can now have a argument size of 0 to indicate
functions with an arbitrary number of arguments (like lst).
Fixed a bug in the code for subsitutions in indexed expressions.
subs_options::no_index_renaming was ignored.
Thanks to Gerhard Hejc for reporting and suggesting a fix.
Richard Kreckel [Tue, 31 May 2011 06:46:32 +0000 (08:46 +0200)]
Care about refcounts when reclaiming memory allocated for static objects.
With commit aff357309f6 we started freeing numeric flyweights when the library
usage count drops to zero. But that triggers assertions in basic::~basic
when compiled with -DDO_GINAC_ASSERT because these flyweights are still being
used by their matching ex objects (their refcount is still 1). Instead of
removing that assertion, let's just call the ex::~ex manually and let it do
the freeing.
Richard Kreckel [Fri, 27 May 2011 06:51:05 +0000 (08:51 +0200)]
Janitorial commit.
Remove some assertions that have been wrong since a while, in particular since 8ba901b532b, when we started to factor numerical factors from power objects.
Fix some broken indentation. Fix some comment errors. Remove unused variable.
[build] configure: don't abuse AC_CHECK_FILE. Unbreaks the cross-compilation.
Checking for ginsh_parser.h in configure is not a good idea, since it
1) produces a bogus warning during an out of source build,
2) breaks cross-compilation.
Solution: just skip that bogus check (auto* tools do a similar check in
the run-time *for a reason*).
Jens Vollinga [Sun, 22 May 2011 14:19:17 +0000 (16:19 +0200)]
This patch fixes a bug on machines where char is unsigned by default, by
extending the type of clifford_max_label to include all 257 possible
return values. Thanks to Martin Guy for the bug report and patch.
Jens Vollinga [Fri, 20 May 2011 23:30:08 +0000 (01:30 +0200)]
Limiting the costly symmetrization tests inside simplify_indexed() to
cases where at least one antisymmetric or cyclic non-free index is
involved. Thanks to P.G.Clark for reporting the problem.
Jens Vollinga [Fri, 20 May 2011 21:30:38 +0000 (23:30 +0200)]
Changed naming convention for the library. Now, it is only libginac.so
without the release version included (instead of libginac-1.5.so, for
example). Since the previous commit broke the ABI, we are free to
implement this long planned change now.
Jens Vollinga [Fri, 20 May 2011 11:55:35 +0000 (13:55 +0200)]
Fixed a bug in is_polynomial() that caused expressions like
sqrt(x*x+1)*sqrt(x+1) to be wrongly identified as polynomials in x.
Thanks to Florent Hivert for reporting.
Jens Vollinga [Thu, 19 May 2011 07:44:11 +0000 (09:44 +0200)]
The patch improves the run time at the expense of using more RAM in some
situations. Please note: it doesn't improve the actual algorithm
(iteration over all permutations). Thanks to Alexei Sheplyakov.
Richard Kreckel [Sun, 15 May 2011 16:40:44 +0000 (18:40 +0200)]
Fix mul::conjugate().
Overwrite conjugate() for mul objects because the base class's conjugate
function is incorrect at branch cuts when exponents are fractional (roots).
This has been reported as Sage #10964.
While at it, fix some funny indentation and remove unneeded tests.
Richard Kreckel [Thu, 3 Feb 2011 22:48:21 +0000 (23:48 +0100)]
Merge branch 'master.msvc.support' of git://github.com/AlexeiSheplyakov/GiNaC
* 'master.msvc.support' of git://github.com/AlexeiSheplyakov/GiNaC:
Omit extra qualification (as in struct foo f() vs foo f()).
[msvc] msvc cannot handle string constants above 16k
[msvc] Yet another compiler bug work around.
[msvc] Work around strange scoping and name mangling rules.
Add few defines for msvc (__func__, __alignof__).
symmetry::compare_same_type(): const-correctness fix
clifford: fix a few GCCisms (or, not).
Don't try to tie the library version to the package version number.
Use curret:release:age to indicate ABI changes instead. Hard-code LT_RELEASE
to 1.5 to avoid spurious SONAME change (current code is binary-compatible
with GiNaC 1.5.8).
But the ability to do so is important for a lot of practical uses. So soon
after the C++98 standard was approved, a language defect report was filed
on this topic, see
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#195
The result is that compilers will be allowed to support reinterpret_cast
conversions of function pointers to other (pointers) types, and vice a versa.
Such conversions work with *current* compilers (GCC 4.x), but don't work
with older ones, hence this patch.
Fix the compliation error *for real* ... and restore performance
Commit 8bf0597dde55e4c94a2ff39f1d8130902e3d7a9b (titled as 'Fixed the parser
such that it can read in user defined classes again.') made the parser a bit
slower, especially if the input contains many terms of user-defined type.
The reason for that is quite simple: we throw and catch an exception every
time we construct an object of user-defined type:
// dirty hack to distinguish between serial numbers of functions and real
// pointers.
GiNaC::function* f = NULL;
try {
unsigned serial = (unsigned)(unsigned long)(void *)(reader->second);
f = new GiNaC::function(serial, args);
}
catch ( std::runtime_error ) {
if ( f ) delete f;
ex ret = reader->second(args);
return ret;
}
Fortunately functions are aligned and we can use much more efficient
technique to distinguish between serial and pointers to functions.
This patch is an ugly hack that does the same as the commit f38cbcd651246fb5c1294705d29399f3cbfddaf5
but without changing the ABI (so it can be used in ginac_1-5).
Richard Kreckel [Thu, 9 Dec 2010 08:18:34 +0000 (09:18 +0100)]
Make symbol::name be initialized lazily.
This fixes symbol::get_name(), which returned an empty string instead of
"symbol" followed by the serial number if the symbol's name wasn't
specified in the constructor.
Richard Kreckel [Thu, 9 Dec 2010 08:18:34 +0000 (09:18 +0100)]
Make symbol::name be initialized lazily.
This fixes symbol::get_name(), which returned an empty string instead of
"symbol" followed by the serial number if the symbol's name wasn't
specified in the constructor.
Thanks to Warren Weckesser for reporting this bug.
[PATCH 2/2] chinrem_gcd: return correct integer content when GCD is a number.
This patch fixes a silly typo and makes chinrem_gcd work correctly with
polynomials which are "almost" (up to an integer coefficient) relatively
prime.
[PATCH 1/2] extract_integer_content: check for rational numbers properly.
Commit 3d09388a (titled as `[bugfix] chinrem_gcd: handle polynomials over
rationals properly.') broke extract_integer_content: now it always returns 1.
The check for rational `integer_contnent' introduced by that commit is wrong
(since integers is a subset of rationals). Rewrite the check proprerly.
(cherry picked from commit f0fb303711b4334ce59f7da63bfa7cb49f46265f)
[PATCH 2/2] chinrem_gcd: return correct integer content when GCD is a number.
This patch fixes a silly typo and makes chinrem_gcd work correctly with
polynomials which are "almost" (up to an integer coefficient) relatively
prime.
Thanks to Ernst Moritz Hahn for a bug report and a test case.
[PATCH 1/2] extract_integer_content: check for rational numbers properly.
Commit 3d09388a (titled as `[bugfix] chinrem_gcd: handle polynomials over
rationals properly.') broke extract_integer_content: now it always returns 1.
The check for rational `integer_contnent' introduced by that commit is wrong
(since integers is a subset of rationals). Rewrite the check proprerly.
Jan Rheinländer [Mon, 20 Sep 2010 12:23:14 +0000 (12:23 +0000)]
[msvc] Work around strange scoping and name mangling rules.
1. msvc creates different symbols for a variable declared in
a namespace scope and (the same variable) in a class method
scope. That is,
// util.cpp
namespace GiNaC {
extern const ex _ex0; // [1]
}
// ex.h
namespace GiNaC {
class ex {
public:
bool is_zero() {
extern const ex _ex0;
// mangled name of _ex0 is different that of [1]
}
};
}
2. The mangled names for cv-qualified and cv-unqualified versions
of a type are different (which violates the requirements stated
in [basic.type.qualifier])
These msvc's "features" cause linking failures due to unresolved
external symbols.
Solution:
1. Declare variables (_ex0) in the GiNaC namespace scope (for msvc only).
2. Add corresponding cv-qualifier(s).
The method in question is const, therefore one should use const_iterator
to access indices. Some compilers (for instance, msvc) are very strict
about this, and won't accept (invalid) code using non-const iterator.
[bugfix] chinrem_gcd: handle polynomials over rationals properly.
* extract_integer_content():
integer_content() can also return a rational number, e.g if the expression
is a polynomial over rationals (in this case expr/content is polynomial
over integers with integer content being 1). Therefore check if
integer_content() is really an integer (and if it's not just return 1,
GCD for polynomials over a field is defined up to arbitrary element of
the field).
This fixes possible segfault when computing GCD of polynomials over
rationals (this is not theoretical, see the added test case).
[bugfix] chinrem_gcd: handle polynomials over rationals properly.
* extract_integer_content():
integer_content() can also return a rational number, e.g if the expression
is a polynomial over rationals (in this case expr/content is polynomial
over integers with integer content being 1). Therefore check if
integer_content() is really an integer (and if it's not just return 1,
GCD for polynomials over a field is defined up to arbitrary element of
the field).
This fixes possible segfault when computing GCD of polynomials over
rationals (this is not theoretical, see the added test case).
Thanks to Ernst Moritz Hahn for reporting this bug.
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)
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).
Avoid infinite loop when unarchiving realsymbol and possymbol.
symbol::read_archive(): explicitly set status_flags::evaluated (and
status_flags::expanded) on object being unarchived. These flags get
reset by basic::operator=(const basic&) for realsymbol and possymbol,
and nothing sets (except symbol ctor), so automatic evaluation never
terminates (or rather, terminates due to a stack overflow). Therefore
it's necessary need to set status_flags::evaluated explicitly.
Avoid infinite loop when unarchiving realsymbol and possymbol.
symbol::read_archive(): explicitly set status_flags::evaluated (and
status_flags::expanded) on object being unarchived. These flags get
reset by basic::operator=(const basic&) for realsymbol and possymbol,
and nothing sets (except symbol ctor), so automatic evaluation never
terminates (or rather, terminates due to a stack overflow). Therefore
it's necessary need to set status_flags::evaluated explicitly.
Thanks to Markus Fröb for a bugreport and a test case.
Richard Kreckel [Wed, 22 Sep 2010 22:40:38 +0000 (00:40 +0200)]
Make sure add::eval() collects all numeric terms.
Apparently, add::eval() assumed that none of the elements of its epvector
has a numeric rest. However, nothing guarantees that -- in particular
evalchildren() doesn't (and actually cannot) do so. Since there are many
places where a new add is constructed directly from an epvector, enforcing
this doesn't make sense either. One example where it did fail was found by
Burgin Erocal: real_part(1+2*(sqrt(2)+1)*(sqrt(2)-1)) returned 1+2*1, not 3.
Richard Kreckel [Wed, 22 Sep 2010 22:40:38 +0000 (00:40 +0200)]
Make sure add::eval() collects all numeric terms.
Apparently, add::eval() assumed that none of the elements of its epvector
has a numeric rest. However, nothing guarantees that -- in particular
evalchildren() doesn't (and actually cannot) do so. Since there are many
places where a new add is constructed directly from an epvector, enforcing
this doesn't make sense either. One example where it did fail was found by
Burgin Erocal: real_part(1+2*(sqrt(2)+1)*(sqrt(2)-1)) returned 1+2*1, not 3.
Richard Kreckel [Wed, 15 Sep 2010 07:11:57 +0000 (09:11 +0200)]
Be more careful about final top-level substitution.
Substituting x==log(x) in exp(x) erroneously returned log(x) because of a
final subst(x==log(x)) after having eval'ed exp(log(x)) -> x. This final
substitution is wrong in the general case. On the other hand, the intent
is to syntactically substitute functions of a given kind etc. This patch
suppresses the final top-level substitution unless the intermediate result
is a container.
Thanks to Burcin Erocal for reporting this bug (originally described by
Kees van Schaik on sage-support@googlegroops.com).
Richard Kreckel [Wed, 15 Sep 2010 07:11:57 +0000 (09:11 +0200)]
Be more careful about final top-level substitution.
Substituting x==log(x) in exp(x) erroneously returned log(x) because of a
final subst(x==log(x)) after having eval'ed exp(log(x)) -> x. This final
substitution is wrong in the general case. On the other hand, the intent
is to syntactically substitute functions of a given kind etc. This patch
suppresses the final top-level substitution unless the intermediate result
is a container.
Thanks to Burcin Erocal for reporting this bug (originally described by
Kees van Schaik on sage-support@googlegroops.com).
Richard Kreckel [Mon, 13 Sep 2010 20:39:05 +0000 (22:39 +0200)]
Fix autoconf warning about AC_INIT use.
Apparently, autoconf doesn't like the angle brackets in the bug-report
argument any more. It comlains "not a literal: <ginac-list@ginac.de>".
So let's remove it. And while at it, also provide tarname and url
arguments.
Richard Kreckel [Mon, 13 Sep 2010 20:39:05 +0000 (22:39 +0200)]
Fix autoconf warning about AC_INIT use.
Apparently, autoconf doesn't like the angle brackets in the bug-report
argument any more. It comlains "not a literal: <ginac-list@ginac.de>".
So let's remove it. And while at it, also provide tarname and url
arguments.
While working on fsolve bug I've noticed the following in valgrind log:
==17455== 136 (56 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 16 of 19
==17455== at 0x4C249C7: operator new(unsigned long) (vg_replace_malloc.c:220)
==17455== by 0x516CA70: GiNaC::power::eval(int) const (power.cpp:540)
==17455== by 0x4FC1E39: GiNaC::ex::construct_from_basic(GiNaC::basic const&) (ex.cpp:310)
==17455== by 0x406FBF: main (ex.h:255)
fsolve: avoid useless numerical evaluation of the function
Don't compute f(x) if new x is outside of the interval. We don't need that
value anyway, and the function might be difficult to compute numerically or
even ill defined outside the interval.
As a result fsolve is able to find root(s) of some weird functions.
For example
In general, ex_to is unsafe, and should be used only after proper checks.
evalf() may return non-numeric expression for various reasons (bad
convergence, floating point over- or underflow, out of memory, etc).
So let's add missing checks.
While working on fsolve bug I've noticed the following in valgrind log:
==17455== 136 (56 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 16 of 19
==17455== at 0x4C249C7: operator new(unsigned long) (vg_replace_malloc.c:220)
==17455== by 0x516CA70: GiNaC::power::eval(int) const (power.cpp:540)
==17455== by 0x4FC1E39: GiNaC::ex::construct_from_basic(GiNaC::basic const&) (ex.cpp:310)
==17455== by 0x406FBF: main (ex.h:255)
Heap allocated objects definitely need the status_flags::dyncallocated flag.
fsolve: avoid useless numerical evaluation of the function
Don't compute f(x) if new x is outside of the interval. We don't need that
value anyway, and the function might be difficult to compute numerically or
even ill defined outside the interval.
As a result fsolve is able to find root(s) of some weird functions.
For example
In general, ex_to is unsafe, and should be used only after proper checks.
evalf() may return non-numeric expression for various reasons (bad
convergence, floating point over- or underflow, out of memory, etc).
So let's add missing checks.
Texinfo interprets @strong{Note...} as a cross reference and gives a
warning about it. Changed the text to avoid this.
(cherry picked from commit 7769ce49235ed6510785baa0a29801e3a59b563e)
git://www.ginac.de / ginac.git / log