From dellweg at tp1.uni-duesseldorf.de  Thu Dec  5 12:11:35 2013
From: dellweg at tp1.uni-duesseldorf.de (Matthias Dellweg)
Date: Thu, 05 Dec 2013 12:11:35 +0100
Subject: [GiNaC-devel] Fix for pattern matching
Message-ID: <20131205121135.64fff47a@phoenix.tp1.uni-duesseldorf.de>

Dear all,
while using GiNaC, I came across a strange behaviour with pattern
matching in products having more than one wildcard. The match succeeded
in a probablistic fashion. My conclusion is, that expairseq::match
dishonors the rule, that repl_lst will remain unchanged whenever false
is returned. See the attached patch, which solves the problem for me.

Anyway, I started to think about the whole matching mechanism. Wouldn't
it be much easier, if the matching was done from the patterns
perspective? A wildcard would know itself to match to anything. And it
might be possible to match a single object to a product of this
object and a global wildcard, since expairseq would know how to
handle that. See for example 'sin(phi).match(sin(wild(0))*wild(1))'.
There could be wildcards matching to everything not containing a
specified Symbol.
And in every case basic would only need to check for type equality and
matchable operands.
I think one can even implement that preserving the
current interface by calling an internal virtual match with interchanged
operands.
Any thoughts on that?

Best wishes, Matthias Dellweg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-matching-in-expairseq.patch
Type: text/x-patch
Size: 2382 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20131205/0632931e/attachment.bin>

From alexei.sheplyakov at gmail.com  Fri Dec  6 09:47:19 2013
From: alexei.sheplyakov at gmail.com (Alexei Sheplyakov)
Date: Fri, 6 Dec 2013 10:47:19 +0200
Subject: [GiNaC-devel] Fix for pattern matching
In-Reply-To: <20131205121135.64fff47a@phoenix.tp1.uni-duesseldorf.de>
References: <20131205121135.64fff47a@phoenix.tp1.uni-duesseldorf.de>
Message-ID: <CADNgsy3P74eTTiZ1O-vaUMibhgGRJccRMkDvZ5aeSdYn6RdfEw@mail.gmail.com>

Hi,

On Thu, Dec 5, 2013 at 1:11 PM, Matthias Dellweg
<dellweg at tp1.uni-duesseldorf.de> wrote:

> while using GiNaC, I came across a strange behaviour with pattern
> matching in products having more than one wildcard. The match succeeded
> in a probablistic fashion.

Could you please give some examples so I can make a proper test case?

> My conclusion is, that expairseq::match dishonors the rule, that repl_lst will
> remain unchanged whenever false  is returned. See the attached patch,
> which solves the problem for me.

