Nabble - GiNaC

Re: parsing of declared functions with ginac 1.5

2009-12-11T11:22:04Z

Hi,

Tony Stoecker schrieb:
> Did I miss something in the declaration to introduce the new function to the
> parser? Any help would be very much appreciated as I could not find the answer
> in the tutorial / mailing list.

starting with ginac 1.5.0 the (default) parsing behavior was changed,
and this causes your problems.
BUT: we already changed it back to the old behavior starting with
version 1.5.3. So, if you use 1.5.3 or better 1.5.5 your problems should
be gone.

Regards,
Jens
_______________________________________________
GiNaC-list mailing list
GiNaC-list@...
https://www.cebix.net/mailman/listinfo/ginac-list

From forum: Ginac - General

parsing of declared functions with ginac 1.5

2009-12-09T08:52:58Z

Hi All:

I am happily using GiNaC since version 1.3. With version 1.5 I have the
problem that parsing of declared functions does not work anymore (the way I
am using it).

The stupid example below works fine with version 1.4 but fails with version
1.5:

terminate called after throwing an instance of 'GiNaC::parse_error'
what(): GiNaC: parse error at line 0, column 0: no function "floor" with 1
arguments
[GiNaC::ex GiNaC::parser::parse_identifier_expr()(parser/parser.cpp:66)]

Did I miss something in the declaration to introduce the new function to the
parser? Any help would be very much appreciated as I could not find the answer
in the tutorial / mailing list.

Cheers,
Tony

#include "ginac/ginac.h"

static GiNaC::ex floor_evalf(const GiNaC::ex &x){
if (!GiNaC::is_a<GiNaC::numeric>(x) ) return x;
GiNaC::ex xn = GiNaC::ex_to<GiNaC::numeric>(x);
return ((int) GiNaC::ex_to<GiNaC::numeric>(xn).to_double() );
}

DECLARE_FUNCTION_1P(floor)
REGISTER_FUNCTION(floor, evalf_func(floor_evalf))

using namespace std;
using namespace GiNaC;

int main() {

symbol x("x");
lst syms; syms.append(x);
lst nums; nums.append(1.9);

//parsing from string does not work with version 1.5
ex p("floor(x)",syms);
cout << syms << "=" << nums << " ; " << p << "="
<< evalf(p.subs(syms,nums)) << endl;
exit(0);

}

------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
_______________________________________________
GiNaC-list mailing list
GiNaC-list@...
https://www.cebix.net/mailman/listinfo/ginac-list

From forum: Ginac - General

Re: Substitution of indexed expressions

2009-11-16T06:55:26Z

Hi,

>>>>> On Sun, 15 Nov 2009 18:37:29 -0500, Z S <baltcode@...> said:
ZS> As a toy example, I wanted to simplify
ZS> E[\sum_{i,j} A.i.j ^ 2] where it is known that E[A.i.j * A.i.j]= 1.

At the moment I cannot see any other solution but to use
expand_dummy_sum() routine. However it may not suit your further
intentions...

Best wishes,
Vladimir
--
Vladimir V. Kisil email: kisilv@...
-- www: http://maths.leeds.ac.uk/~kisilv/
_______________________________________________
GiNaC-list mailing list
GiNaC-list@...
https://www.cebix.net/mailman/listinfo/ginac-list

From forum: Ginac - General

Substitution of indexed expressions

2009-11-15T15:37:29Z

I am new to ginac, and I want to simplify some expected values of indexed expressions. As a toy example, I wanted to simplify
E[\sum_{i,j} A.i.j ^ 2]
where it is known that E[A.i.j * A.i.j] = 1.
The answer should be N + E[ \sum{i,j} A.i.j \sum_{k != i,l != j} A.k.l].

I tried to use the following program but it doesnt work. Any help would be greatly appreciated as I need to implement similar but more involved expressions. Thanks!

#include <iostream>
#include <ginac/ginac.h>
using namespace std;
using namespace GiNaC;

