Richard Kreckel [Sat, 22 May 2010 20:34:42 +0000 (22:34 +0200)]
Be more careful with conjugate(f(x)) -> f(conjugate(x)).
That identity is correct for holomorphic functions, but we have to be
careful with some functions not being holomorphic everywhere. On branch
cuts, it is wrong. For a discussion, see:
<http://www.ginac.de/pipermail/ginac-list/2010-April/001601.html>.
This patch changes the default behavior of user-defined functions. From
now on, a user-defined conjugate_func must be registered, in order to
evaluate conjugate(f(x)) -> f(conjugate(x)). This patch also adds such
functions for most initially known functions.
Richard Kreckel [Sat, 22 May 2010 20:34:42 +0000 (22:34 +0200)]
Be more careful with conjugate(f(x)) -> f(conjugate(x)).
That identity is correct for holomorphic functions, but we have to be
careful with some functions not being holomorphic everywhere. On branch
cuts, it is wrong. For a discussion, see:
<http://www.ginac.de/pipermail/ginac-list/2010-April/001601.html>.
This patch changes the default behavior of user-defined functions. From
now on, a user-defined conjugate_func must be registered, in order to
evaluate conjugate(f(x)) -> f(conjugate(x)). This patch also adds such
functions for most initially known functions.
pgcd(), chinrem_gcd(): use appropriate definition of the degree.
Effect: fixes (rare) GCD miscalculation.
pgcd() treats polynomials Z_p[x_0, ..., x_n] as R[x_0, ..., x_{n - 1}], where
R = Z_p[x_n]. Therefore one should use correct definition of the degree
(i.e. compute it w.r.t. x_0, ..., x_{n-1}, but NOT w.r.t. x_n!).
One should use appropriate definition of degree (that is, w.r.t. x_0, ..., x_n)
in chinrem_gcd() too.
pgcd(): avoid infinite loop if the first GCD candidate coincides with GCD
136 if (H_lcoeff.is_equal(lc_gcd)) {
137 if ((Hprev-H).expand().smod(pn).is_zero()) // (*)
138 continue;
The check (*) can result in infinite loop if the (very) first GCD candidate
gives the correct GCD: any subsequent iterations give the same result, so
Hprev and H will be equal (hence the infinite loop). That check is not very
useful (AFAIR I was trying to avoid extra division checks), so let's remove it.
pgcd(), chinrem_gcd(): use appropriate definition of the degree.
Effect: fixes (rare) GCD miscalculation.
pgcd() treats polynomials Z_p[x_0, ..., x_n] as R[x_0, ..., x_{n - 1}], where
R = Z_p[x_n]. Therefore one should use correct definition of the degree
(i.e. compute it w.r.t. x_0, ..., x_{n-1}, but NOT w.r.t. x_n!).
One should use appropriate definition of degree (that is, w.r.t. x_0, ..., x_n)
in chinrem_gcd() too.
pgcd(): avoid infinite loop if the first GCD candidate coincides with GCD
136 if (H_lcoeff.is_equal(lc_gcd)) {
137 if ((Hprev-H).expand().smod(pn).is_zero()) // (*)
138 continue;
The check (*) can result in infinite loop if the (very) first GCD candidate
gives the correct GCD: any subsequent iterations give the same result, so
Hprev and H will be equal (hence the infinite loop). That check is not very
useful (AFAIR I was trying to avoid extra division checks), so let's remove it.
Richard Kreckel [Thu, 13 May 2010 16:30:40 +0000 (18:30 +0200)]
Explicit function disambiguation.
This is necessary for compilers where the hyperbolic and the tgamma function
templates are pulled in from <cmath> and compete with GiNaC's function
templates. GCC 4.4 and 4.5 need this, when compiling with -std=cxx0x.
Richard Kreckel [Thu, 13 May 2010 16:30:40 +0000 (18:30 +0200)]
Explicit function disambiguation.
This is necessary for compilers where the hyperbolic and the tgamma function
templates are pulled in from <cmath> and compete with GiNaC's function
templates. GCC 4.4 and 4.5 need this, when compiling with -std=cxx0x.
Richard Kreckel [Thu, 25 Mar 2010 22:08:54 +0000 (23:08 +0100)]
Really fixed the atan2(-Pi, 0) bug.
The problem was that atan2_eval assumed that if y is real and not
positive, it must be negative. But this neglects the fact that in
symbolic compution it may just not be possible to determine the
sign. Now, the expression is returned as it is. Ugly, but correct.
Richard Kreckel [Thu, 25 Mar 2010 22:08:54 +0000 (23:08 +0100)]
Really fixed the atan2(-Pi, 0) bug.
The problem was that atan2_eval assumed that if y is real and not
positive, it must be negative. But this neglects the fact that in
symbolic compution it may just not be possible to determine the
sign. Now, the expression is returned as it is. Ugly, but correct.
Jens Vollinga [Thu, 25 Mar 2010 09:36:41 +0000 (10:36 +0100)]
Fixed a bug in atan2. It gave a division by zero error for calls like
atan2(-Pi,0), because arguments like -Pi were not recognized (via
info_flags) as negative but as real nevertheless.
(cherry picked from commit 9e13d46552bb7852399867b9eb355732b9ded59e)
Jens Vollinga [Thu, 25 Mar 2010 09:36:41 +0000 (10:36 +0100)]
Fixed a bug in atan2. It gave a division by zero error for calls like
atan2(-Pi,0), because arguments like -Pi were not recognized (via
info_flags) as negative but as real nevertheless.
pgcd(): detect relatively prime polynomials properly...
... so pgcd() doesn't loop forever any more. Division test does not handle
relatively prime polynomials (because C = 1 divides any polynomial). So we
should stop interpolation (and return gcd of contents) if we got relatively
prime images (we should do that for efficiency reasons too).
pgcd(): detect relatively prime polynomials properly...
... so pgcd() doesn't loop forever any more. Division test does not handle
relatively prime polynomials (because C = 1 divides any polynomial). So we
should stop interpolation (and return gcd of contents) if we got relatively
prime images (we should do that for efficiency reasons too).
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.
Richard Kreckel [Tue, 29 Sep 2009 20:28:47 +0000 (22:28 +0200)]
Remove debian/ directory.
The lifecycle of the Debian packaging files is better maintained in
the Debian pool's diff file. Removing these files makes the life of
the GiNaC releaser easier.
Richard Kreckel [Tue, 29 Sep 2009 20:25:16 +0000 (22:25 +0200)]
Remove debian/ directory.
The lifecycle of the Debian packaging files is better maintained in
the Debian pool's diff file. Removing these files makes the life of
the GiNaC releaser easier.
Richard Kreckel [Tue, 29 Sep 2009 20:08:11 +0000 (22:08 +0200)]
Properly document how to deal with libtool versioning.
The old description was referring to ginac_lt_age which should always
stay 0, because we promised to mark incompatible binary interfaces by
bumping ginac_minor_version (or even ginac_major_version). Let's get
rid of ginac_lt_age.
Richard Kreckel [Tue, 29 Sep 2009 20:08:11 +0000 (22:08 +0200)]
Properly document how to deal with libtool versioning.
The old description was referring to ginac_lt_age which should always
stay 0, because we promised to mark incompatible binary interfaces by
bumping ginac_minor_version (or even ginac_major_version). Let's get
rid of ginac_lt_age.
modular_matrix: don't use STL iterators in {mul, sub}_col and friends.
Not using STL iterators makes the code simpler and cleaner. Also we don't
have to argue whether the standard ([lib.random.access.iterators]) imposes
any pre/post-condictions on operator+=.
(cherry picked from commit 59ec13895c97ffd74979a0b811a7571f6de56386)
modular_matrix: don't use STL iterators in {mul, sub}_col and friends.
Not using STL iterators makes the code simpler and cleaner. Also we don't
have to argue whether the standard ([lib.random.access.iterators]) imposes
any pre/post-condictions on operator+=.
shaker_sort, permutation_sign: fix invalid use of STL iterators.
According to the standard incrementing end(), and decrementing begin()
are ill-defined operations (see [lib.forward.iterators],
[lib.bidirectional.iterators]).
(cherry picked from commit 694f839947982f5b12b6c629d5bab522c801630d)
check_parameter_G: fix pontential increment of end().
Incrementing past-the-end iterator is not permitted by the standard, see
[lib.input.iterators].
(cherry picked from commit 49a44f7d55ec0d6686d3c32c7081a07d10c93274)
According to [lib.bidirectional.iterators] it's not OK to decrement
an iterator pointing to the beginning of the sequence. Fortunately random
access iterators provided by (current versions of) gcc/libstdc++ don't have
this silly limitation, so the code which works with pointers works with
iterators without any changes at all. However,
- there's no guarantee that the current behavior won't change in the future
- some non-GNU compilers are not that smart (i.e. the program segfaults
upon when decrementing beginning-of-the-sequence iterator).
(cherry picked from commit dda45abd8a2c408f8b3eb7959a10dfb2468ecc3a)
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.
shaker_sort, permutation_sign: fix invalid use of STL iterators.
According to the standard incrementing end(), and decrementing begin()
are ill-defined operations (see [lib.forward.iterators],
[lib.bidirectional.iterators]).
According to [lib.bidirectional.iterators] it's not OK to decrement
an iterator pointing to the beginning of the sequence. Fortunately random
access iterators provided by (current versions of) gcc/libstdc++ don't have
this silly limitation, so the code which works with pointers works with
iterators without any changes at all. However,
- there's no guarantee that the current behavior won't change in the future
- some non-GNU compilers are not that smart (i.e. the program segfaults
upon when decrementing beginning-of-the-sequence iterator).
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).
Changed the parser such that it understands all defined functions
including the user defined ones.
To this end a method has been added to class function to allow the
modified get_default_reader() function to build up a complete prototype
table. The autogen tool is no longer required.
Added include for cstdio header.
gcc 4.0 does not include cstdio as part of other headers like string
anymore. As a result, gcc 4.0 complained about EOF being undefined.
Added include for cstdio header.
gcc 4.0 does not include cstdio as part of other headers like string
anymore. As a result, gcc 4.0 complained about EOF being undefined.
Due to the strange (although permitted by the standard) behaviour of C++
RTTI on woe32 calchash() returns different hash values for equal objects.
As a result automatic evaluation gets spectacularly broken:
examining clifford objects.....({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned -{1+t,2+x,3+y,4+z}+{1+t,2+x,3+y,4+z} instead of 0
({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned -{1+t,2+x,3+y,4+z}+{1+t,2+x,3+y,4+z} instead of 0
.({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned -{1+t,2+x,3+y,4+z}+{1+t,2+x,3+y,4+z} instead of 0
({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned {1+t,2+x,3+y,4+z}-{1+t,2+x,3+y,4+z} instead of 0
[skipped]
.......FAIL: exam_clifford.exe
This patch works around `features' of woe32 RTTI, so calchash() works
properly.
Due to the strange (although permitted by the standard) behaviour of C++
RTTI on woe32 calchash() returns different hash values for equal objects.
As a result automatic evaluation gets spectacularly broken:
examining clifford objects.....({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned -{1+t,2+x,3+y,4+z}+{1+t,2+x,3+y,4+z} instead of 0
({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned -{1+t,2+x,3+y,4+z}+{1+t,2+x,3+y,4+z} instead of 0
.({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned -{1+t,2+x,3+y,4+z}+{1+t,2+x,3+y,4+z} instead of 0
({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned {1+t,2+x,3+y,4+z}-{1+t,2+x,3+y,4+z} instead of 0
[skipped]
.......FAIL: exam_clifford.exe
This patch works around `features' of woe32 RTTI, so calchash() works
properly.
Univariate GCD timing: use sr_gcd when appropriate.
The benchmark consists of two parts:
1) timing of different GCD calculation methods (i.e. subresultant PRS,
heuristic, chinese remaindering).
2) timing of different implementations of the same method. The purpose
is to find out how (in)efficient GiNaC::ex is as a representation
of (univariate) polynomials (as a side note, the result is a bit
depressing -- using coefficient vector instead of GiNaC:ex makes
GCD calculation 50x -- 1000x faster).
Now GiNaC uses modular (chinese remaindering) GCD by default, so part 2)
got broken, i.e. instead of (intended) timings
a) (heuristic, GiNaC::ex) versus (heuristic, coefficient vector)
b) (PRS, GiNaC::ex) versus (PRS, coefficient vector)
one gets
a') (heuristic, GiNaC::ex) versus (heuristic, coefficient vector)
b') (chinese remaindering, GiNaC::ex) versus (PRS, coefficient vector)
Set the gcd_options::use_sr_gcd to restore the meaning of the benchmark.
Note: this patch does not affect the library proper.
Jens Vollinga [Fri, 6 Feb 2009 15:07:10 +0000 (16:07 +0100)]
Prettified source code.
- Added copyright and GPL licencing to new files.
- Increased year to 2009.
- Changed guarding macros in header to uniform pattern without leading or
trailing __ (double underscores).
- Put includes of system wide header consistently below own includes (help
a tiny bit to clarify dependencies).
git://www.ginac.de / ginac.git / log