Thanks for the patch. I've glanced through it and it looks reasonable.
I'll do more test
and merge it during the next week (I'm a bit busy at the moment).

Best regards,
       Alexei


From dellweg at tp1.uni-duesseldorf.de  Sat Dec  7 00:03:30 2013
From: dellweg at tp1.uni-duesseldorf.de (Matthias Dellweg)
Date: Sat, 07 Dec 2013 00:03:30 +0100
Subject: [GiNaC-devel] Fix for pattern matching
In-Reply-To: <CADNgsy3P74eTTiZ1O-vaUMibhgGRJccRMkDvZ5aeSdYn6RdfEw@mail.gmail.com>
References: <20131205121135.64fff47a@phoenix.tp1.uni-duesseldorf.de>
 <CADNgsy3P74eTTiZ1O-vaUMibhgGRJccRMkDvZ5aeSdYn6RdfEw@mail.gmail.com>
Message-ID: <20131207000330.0b0c8908@horus>

Am Fri, 06 Dec 2013 10:47:19 +0200
schrieb Alexei Sheplyakov <alexei.sheplyakov at gmail.com>:

> > while using GiNaC, I came across a strange behaviour with pattern
> > matching in products having more than one wildcard. The match
> > succeeded in a probablistic fashion.
> 
> Could you please give some examples so I can make a proper test case?

Try this:

exmap repl_lst;
cout << (t*t*exp(t*A)).match(pow(t, wild(0))*exp(wild(1))*A, repl_lst)
  << repl_lst << endl;

It turns out, my repl_lst was actually prefilled by a failed match
before. It didn't fail on its own. But it must somehow be possible to
create a Situation where a single match triggers this problem on its
own.

Kind regards,
 Matthias


From dellweg at tp1.uni-duesseldorf.de  Mon Dec  9 14:08:52 2013
From: dellweg at tp1.uni-duesseldorf.de (Matthias Dellweg)
Date: Mon, 09 Dec 2013 14:08:52 +0100
Subject: [GiNaC-devel] Fix for pattern matching
In-Reply-To: <20131207000330.0b0c8908@horus>
References: <20131205121135.64fff47a@phoenix.tp1.uni-duesseldorf.de>
 <CADNgsy3P74eTTiZ1O-vaUMibhgGRJccRMkDvZ5aeSdYn6RdfEw@mail.gmail.com>
 <20131207000330.0b0c8908@horus>
Message-ID: <20131209140852.38c9b527@phoenix.tp1.uni-duesseldorf.de>

Am Sat, 07 Dec 2013 00:03:30 +0100
schrieb Matthias Dellweg <dellweg at tp1.uni-duesseldorf.de>:
> But it must somehow be possible to
> create a Situation where a single match triggers this problem on its
> own.

Finally found it:

for i in $(seq 1 30); do echo 'match((exp(A)*sin(x))+(exp(B)*sin(y)),
(exp(A)*sin($0))+(exp(B)*sin($1)));' | ginsh ; done

without the patch it fails approximately in one out of four cases.
With the patch it seems to succeed every time.

Kind regards,
  Matthias Dellweg


From git at ginac.de  Sun Dec 15 16:28:39 2013
From: git at ginac.de (Alexei Sheplyakov)
Date: Sun, 15 Dec 2013 16:28:39 +0100 (CET)
Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic
	computations branch, master, updated. release_1-4-0-406-g9ada7a7
Message-ID: <20131215152840.0CC69F009E4@cebix.net>

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  9ada7a7f5c47e512b7bf6057d4c013612be9a33b (commit)
      from  e5c76f659e2e882da3d5dba60502d6851f782bf3 (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 9ada7a7f5c47e512b7bf6057d4c013612be9a33b
Author: Matthias Dellweg <dellweg at tp1.uni-duesseldorf.de>
Date:   Tue Dec 10 10:55:28 2013 +0200

    expairseq::match(): no side effects if match failed. Fixes spurious match failures.
    
    > match(sin(y)*exp(b)+sin(x)*exp(a), sin($0)*exp(a)+exp(b)*sin($1))
    FAIL
    
    The reason is that expairseq::match() might assign a wildcard even if
    the match fails. The first attempted submatch is sin(y)*exp(b) with
    sin($0)*exp(a). It fails (as it should) but $0 == y gets assigned as
    a side effect (which is wrong). Next submatch is sin(x)*exp(a) with
    sin($0)*exp(a) (the same pattern as in the first submatch). This one
    fails because of spurious $0 == y assignment.
    
    Due to the unpredicatable term ordering the sequence of submatches might
    be different and the match might succeed (as it should). This makes
    debugging a bit more funny.
    
    Signed-off-by: Matthias Dellweg <dellweg at tp1.uni-duesseldorf.de>
    
    [Alexei Sheplyakov: figure out the cause of the problem, make a test case]

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

Summary of changes:
 check/match_bug.cpp |   44 ++++++++++++++++++++++++++++++++++++++++++++
 ginac/expairseq.cpp |   26 +++++++++++++++++++++-----
 2 files changed, 65 insertions(+), 5 deletions(-)


hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations


From alexei.sheplyakov at gmail.com  Wed Dec 18 20:29:51 2013
From: alexei.sheplyakov at gmail.com (Alexei Sheplyakov)
Date: Wed, 18 Dec 2013 21:29:51 +0200
Subject: [GiNaC-devel] Fix for pattern matching
In-Reply-To: <20131209140852.38c9b527@phoenix.tp1.uni-duesseldorf.de>
References: <20131205121135.64fff47a@phoenix.tp1.uni-duesseldorf.de>
 <CADNgsy3P74eTTiZ1O-vaUMibhgGRJccRMkDvZ5aeSdYn6RdfEw@mail.gmail.com>
 <20131207000330.0b0c8908@horus>
 <20131209140852.38c9b527@phoenix.tp1.uni-duesseldorf.de>
Message-ID: <CADNgsy2pq_4XxbNwAHy8-6PnyPcmKpxy28FOWHkLsSoerh7Aiw@mail.gmail.com>

Hi, Matthias,


On Mon, Dec 9, 2013 at 3:08 PM, Matthias Dellweg
<dellweg at tp1.uni-duesseldorf.de> wrote:

> Finally found it:
>
> for i in $(seq 1 30); do echo 'match((exp(A)*sin(x))+(exp(B)*sin(y)),
> (exp(A)*sin($0))+(exp(B)*sin($1)));' | ginsh ; done
>
> without the patch it fails approximately in one out of four cases.
> With the patch it seems to succeed every time.