int main()
{
        symbol N("N");
        symbol i_sym("i"), j_sym("j");
        idx i(i_sym, N), j(j_sym, N);
         symbol A("A");
        ex e = indexed(A,i,j) * indexed(A,i,j);
        cout << "e = "<< e<< endl;
        cout << "Free indices = " << exprseq(e.get_free_indices()) << "\n";

        // I want to substitute A.i.j * A.i.j = 1, for any i,j
        // The following gives a run time error
        //ex e3 = subs(e,indexed(A,wild(),wild()) * indexed(A,wild(),wild()) == 1);

        // The following doesnt substitute/simplify anything

        idx i0(wild(),N), i1(wild(),N);
        ex e3 = subs(e,indexed(A,i0,i1) * indexed(A,i0,i1) == 1);
        cout << "e3 = " << e3 << endl;
        cout << "Free indices = " << exprseq(e3.get_free_indices()) << "\n";
}

_______________________________________________
GiNaC-list mailing list
GiNaC-list@...
https://www.cebix.net/mailman/listinfo/ginac-list

From forum: Ginac - General

GiNaC release 1.5.5

2009-11-04T14:07:21Z

Hi everybody,

the last release, 1.5.4, didn't have the correct library versioning.
This release fixes the problem.

GiNaC 1.5.5 is out and available. The changes are:

* Correct libtool versioning.

As always, this release can be downloaded from

http://www.ginac.de/Download.html

Best wishes,
Jens
_______________________________________________
GiNaC-list mailing list
GiNaC-list@...
https://www.cebix.net/mailman/listinfo/ginac-list

From forum: Ginac - General

GiNaC release 1.5.5

2009-11-04T14:07:21Z

Hi everybody,

the last release, 1.5.4, didn't have the correct library versioning.
This release fixes the problem.

GiNaC 1.5.5 is out and available. The changes are:

* Correct libtool versioning.

As always, this release can be downloaded from

http://www.ginac.de/Download.html

Best wishes,
Jens
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

[SCM] GiNaC -- a C++ library for symbolic computations tag, release_1-5-5, created. release_1-4-0-219-g1a7165c

2009-11-04T13:32:55Z

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 tag, release_1-5-5 has been created
at 1a7165c618c297688b905dcb7cea24512a9fbc88 (commit)

- Log -----------------------------------------------------------------
commit 1a7165c618c297688b905dcb7cea24512a9fbc88
Author: Jens Vollinga <jensv@...>
Date: Wed Nov 4 22:56:47 2009 +0100

Preparing for release.
-----------------------------------------------------------------------

hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

[SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-220-gdbf7b53

2009-11-04T13:25:00Z

From forum: Ginac - Dev

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-202-ge6b2274

2009-11-04T13:01:28Z

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 e6b2274fd45c4e635d5bcad3a4def1e97b37e051 (commit)
from 5631205a455c42a32ce9d50b6c99df0f1ad6b4e7 (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 e6b2274fd45c4e635d5bcad3a4def1e97b37e051
Author: Richard Kreckel <kreckel@...>
Date: Wed Nov 4 21:58:26 2009 +0100

Fix libtool versioning fiasco.

Fix f2f67dde5c9caca, which caused the soname to be bumped too frequently.

-----------------------------------------------------------------------

Summary of changes:
configure.ac | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)

hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

[SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-219-g55c9e75

2009-11-04T13:01:28Z

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 55c9e750f7d9dd94e7cb15ae43752da9a402973a (commit)
from 05aa307b632d8dabdf5aff96d1a0f57d94836a69 (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 55c9e750f7d9dd94e7cb15ae43752da9a402973a
Author: Richard Kreckel <kreckel@...>
Date: Wed Nov 4 21:58:26 2009 +0100

Fix libtool versioning fiasco.

Fix f2f67dde5c9caca, which caused the soname to be bumped too frequently.

-----------------------------------------------------------------------

Summary of changes:
configure.ac | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)

hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

Re: Release GiNaC 1.5.4

2009-11-03T16:08:40Z

Hi!

Richard B. Kreckel wrote:
> * A new soname, making it unsuitable as drop-in replacement for
> GiNaC-1.5.[0-3] for distributions. :-(
>
> Methinks, my patch f2f67dde5c9caca is screwy and made you screw up the
> soname of libtool versioning.
>
> Rats! I was lucky to finally have arrived at a crystal clear
> prescription in configure.ac and now it turns out to be wrong.

Oh, I think I know what's messed up! The text in configure.ac is
correct, but when we don't use the age feature, we have only two
situations: A) the interface is the same as before and B) the interface
was extended by functions/classes.

Normally, case A would be ++revision. Case B would be ++current, ++age,
and revision=0. So we always have age==current. But the way
LT_VERSION_INFO in configure.ac is assigned, age is pinned at 0! It
should be pinned at age, instead.

So, this would be the correct fix:

--- a/configure.ac
+++ b/configure.ac
@@ -58,8 +58,9 @@ AC_DEFINE_UNQUOTED(ARCHIVE_VERSION, $ARCHIVE_VERSION,
[Current GiNaC archive fil
AC_DEFINE_UNQUOTED(ARCHIVE_AGE, $ARCHIVE_AGE, [GiNaC archive file
version age])

dnl libtool versioning (We don't use libtool's age numbering since we
promise
-dnl to keep the binary interface compatible if only ginac_micro_version
changes.)
-LT_VERSION_INFO="ginac_lt_current:ginac_lt_revision:0"
+dnl to keep the binary interface compatible if only ginac_micro_version
changes.
+dnl In effect, age is pinned to current.)
+LT_VERSION_INFO="ginac_lt_current:ginac_lt_revision:ginac_lt_current"
LT_RELEASE="ginac_release"

AC_SUBST(LT_VERSION_INFO)

Indeed, it leads to libginac-1.5.so.0.1.0 with soname libginac-1.5.so.0.

-richy.
--
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

Re: Release GiNaC 1.5.4

2009-11-02T22:44:39Z

Hi Jens,

Jens Vollinga wrote:

> GiNaC 1.5.4 is out and available. The changes are:
>
> * Default parser now can again read in user defined classes.
> * Add mul::info() and add::info() support for numeric info_flags
> (GiNaC now can detect that the sum or product of a number of
> positive expressions is again a positive expression).
> * Fixed cast that caused compile error on 64bit machines.
> * Fixed incorrect uses of STL iterators.
> * Removed subdirectory debian.
> * Output LaTeX-symbols using \mathrm, instead of \mbox.

* A new soname, making it unsuitable as drop-in replacement for
GiNaC-1.5.[0-3] for distributions. :-(

Methinks, my patch f2f67dde5c9caca is screwy and made you screw up the
soname of libtool versioning.

Rats! I was lucky to finally have arrived at a crystal clear
prescription in configure.ac and now it turns out to be wrong.

-richy.
--
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

Release GiNaC 1.5.4

2009-11-02T14:59:35Z

Hi everybody,

GiNaC 1.5.4 is out and available. The changes are:

* Default parser now can again read in user defined classes.
* Add mul::info() and add::info() support for numeric info_flags
(GiNaC now can detect that the sum or product of a number of
positive expressions is again a positive expression).
* Fixed cast that caused compile error on 64bit machines.
* Fixed incorrect uses of STL iterators.
* Removed subdirectory debian.
* Output LaTeX-symbols using \mathrm, instead of \mbox.

As always, this release can be downloaded from

http://www.ginac.de/Download.html

Best wishes,
Jens
_______________________________________________
GiNaC-list mailing list
GiNaC-list@...
https://www.cebix.net/mailman/listinfo/ginac-list

From forum: Ginac - General

Release GiNaC 1.5.4

2009-11-02T14:59:35Z

Hi everybody,

GiNaC 1.5.4 is out and available. The changes are:

* Default parser now can again read in user defined classes.
* Add mul::info() and add::info() support for numeric info_flags
(GiNaC now can detect that the sum or product of a number of
positive expressions is again a positive expression).
* Fixed cast that caused compile error on 64bit machines.
* Fixed incorrect uses of STL iterators.
* Removed subdirectory debian.
* Output LaTeX-symbols using \mathrm, instead of \mbox.

As always, this release can be downloaded from

http://www.ginac.de/Download.html

Best wishes,
Jens
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

[SCM] GiNaC -- a C++ library for symbolic computations tag, release_1-5-4, created. release_1-4-0-218-g05aa307

2009-11-02T14:32:07Z

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 tag, release_1-5-4 has been created
at 05aa307b632d8dabdf5aff96d1a0f57d94836a69 (commit)

- Log -----------------------------------------------------------------
commit 05aa307b632d8dabdf5aff96d1a0f57d94836a69
Author: Jens Vollinga <jensv@...>
Date: Mon Nov 2 23:29:21 2009 +0100

Preparing for release.
-----------------------------------------------------------------------

hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

[SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-218-g05aa307

2009-11-02T14:29:43Z

From forum: Ginac - Dev

Re: Upcoming GiNaC release

2009-10-11T14:34:34Z

Dear Vladimir,

Vladimir V. Kisil wrote:
> The part of my patch from
>
> http://www.ginac.de/pipermail/ginac-devel/2009-September/001656.html
>
> which deals with positivity of adds and muls was not applied, I do not
> know either it is forgotten or was not approved.

I've talked with Jens about it and, as a result, pushed it in. In the
future, could you, please, submit git-style commented patches of
individual topics? (Best give git a try. It's a fantastic system!)
Thanks in advance!

-richy.
--
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

Re: Upcoming GiNaC release

2009-10-11T14:33:12Z

>>>>> On Sun, 11 Oct 2009 23:34:34 +0200, "Richard B. Kreckel" <kreckel@...> said:
RK> Best give git a try. It's a fantastic system!

I will try to learn it on the next occasion.

Best wishes,
Vladimir
--
Vladimir V. Kisil email: kisilv@...
-- www: http://maths.leeds.ac.uk/~kisilv/
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

[SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-217-gc7299e5

2009-10-11T14:26:42Z

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 c7299e51d5ecf61b5d85bdfeb9a2db536abf18bb (commit)
from e710763e51b6fe11020bac880c44f426544471c2 (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 c7299e51d5ecf61b5d85bdfeb9a2db536abf18bb
Author: Richard Kreckel <kreckel@...>
Date: Sun Oct 11 23:19:21 2009 +0200

Add mul::info() and add::info() support for numeric info_flags.

This way, GiNaC knows that the sum or product of a number of positive
expressions is again a positive expression. [by Vladimir Kisil]

-----------------------------------------------------------------------

Summary of changes:
ginac/add.cpp | 12 ++++++++++++
ginac/flags.h | 2 +-
ginac/mul.cpp | 12 ++++++++++++
ginac/power.cpp | 2 ++
4 files changed, 27 insertions(+), 1 deletions(-)

hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-201-g5631205

2009-10-11T14:26:42Z

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 5631205a455c42a32ce9d50b6c99df0f1ad6b4e7 (commit)
from 9b5d06b34d3ee5f0ccd3c500be38fcdf61222956 (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 5631205a455c42a32ce9d50b6c99df0f1ad6b4e7
Author: Richard Kreckel <kreckel@...>
Date: Sun Oct 11 23:19:21 2009 +0200

Add mul::info() and add::info() support for numeric info_flags.

This way, GiNaC knows that the sum or product of a number of positive
expressions is again a positive expression. [by Vladimir Kisil]

-----------------------------------------------------------------------

Summary of changes:
ginac/add.cpp | 12 ++++++++++++
ginac/flags.h | 2 +-
ginac/mul.cpp | 12 ++++++++++++
ginac/power.cpp | 2 ++
4 files changed, 27 insertions(+), 1 deletions(-)

hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

Re: GiNaC and polylogarithms

2009-10-11T14:25:55Z

On 21:32 Tue 06 Oct , Jens Vollinga wrote:
> Emanuele Bagnaschi schrieb:
> >First, G-functions currently evaluate numerically only for real
> >arguments y >= 0.
>
> yes. But I have my doubts that "improving" this is really helpful
> for practice.

I find your comment extremely interesting, since I was specifically
asked to look how to evaluate G-functions in the complex field. Do you
think that the extension is naive because of the "scaling relation"?
Or there is something else behind your comment?

>
> [...]
>

I see that there is really a lot of work to do but I'm willing to
contribute to this project and improve the status of GiNaC with this
regard. I'm really interested, even at the personal level. In fact
I've searched for years for an interesting open source project to
start contributing to.

However I won't be free to focus on this matter at least until the
21st of October, due to some major university duties. In the meanwhile
I will try to get acquainted with the existing GiNaC code.

Best regards.
--
Emanuele A. Bagnaschi
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

Re: Upcoming GiNaC release

2009-10-06T13:07:49Z

Dear Jens,

The part of my patch from

http://www.ginac.de/pipermail/ginac-devel/2009-September/001656.html

which deals with positivity of adds and muls was not applied, I do not
know either it is forgotten or was not approved.

Best wishes,
Vladimir
--
Vladimir V. Kisil email: kisilv@...
-- www: http://maths.leeds.ac.uk/~kisilv/
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

Upcoming GiNaC release

2009-10-06T12:34:44Z

Hi everybody,

I am finally going to make a 1.5.4 release soon (let's say next
weekend). Are there any pending issues left?

Regards,
Jens
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

Re: GiNaC and polylogarithms

2009-10-06T12:32:41Z

Hi,

sorry for the late reply.

Emanuele Bagnaschi schrieb:
> First, G-functions currently evaluate numerically only for real
> arguments y >= 0.

yes. But I have my doubts that "improving" this is really helpful for
practice.

> Secondly, in the tutorial is written that there's no support
> for compiling expressions containing polylogarithms to C function pointers.

True. This is badly missing. GiNaC should be able to generate a C
function that numerically evaluates a specific polylog in double
precision and whose name would be used in expression output. One reason
for not having implemented this yet is a principle problem of the code,
see below.

> Finally, I see that there are some "TODO" comments in inifcns_nsdsums.cpp which describe missing features.

Yes, but a lot of them are not that urgent, I think.

> I'm also open to any other suggestions.
> All comments are welcome.

Two more issues (which are the most urgent in this):

- Multiple polylogs with roots of unity as arguments (x1,x2,...) produce
for certain weights (m1,m2,...) wrong numeric results. There is still a
bug in the transformations. I would have to look a while for the
details. But while it is probably of no consequence for physics
applications, it is still a bad bug and needs to be fixed.

- The code is badly written. It mixes purely algebraic operations
(transformations) with numerics while using a (prematurely ...)
optimized representation of the arguments. This had and has three
consequences: bugs like above are very hard to catch, generating C
functions for compiled expressions is very difficult because the formula
used in the end for the numerics is not available to the outside as a
whole (i.e. other functions managing the expression compilation), and
thirdly the functionality of just asking a polylog what its so and so
transformation would yield is not available to the user (there are other
nice math packages that offer this).

Regards,
Jens
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

[SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-216-ge710763

2009-10-04T13:34:37Z

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 e710763e51b6fe11020bac880c44f426544471c2 (commit)
via 71e1de972fd7f37d560427bffbb0f36215788d31 (commit)
from 9fb17531da05d2959decc3856d03c71c0220b116 (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 e710763e51b6fe11020bac880c44f426544471c2
Merge: 71e1de972fd7f37d560427bffbb0f36215788d31 9fb17531da05d2959decc3856d03c71c0220b116
Author: Richard Kreckel <kreckel@...>
Date: Sun Oct 4 22:34:33 2009 +0200

Merge branch 'ginac_1-5' of ssh://www.ginac.de/srv/git/ginac into ginac_1-5

commit 71e1de972fd7f37d560427bffbb0f36215788d31
Author: Richard Kreckel <kreckel@...>
Date: Sun Oct 4 22:30:45 2009 +0200

Output LaTeX-symbols using \mathrm, instead of \mbox.

Using \mathrm improves printing in complex formulae.
One reason is that it scales in fractions. [by Vladimir Kisil]

-----------------------------------------------------------------------

Summary of changes:
ginac/constant.cpp | 6 +++---
ginac/inifcns.cpp | 4 ++--
ginac/inifcns_gamma.cpp | 2 +-
ginac/inifcns_nstdsums.cpp | 6 +++---
4 files changed, 9 insertions(+), 9 deletions(-)

hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-200-g9b5d06b

2009-10-04T13:34:15Z

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 9b5d06b34d3ee5f0ccd3c500be38fcdf61222956 (commit)
from ac235fa0a9285c055993bfa019896018db1817e6 (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 9b5d06b34d3ee5f0ccd3c500be38fcdf61222956
Author: Richard Kreckel <kreckel@...>
Date: Sun Oct 4 22:30:45 2009 +0200

Output LaTeX-symbols using \mathrm, instead of \mbox.

Using \mathrm improves printing in complex formulae.
One reason is that it scales in fractions. [by Vladimir Kisil]

-----------------------------------------------------------------------

Summary of changes:
ginac/constant.cpp | 6 +++---
ginac/inifcns.cpp | 4 ++--
ginac/inifcns_gamma.cpp | 2 +-
ginac/inifcns_nstdsums.cpp | 6 +++---
4 files changed, 9 insertions(+), 9 deletions(-)

hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

Re: Powers of exponents

2009-10-04T13:14:47Z

Hello everybody,

I'm a new ginac user because I discover sage. So you might excuse my
point of view if my arguments are out of ginac purpose. And this message
isn't direct reponse for this patch.

// 1 //

I understand that ginac operates over complex analysis as the other
computer algebra systems.

In this case it's very curious to write exp(u)^v == exp(u*v).
Fine choices of "branch cuts" may allow this point of view for a local
study,
but it isn't usual mathematics for general purpose.

You understand I don't like the exp(u)^v == exp(u*v)

// 2 //

It' bad if exp(x)/exp(x) remains : sage reduces sin(x)/sin(x) == 1 as
usual.
I don't know the inner algorithms of ginac but I suppose that all
function calls as sin(x) are seen as a new variable in the expression
which is a fraction with a lot of variables, even if someones as sin(x)
and cos(x) are linked together by cos(x)^2+sin(x)^2==1.

So exp(x)/exp(x) must be simplified in 1.

// 3 //

Look at sin(x) and cos(x).

Sometimes the user prefers the expanded formula with Tchebytchev polynomials
(cos(2x)+1)/(sin(2x)) == (2 cos(x)^2)/(2 sin(x) cos(x)) == cos(x)/sin(x)
== cotan(x).

Othertimes the user wants to combine 2 cos(x)^2 into the (almost) linear
form cos(2x)+1.
Computer algebra systems don't have any automatic transform
but the user calls the expand or the combine function for theses
opposite purposes.

Calculus are similar with exp : both transforms exp(x)^2 <==> exp(2*x)
are useful.

I observe that ginac respects algebraic user input :
by example there are very view transform with

x = 2*t/(1-t^2) ;
x.subs(t=x) == 4*t / (1 - (2*t/(1-t^2))^2)

Then the user calls expand, "simplify_fractions" or others functions if
he wants an other form of this input.

power and exp functions might be in the same case :
exp(x)^2 remains exp(x)^2 and exp(2*x) remains exp(2*x).
Then an expand call translates exp(2*x) to exp(x)^2
and a combine (or an other name) translates back exp(x)^2 to exp(2*x)

If it does so, ginac respects also the user choice for the exp function
as it does for the fractions.

_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

[SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-214-g9fb1753

2009-10-04T13:14:13Z

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 9fb17531da05d2959decc3856d03c71c0220b116 (commit)
from 43d36593b9588b938a42a98f823c36c9f1ded088 (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 9fb17531da05d2959decc3856d03c71c0220b116
Author: Jens Vollinga <jensv@...>
Date: Sun Oct 4 22:15:13 2009 +0200

Moved header includes to source files to avoid polluting the namespace
for library users.

-----------------------------------------------------------------------

Summary of changes:
ginac/parser/default_reader.tpl | 7 +++++++
ginac/parser/parse_context.h | 6 ------
ginac/parser/parser.cpp | 6 ++++++
3 files changed, 13 insertions(+), 6 deletions(-)

hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

Re: Powers of exponents

2009-10-04T12:23:45Z

Hi!

I wrote:
> I'll push a patch for the exp function and for doc/powerlaws.tex.

Well, I didn't push it yet because it turns out that it interferes in
surprising ways with mul::eval(). We used to have exp(x)/exp(x) -> 1 but
that doesn't work any more because exp(x)^(-1) evaluates to exp(-x)
first, resulting in exp(x)/exp(x) -> exp(x)*exp(-x). :-(

Unless somebody comes up with a convincing idea how to fix eval() in the
presence of pow(exp(x),a) -> exp(a*x) I'm not going to apply this patch.

Bye
-richy.
--
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

Re: Powers of exponents

2009-10-03T15:31:02Z

Hi!

I wrote:
> I'll push a patch for the exp function and for doc/powerlaws.tex.

Oh, it is all there in doc/powerlaws.tex!

This is another fine example where we saved an hour or so reading the
documentation by spending a couple of days arguing back and forth. :-)

-richy.
--
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

Re: Powers of exponents

2009-10-03T14:53:18Z

Hi!

Stephen Montgomery-Smith wrote:
> Vladimir V. Kisil wrote:
>>>>>>> On Fri, 02 Oct 2009 00:00:13 +0200, "Richard B. Kreckel"
>>>>>>> <kreckel@...> said:
>> RK> Maybe it is just too late, but I don't see the motivation for
>> RK> the "is x an integer" condition.
>>
>> Why not, if it is a correct substitution. Who know, may be as a
>> result of some evaluation power of the exponents will becomes 2.

Actually, including "x is an integer" turns out to be correct. But we
can do even better: it is sufficient to test if a is real.

Here is a proof. With arbitrary complex b:

pow(exp(a),b) == exp(b*log(exp(a))

Since a is real, we know that exp(a) is real and positive. So
log(exp(a))==a and exp(b*log(exp(a))==exp(b*a). q.e.d.

I'll push a patch for the exp function and for doc/powerlaws.tex.

> I think it is wrong to include "x is an integer." Even 1^i (which is
> exp(0)^i) is not well defined (it can be any of e^(2 pi n) for all
> integers).

That argument is confused. After all, we rewrite exp(2*Pi*I) -> 1.

-richy.
--
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

Re: Powers of exponents

2009-10-02T07:48:29Z

>>>>> On Fri, 02 Oct 2009 07:11:51 -0500, Stephen Montgomery-Smith <stephen@...> said:
SMS> I think it is wrong to include "x is an integer." Even 1^i
SMS> (which is exp(0)^i) is not well defined (it can be any of e^(2
SMS> pi n) for all integers).

Alright, here is the patch to stay on the safe side.

Best wishes,
Vladimir
--
Vladimir V. Kisil email: kisilv@...
-- www: http://maths.leeds.ac.uk/~kisilv/

--- inifcns_trans.cpp 2009-02-17 13:39:22.000000000 +0000
+++ patches/inifcns_trans.cpp 2009-10-02 15:45:17.000000000 +0100
@@ -99,9 +99,18 @@
return exp(GiNaC::real_part(x))*sin(GiNaC::imag_part(x));
}

+static ex exp_power(const ex & x, const ex & a)
+{
+ if (a.info(info_flags::integer) || (x.info(info_flags::real) && a.info(info_flags::real)))
+ return exp(x*a);
+
+ return power(exp(x), a).hold();
+}
+
REGISTER_FUNCTION(exp, eval_func(exp_eval).
evalf_func(exp_evalf).
derivative_func(exp_deriv).
+ power_func(exp_power).
real_part_func(exp_real_part).
imag_part_func(exp_imag_part).
latex_name("\\exp"));

_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

Re: Powers of exponents

2009-10-02T05:11:51Z

Vladimir V. Kisil wrote:
>>>>>> On Fri, 02 Oct 2009 00:00:13 +0200, "Richard B. Kreckel" <kreckel@...> said:
> RK> Maybe it is just too late, but I don't see the motivation for
> RK> the "is x an integer" condition.
>
> Why not, if it is a correct substitution. Who know, may be as a
> result of some evaluation power of the exponents will becomes 2.

I think it is wrong to include "x is an integer." Even 1^i (which is
exp(0)^i) is not well defined (it can be any of e^(2 pi n) for all
integers).

_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

Re: Powers of exponents

2009-10-02T00:33:44Z

>>>>> On Fri, 02 Oct 2009 00:00:13 +0200, "Richard B. Kreckel" <kreckel@...> said:
RK> Maybe it is just too late, but I don't see the motivation for
RK> the "is x an integer" condition.

Why not, if it is a correct substitution. Who know, may be as a
result of some evaluation power of the exponents will becomes 2.

Best wishes,
Vladimir
--
Vladimir V. Kisil email: kisilv@...
-- www: http://maths.leeds.ac.uk/~kisilv/
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev

Re: Powers of exponents

2009-10-01T15:00:13Z

Vladimir V. Kisil wrote:
>>>>>> On Thu, 01 Oct 2009 10:49:03 -0500, Stephen Montgomery-Smith <stephen@...> said:
> SMS> It will also be true for arbitrary x if a is an integer.
>
> Good point! The third iteration of the patch is attached.
[...]
> + if (x.info(info_flags::integer) || a.info(info_flags::integer)
> + || (x.info(info_flags::real) && a.info(info_flags::real)))
> + return exp(x*a);

Maybe it is just too late, but I don't see the motivation for the "is x
an integer" condition.

-richy.
--
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

From forum: Ginac - Dev