Thanks a lot. I've committed the fix and a test case (almost a week
ago, sorry for a late notification).

Best regards,
      Alexei


From dellweg at tp1.uni-duesseldorf.de  Fri Dec 20 15:02:38 2013
From: dellweg at tp1.uni-duesseldorf.de (Matthias Dellweg)
Date: Fri, 20 Dec 2013 15:02:38 +0100
Subject: [GiNaC-devel] Fix for pattern matching
In-Reply-To: <CADNgsy2pq_4XxbNwAHy8-6PnyPcmKpxy28FOWHkLsSoerh7Aiw@mail.gmail.com>
References: <20131205121135.64fff47a@phoenix.tp1.uni-duesseldorf.de>
 <CADNgsy3P74eTTiZ1O-vaUMibhgGRJccRMkDvZ5aeSdYn6RdfEw@mail.gmail.com>
 <20131207000330.0b0c8908@horus>
 <20131209140852.38c9b527@phoenix.tp1.uni-duesseldorf.de>
 <CADNgsy2pq_4XxbNwAHy8-6PnyPcmKpxy28FOWHkLsSoerh7Aiw@mail.gmail.com>
Message-ID: <20131220150238.31027f6e@phoenix.tp1.uni-duesseldorf.de>

Am Wed, 18 Dec 2013 21:29:51 +0200
schrieb Alexei Sheplyakov <alexei.sheplyakov at gmail.com>:

> Hi, Matthias,
> 
> 
> On Mon, Dec 9, 2013 at 3:08 PM, Matthias Dellweg
> <dellweg at tp1.uni-duesseldorf.de> wrote:
> 
> > Finally found it:
> >
> > for i in $(seq 1 30); do echo
> > 'match((exp(A)*sin(x))+(exp(B)*sin(y)),
> > (exp(A)*sin($0))+(exp(B)*sin($1)));' | ginsh ; done
> >
> > without the patch it fails approximately in one out of four cases.
> > With the patch it seems to succeed every time.
> 
> Thanks a lot. I've committed the fix and a test case (almost a week
> ago, sorry for a late notification).
> 
> Best regards,
>       Alexei
> _______________________________________________
> GiNaC-devel mailing list
> GiNaC-devel at ginac.de
> https://www.cebix.net/mailman/listinfo/ginac-devel

Hi Alexei,
did you check, whether your test fails probablistically within one
single process? I thougt the sorting order depends on the memorylayout
of the program. Therefor it was stable inside the debugger or one
process, but unstable accross several runs of the program.
And again: What do you think about inverting the matching from the
expression trying to match a pattern to the pattern trying to fit to an
expression?
Best wishes,
  Matthias


From dellweg at tp1.uni-duesseldorf.de  Fri Dec 20 15:21:34 2013
From: dellweg at tp1.uni-duesseldorf.de (Matthias Dellweg)
Date: Fri, 20 Dec 2013 15:21:34 +0100
Subject: [GiNaC-devel] RFC: step function and Pauli matrices
Message-ID: <20131220152134.5af069af@phoenix.tp1.uni-duesseldorf.de>

Dear all,
please consider the attached patches:

GiNaC is able to check whether expressions are sums of possymbols. We
can use that to evaluate some step functions immediately:
	0001-Evaluate-step-whenever-possible.patch
This should be a generic transformation from an integral with a step
function to step functions times integrals without:
	0002-Integrate-when-integrand-is-a-product-with-a-step-fu.patch
This patch implements Pauli matrices in the same manner as in color.cpp
(shamelessly borrowed...):
	0003-Implementation-of-Pauli-matrices.patch
As opposed to the color algebra, a product of pauli objects can always
be reduced to a linear combination of single pauli objects:
	0004-New-function-pauli_normalize.patch

Best wishes,
  Matthias Dellweg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Evaluate-step-whenever-possible.patch
Type: text/x-patch
Size: 1707 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20131220/9c639c7d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Integrate-when-integrand-is-a-product-with-a-step-fu.patch
Type: text/x-patch
Size: 1602 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20131220/9c639c7d/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Implementation-of-Pauli-matrices.patch
Type: text/x-patch
Size: 17573 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20131220/9c639c7d/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-New-function-pauli_normalize.patch
Type: text/x-patch
Size: 1513 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20131220/9c639c7d/attachment-0003.bin>

From git at ginac.de  Sun Dec 29 00:59:42 2013
From: git at ginac.de (Richard B. Kreckel)
Date: Sun, 29 Dec 2013 00:59:42 +0100 (CET)
Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic
	computations branch, master, updated. release_1-4-0-407-g9843321
Message-ID: <20131228235943.0743DF00B7C@cebix.net>

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  98433210d31a34b55c8283eb7fb7767d6c830e14 (commit)
      from  9ada7a7f5c47e512b7bf6057d4c013612be9a33b (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 98433210d31a34b55c8283eb7fb7767d6c830e14
Author: Vladimir V. Kisil <kisilv at maths.leeds.ac.uk>
Date:   Sat Dec 28 23:58:40 2013 +0000

    Fix evaluation of log(p^a) -> a*log(p), if p>0 and a is real.
    
    This evaluation was broken with commit e5c76f659e2e882d.

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

Summary of changes:
 ginac/inifcns_trans.cpp |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)


hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations


From kreckel at ginac.de  Sun Dec 29 01:04:29 2013
From: kreckel at ginac.de (Richard B. Kreckel)
Date: Sun, 29 Dec 2013 01:04:29 +0100
Subject: [GiNaC-devel] Fixing log evaluation for powers
In-Reply-To: <24421.1383569854@krein.leeds.ac.uk>
References: <24421.1383569854@krein.leeds.ac.uk>
Message-ID: <52BF670D.8070804@ginac.de>

Hi Vladimir,

On 11/04/2013 01:57 PM, Vladimir V. Kisil wrote:
> 	Making check on current master, I noticed that the following
>   test
> 
>   if (!ex(log(pow(p,a))).is_equal(a*log(p)))
>      ++result;
> 
>   from exam_inifnc.cpp failed. I think that the evaluation rule
> 
>   log(p^a) -> a*log(p), if p>0 and a is real
> 
>   falls out of inifcns_trans.cpp. I am attaching the corresponding
>   patch.

Out of curiosity, I let git bisect to the regression and found the
culprit. But how exactly your expansion rules for exp(), log(), and
abs() managed to break this evaluation is a mystery to me.

Anyway, thanks for your patch! I've applied it.

Cheers
   -richy.
-- 
Richard B. Kreckel